@RobTitian16 why do you have: <Domain>.\</Domain> ? Also look at this thread: https://forums.fogproject.org/topic/9394/trying-to-sysprep-windows-10-to-upload-to-fog-please-help . The user had a very similar issue (boot loop due to a bad unattend file), there’s several Windows 10 unattend files posted from various users in our forums.

@ryan.mckenzie so this is definitely an issue with your unattend.xml then. Mind posting the file and maybe one of the @Moderators or @Testers, who are familiar with sysprep can take a look?

@Tony-Ayre just wanted to acknowledge that this is definitely a limitation of FOG backend that we were handed when @Tom-Elliott picked up this project. Our current rewrite addresses this problem (and most scaling problems), but it’ll be a quite a bit before FOG 2.0 is ready.

@Lenain I’ve been working on better sysprep integration, so at some point there should be a release that handles it automatically.

@asbenavides Firefox does not publish MSIs for their software. Firefox’s offline exe installer already has a silent mode: setup.exe -ms (assuming it hasn’t changed). Or see if that place offers an offline msi, and not a stub. Ultimately however, this is no longer a client issue.

@asbenavides that means its an issue with your snapin:

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 1/31/2017 2:36 PM Client-Info Client Version: 0.11.9
 1/31/2017 2:36 PM Client-Info Client OS:      Windows
 1/31/2017 2:36 PM Client-Info Server Version: 1.3.4
 1/31/2017 2:36 PM Middleware::Response Success
 1/31/2017 2:36 PM SnapinClient Snapin Found:
 1/31/2017 2:36 PM SnapinClient     ID: 155
 1/31/2017 2:36 PM SnapinClient     Name: Firefox 50.1
 1/31/2017 2:36 PM SnapinClient     Created: 2017-01-31 20:36:25
 1/31/2017 2:36 PM SnapinClient     Action: 
 1/31/2017 2:36 PM SnapinClient     Pack: False
 1/31/2017 2:36 PM SnapinClient     Hide: False
 1/31/2017 2:36 PM SnapinClient     Server: 
 1/31/2017 2:36 PM SnapinClient     TimeOut: 0
 1/31/2017 2:36 PM SnapinClient     RunWith: msiexec.exe
 1/31/2017 2:36 PM SnapinClient     RunWithArgs: /i
 1/31/2017 2:36 PM SnapinClient     Args: /quiet
 1/31/2017 2:36 PM SnapinClient     File: firefox_setup_stub_50.1.0.msi
 1/31/2017 2:36 PM Middleware::Communication Download: http://192.168.119.130/fog/service/snapins.file.php?mac=F8:B1:56:D3:8E:86|E4:F4:C6:4C:33:F2|00:15:83:EA:BE:70||00:00:00:00:00:00:00:E0&taskid=155
 1/31/2017 2:36 PM SnapinClient C:\Program Files (x86)\FOG\tmp\firefox_setup_stub_50.1.0.msi
 1/31/2017 2:36 PM Bus {
  "self": true,
  "channel": "Notification",
  "data": "{\r\n  \"title\": \"Installing Firefox 50.1\",\r\n  \"message\": \"Please do not shutdown until this is completed\"\r\n}"
}
 1/31/2017 2:36 PM Bus Emmiting message on channel: Notification
 1/31/2017 2:36 PM SnapinClient Starting snapin...
 1/31/2017 2:36 PM SnapinClient Snapin finished
 1/31/2017 2:36 PM SnapinClient Return Code: 0
 1/31/2017 2:36 PM Bus {
  "self": true,
  "channel": "Notification",
  "data": "{\r\n  \"title\": \"Firefox 50.1 installed\",\r\n  \"message\": \"Installation has finished and is now ready for use\"\r\n}"
}
 1/31/2017 2:36 PM Bus Emmiting message on channel: Notification
 1/31/2017 2:36 PM Middleware::Communication URL: http://192.168.119.130/fog/service/snapins.checkin.php?taskid=155&exitcode=0&mac=F8:B1:56:D3:8E:86|E4:F4:C6:4C:33:F2|00:15:83:EA:BE:70||00:00:00:00:00:00:00:E0&newService&json
