@cojohnson That’s pretty straight forward. Using the tray icon would probably be the most effective yet least intrusive; for example it could have some kind of indicator color on the icon if its pending.

For anyone still having this issue, you can run this tool as Administrator and it will clean up leftovers from the legacy client (only run after you have uninstalled the legacy client): https://build.jbob.io/Tools/CleanLegacyClient.exe.

@jpaul said in network printers not coming in when imaging with fog 1.2.0:

ill not populate even after all the forced group policy updates per machine . Has anyone found the the problem might be with fog imagining or is it just something wrong with our group policies,

@jpaul it sounds like an issue with your GPO. Is there also a reason why you just started using 1.2.0? It’s fairly outdated and doesn’t support newer operating systems (like Windows 10) very well.

@tomtom what os is the client on? When did reg edit snapin a stop working?

@Scott-Adams said in Computers not joining domain after password change:

I had thought about that as a work around, didn’t think that would be the actual solution though. Thanks @Wayne-Workman

@Scott-Adams You’d need to post the fog.log from a problematic host.

@Seydoo uninstalling / installing the client requires additional steps (https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Reset_encryption_data). As for macs, if they are pending, then they do infact exist on that host (they could be tunnel interfaces, VirtualBox interfaces, or any other kind of virtual adapter),

Also be sure to check the fog.log to ensure that it is still the private key not found error, and not a new one now. Just because the client is still not authenticating doesn’t mean the underlying issue hasn’t changed.

Your original issue Private key not found is strictly a server issue. How did you copy over your installation to the new server? On fresh installs or upgrades this issue is not present, indicating its likely a permission issue from when you migrated the server, or something alike. @Tom-Elliott would be best equipped to tell you which files / permissions to check.

@Seydoo did you rerun the installer with --recreate-keys?

@rmmadden said in Normal Snapin deploy .reg file:

I am guessing it has to be doing this somewhere on execution.

Correct. Would you mind posting the .reg file? I know you switched to GPO, but I’m curios as to why its not applying when running as SYSTEM.

@rmmadden said in Normal Snapin deploy .reg file:

As a followup question/clarification - does the new client (0.11.12) operate differently in terms of operating user on snapin installs (than the old version did [.10 I think])?

@rmmadden it’s likely the registry keys that were being edited, and their path (e.g. were they under HKEY_CURRENT_USER ?). As for the service executing snapins, it is fairly similar to how the legacy client operated (minus the security changes and optimizations of course).

@Seydoo did you follow these steps: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server ?

If you have completey copied over the snapins directory (including hidden files), then re-run the fog installer on the new server with the --recreate-keys flag present (this is all described in the wiki article).

@Warget that is beyond the scope of the fog forums. You could try posting on spiceworks.

@george1421 the problem is likely that he is deleting hosts and then importing them (I’m not sure if a CSV export stores this information). This is why I advised directly modifying the SQL database.

@anthony-delarosa in my opinion your best approach would be to have a script setup or something that changes the hostnames in the SQL database. For example if you wanted to slowly roll out the changes, the script could do 50 at a time, or it could wait until sunday night and then do all of them at once. Once changed in the DB, the fog client would receive the new hostname and apply the change almost instantly.

@Warget like @Scott-Adams mentioned, WSUS is specifically built to handle exactly this. However, if you really want to use a snapin, look into using a powershell script for the easiest approach (https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc is a good library). As for .dmgs, as long as OSX is running the client, you can make a bash script do it (e.g. http://stackoverflow.com/a/22940943) inside of a snapin pack.

@Hanz 0.11.12 logs a lot less information now (anything that can already be seen on the server). This includes the tasks of PowerManagement. Tasks will still work, but it will not log about scheduling / unscheduling them unless you are running a debug build of the client.

@prophitt this really isn’t a “fog” issue. Like @Tom-Elliott said, snapins, like any service, runs as the SYSTEM account. A lot of applications may have issues doing stuff like shortcuts if they didn’t take SYSTEM into account.

@prophitt Some clarifications:

• This script also installs the messenger? And that part works?
• If you were to run this script manually, does it work as expected?

@x23piracy @fry_p Basically I finally had the time to rework how domain joining / renaming happened to only require 1 reboot to apply all the changes.

@pmonstad @Fernando-Gietz 0.11.12 includes the es-ES, eu, no translations, thanks for providing them! @x23piracy Thanks for the Italian translations! If we could get another person to ok the Italian translations I’ll add them in the next client release.

@utopia 0.11.12 fixes the banner downloading issue. I agree the wiki could use some updating on rebranding, @Wayne-Workman would you be able to add a section on it when you have some spare time? You can use https://news.fogproject.org/fog-client-v0-11-6-released/ as a template.