The driver thing is interesting - and possibly could be part of things.
So today a colleague deployed to ~60 computers.
Half of them failed to start fog service after reboot from FOGClientupdate/renaming/joining domain.
Half of them worked fine.
The difference between them is a different model motherboard (Both ASUS, H61 and B75 based respectively)
The image used was made on a VM, with no drivers pre-installed for either motherboard/chipset. In theory, both would need drivers to be installed during OOBE, so I’m not so sure what…
The H61 based systems should be slower, but not by a whole lot, at least not for imaging tasks.
Anyways, if it is a driver update/WU based reboot, then this reg key will have been created. Could the fog client detect that, and instead of exiting, accelerate the reboot schedule somehow?
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending
Here is the relevant section of the log file - which looks ok, but looks like for some reason (scheduled reboot?) it did not reboot.
------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
6/27/2016 4:04 PM Client-Info Client Version: 0.11.2
6/27/2016 4:04 PM Client-Info Client OS: Windows
6/27/2016 4:04 PM Client-Info Server Version: 8263
6/27/2016 4:04 PM Middleware::Response Success
6/27/2016 4:04 PM HostnameChanger Checking Hostname
6/27/2016 4:04 PM HostnameChanger Removing host from active directory
6/27/2016 4:04 PM HostnameChanger The machine is not currently joined to a domain, code = 2692
6/27/2016 4:04 PM HostnameChanger Renaming host to HiLibLabBack4
6/27/2016 4:04 PM Power Creating shutdown request
6/27/2016 4:04 PM Power Parameters: /r /c "FOG needs to rename your computer" /t 0
6/27/2016 4:04 PM Bus {
"self": true,
"channel": "Power",
"data": "{\r\n \"action\": \"shuttingdown\"\r\n}"
}
6/27/2016 4:04 PM Bus Emmiting message on channel: Power
------------------------------------------------------------------------------
At this point, no snapins have run, and the computer does not reboot…I logged in via RDP:
6/27/2016 10:03 PM Main Overriding exception handling
6/27/2016 10:03 PM Main Bootstrapping Zazzles
6/27/2016 10:03 PM Controller Initialize
6/27/2016 10:03 PM Entry Creating obj
6/27/2016 10:03 PM Controller Start
6/27/2016 10:03 PM Service Starting service
6/27/2016 10:03 PM Bus Became bus server
6/27/2016 10:03 PM Bus {
"self": true,
"channel": "Status",
"data": "{\r\n \"action\": \"load\"\r\n}"
}
6/27/2016 10:03 PM Bus Emmiting message on channel: Status
------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
6/27/2016 10:03 PM Client-Info Version: 0.11.2
6/27/2016 10:03 PM Client-Info OS: Windows
6/27/2016 10:03 PM Middleware::Authentication Waiting for authentication timeout to pass
6/27/2016 10:03 PM Middleware::Communication Download: http://fog.XYZ.local/fog/management/other/ssl/srvpublic.crt
6/27/2016 10:03 PM Data::RSA FOG Server CA cert found
6/27/2016 10:03 PM Middleware::Authentication Cert OK
6/27/2016 10:03 PM Middleware::Communication POST URL: http://fog.XYZ.local/fog/management/index.php?sub=requestClientInfo&authorize&newService
6/27/2016 10:03 PM Middleware::Response Success
6/27/2016 10:03 PM Middleware::Authentication Authenticated
As you can see, for some reason (foguser?) the service restarted when a user logged in, and carried on - despite a pending reboot that never happened.
UPDATE: As of ~10:30PM, the machines that hadn’t finished the rename/reboot, rebooted on their own (must have been that scheduled power thing!) and started carrying on.