------------------------------------------------------------------------------

The snapin runs and returns an exit code of 0. One thing I noticed is you’re using the stub installer. How come? The stub installer requires downloading a lot of additional files during installation (it’s basically just a wrapper that downloads firefox).

@asbenavides

 1/31/2017 2:28 PM Middleware::Response Invalid security token

You need to hit Reset Encryption Data on this host in the fog web portal.

@asbenavides on the computer with the client it will either be at C:\fog.log or C:\Program Files (x86)\FOG\fog.log

For anyone following this thread, I am working with @ryan.mckenzie via chat.

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

@ryan.mckenzie at this point it’s an issue with how the image is being made (either your unattend file or setupcomplete) before capturing. Could you post both?

@Raj-G the printer tool can be downloaded form here: https://github.com/FOGProject/fog-client/releases/tag/0.11.9

@ryan-mckenzie how many times does it restart? Because it should normally restart 3 or so times (so the client can undo the generalization done by sysprep)

@rstockham23 I meant reboot once the entire domain process is complete, and then check how long the service takes to startup. (This can be done by monitoring the fog.log by using get-content -wait C:\fog.log from powershell). If there’s an authentication issue again, please post the entire fog.log after you test the reboot.

You done messed up @Tom-Elliott.

@rstockham23 @george1421 the 10 minute wait period is not normal.

@rstockham23 after all of the reboots are completed, can you try an additional reboot and see if the client still takes an unusually long period of time to startup?

@rstockham23 from your log file:

 1/27/2017 1:07 PM Service Starting service
 1/27/2017 1:07 PM Bus Became bus server
 1/27/2017 1:07 PM Bus {
  "self": true,
  "channel": "Status",
  "data": "{\r\n  \"action\": \"load\"\r\n}"
}
 1/27/2017 1:07 PM Bus Emmiting message on channel: Status
 1/27/2017 1:07 PM Service Invoking early JIT compilation on needed binaries

<skip>

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 1/27/2017 1:07 PM Client-Info Client Version: 0.11.7
 1/27/2017 1:07 PM Client-Info Client OS:      Windows
 1/27/2017 1:07 PM Client-Info Server Version: 1.3.0
 1/27/2017 1:07 PM Middleware::Response Success
 1/27/2017 1:07 PM HostnameChanger Checking Hostname
 1/27/2017 1:07 PM HostnameChanger Hostname is correct
 1/27/2017 1:07 PM HostnameChanger Attempting to join domain
 1/27/2017 1:07 PM HostnameChanger Success, code =  0
 1/27/2017 1:07 PM Power Creating shutdown command in 60 seconds
 1/27/2017 1:07 PM Bus {
  "self": true,
  "channel": "Power",
  "data": "{\r\n  \"action\": \"request\",\r\n  \"period\": 60,\r\n  \"options\": 2,\r\n  \"command\": \"/r /c \\\"Host joined to Active Directory, restart required\\\" /t 0\",\r\n  \"aggregatedDelayTime\": 0,\r\n  \"message\": \"FOG needs to perform maintenance on this computer.\"\r\n}"
}
 1/27/2017 1:07 PM Bus Emmiting message on channel: Power
------------------------------------------------------------------------------

As you can see the client service is started at 1:07PM and within that very same minute it begins the restart process. This means the client is operating as expected, but the FOGService is starting late. Did you set it to be a delayed start?

@ryan.mckenzie The lines for setupcomplete should be placed at the end (since once the restart command is issued, the script can’t do anything else).

@ryan-mckenzie if you are using the new client, please follow the instructions here: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@Wayne-Workman /S is standard and has been around in teamviewer for awhile (at least starting in the early 201X’s). The reason it’s /S is because Teamviewer uses NSIS to package their installers (which a simple hexdump of the installer’s manifest would reveal), and NSIS uses /S as a convention.