@Claude-Girard
This is a bug that is fixed in my nightly builds (as seen by @Uncle-Frank 's link). For now you should be able to add a space infront of
“C:\tmp” in your “Snapin Arguments” field. Hopefully that should serve as a hot-fix.

This issue was addressed in v0.11.2. As I mentioned in the other thread concerning this issue, auto updating patches don’t take place until the next release. What I mean by that is since v0.10.6 was installed, v0.10.6 auto update code runs, not v0.11.2. When v0.11.2 performs an upgrade to something newer, then that patch will run.

And again, as I mentioned in the other thread, a band-aid for your client that upgrade to v0.11.2 is to simply make a snapin script that deleted the file if it exists.

This issue can only occur on Windows with a non root log.

Nothing has changed concerning how the client binds a machine to the domain since v0.8 or so. Having your source image be part of the domain is a mess waiting to happen, especially if you didn’t sysprep.

Essentially all your machines post-imaged have the same security ids, the same domain binding and membership, the same everything. So right out of the gate post-imaged they would have massive domain membership conflicts.

@Claude-Girard v0.9.6 is released, and this includes the snapin fix for the problem you originally posted on. (https://news.fogproject.org/client-v0-9-6/ )

@kenoboy

Short answer: Not with the client, but perhaps with some post-sysprep script.

Long answer: Azure AD is not your standard enterprise directory service system. A directory service is meant to manage things like identity, workstations, security, network policies, and so on. It is also standard for a directory service to provide the LDAP protocol for authentication (Lightweight Directory Access Protocol). This is what the client leverages to join Windows Server AD, Apple Open Directory, Samba, and any other LDAP compliant directory service.

Azure AD only focuses on the identity portion, and one of its main uses is as SaaS (Software as a Service). As such it has no need to provide LDAP support. Instead it provides modern web-tech based protocols via REST api and such. It’s used to integrate with other software and provide a SSO interface.

Azure AD and your standard LDAP domain are fundamentally different, and as such the client cannot join it. Instead you may need to use a script that runs after sysprep completes (setupcomplete.cmd). A quick Google search results in this article: https://azure.microsoft.com/en-us/documentation/articles/active-directory-azureadjoin-devices-group-policy/ . I haven’t looked through it in detail, but it appears they are using a powershell script to join Azure AD.

If you got that route, you must/should really use the built in snapin reboot option . That option exists for a reason.

@Wayne-Workman
http://php.net/manual/en/language.operators.string.php#language.operators.string

@Joe-Gill try resetting encryption data for that host and see if things are better. In any case this is a server issue @Tom-Elliott

The log says invalid security token. Try hitting the reset encryption data button on the host in the fog web portal.

@jmeyer , v0.9.9 is released. This should fix your issue. Can you confirm this when you get a chance?

Go to the host in your fog web portal and there should be a large reset encryption button on the top.

Since I don’t know everything about your setup I can only speculate. My guess is that at some point you may have tried reinstalling the client on the problematic host. It would cause an issue because:

1. the original installation successfully authenticated and set the token.
2. on uninstalling / reinstallation the token is deleted from the computer, but the server still has it.
3. on installation the client no longer has the old token, but the server is expecting it. Thus causing authentication issues.

@jmeyer

The client automatically updates itself whenever you upgrade the server.

Try logging out and in.

As much as the security model may seem like its an overkill, believe me when I say it is needed. We also built it in a fashion that you, as an end user, should almost never have to interact with it or manually intervene (e.g. resetting encryption data). The only time you need to step in is if you move your server to another machine or reinstall the client on the computer.

Disable the client updater module on all computers, that will halt the massive network traffic.

Sounds like the printer configuration isn’t correct. Try running printer manager helper on this host and go to the Add New Printer tab. Fill in the necessary fields and try adding it. You should get an error pop up.

@Wayne-Workman one thing. I always recommend resolving where the snapin pack is at runtime instead of hard coding. For Powershell the command would be:

$scriptDir = split-path -parent $MyInvocation.MyCommand.Definition on powershell 2 and above or just $PSScriptRoot on powershell 3 and above.

@Matthieu-Jacquart @ch3i @Claude-Girard

v0.9.11 is currently in the process of being released, and should properly address this issue.

@Tom-Elliott, can you post here when you update the fogproject repo with 0.9.11?

Was it a bad driver? The ntprint inf is actually a wrapper driver that just points to any installed drivers that say they will work. You could just host the driver on a network share or even have a local copy that you point to. (Printer manager helper will always say its using ntprint as the driver though).