Best posts made by Joe Schmitt

@dolf if you can, after you update your image could you try deployments with early hostname changer both on and off? If I’m right the issues that early hostname changer had with sysprep should have been fixed.

@matthieu-jacquart you should be able to update your signature now.

The shutdown prompt requires the user service to be running. More than likely what you are seeing is an effect of the auto update process. There is a bug where if a user is logged on during auto update, their user service is not started back up after the update. However, if they relogin in then all work properly.

If you select a batch script template you will notice you are missing the /c parameter.

@FantasyGamer @rwakc It’s back up now, thanks for letting us know.

The legacy client still has (or should have) compatibility with trunk.

7/29/2016 9:19 AM Data::RSA ERROR: Certificate validation failed
7/29/2016 9:19 AM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. (NotSignatureValid), A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. (NotTimeValid)
7/29/2016 9:19 AM Middleware::Authentication ERROR: Could not authenticate
7/29/2016 9:19 AM Middleware::Authentication ERROR: Certificate is not from FOG CA

Well there’s your problem. At some point you regenerated your FOG server root CA certificates, or setup a new server and didn’t transfer your keys.

@george1421 they are removed in the working/dev branch. Once v1.5.0 is stable, the changes will be merged to master.

@JJ-Fullmer correct, we are just pushing RC’s to trunk until we hit stable. After that normal trunk will resume.

https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@eseelke - @george1421 covered many of my initial reactions. With that said, I would be interested in seeing a benchmark of any performance loss (or even gain) of WIM vs FOG’s sector-level clones. As of right now the latest benchmark we’ve seen is that FOG is capable of deploying Windows 10 in about 2 minutes with well configured images, high network bandwidth, and fast hosts/clients.

I believe that we likely wouldn’t integrate WIM into the 1.X series. We are hoping to make some key architectural changes to FOG with the 2.X series, and as @george1421 mentioned, 1.X is “locked into” partclone, as the entire codebase is built around the assumption of its usage. FOG 2.X would have the potential to support non-partclone formats, as we are hoping to make it more agnostic in terms of what it ties into, so it may be worthwhile to investigate.

I will look into this when I get a chance. Could you describe in detail the hardware that has this issue and the OS config (e.g. if its sysprep please provide the unattend and setup complete) also the exact OS info. I need to figure out how to replicate this on my vms.

Is this right after deployment? If so try disabling early hostname changer.

@BrendoJohnso simply run sudo mv .... where you replace .... with the correct arguments. sudo just elevates a command to ensure it has root-level privileges.

@Tom-Elliott is correct that the GUI setting I pointed to is the best, and safest, approach for setting the option as the DB schema is subject to change with each FOG release.

Have you tried unassigning the printers, letting fog client remove them, and then reassigning them?

@pixomondo said in New Fog Client - The Computer Restarted Unexpectedly:

fog prep VM reboots after sysprepping

Two things:

1. FOGPrep is no longer needed
2. https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

I would need to see the exact error message.

@Wayne-Workman printer manager helper only shows TCP/IP printers. Not network printers.

@pixomondo said in New Fog Client - The Computer Restarted Unexpectedly:

In the past I used to deactivate the fog client to prevent it from rebooting the machine while sysprep was running and this seemed to have fixed it again

That’s exactly what the link I gave you (the wiki article on sysprepping) says.

Just try disabling it, and re-imaging.