Windows 10 1709 and Client 11.14

[Joe Schmitt]

@UWPVIOLATOR I see no indication of a second reboot even being scheduled or attempted in the logs. There is only the single reboot done to rename and join AD:

------------------------------------------------------------------------------
--------------------------------HostnameChanger-------------------------------
------------------------------------------------------------------------------
 2/20/2018 10:23 AM Client-Info Client Version: 0.11.14
 2/20/2018 10:23 AM Client-Info Client OS:      Windows
 2/20/2018 10:23 AM Client-Info Server Version: 1.4.4
 2/20/2018 10:23 AM Middleware::Response Success
 2/20/2018 10:23 AM HostnameChanger Checking Hostname
 2/20/2018 10:23 AM HostnameChanger Renaming host to MMSD-LPT-119719
 2/20/2018 10:23 AM HostnameChanger Joining domain
 2/20/2018 10:23 AM HostnameChanger Success, code =  0
 2/20/2018 10:23 AM Power Creating shutdown command in 60 seconds
 2/20/2018 10:23 AM Bus Emmiting message on channel: Power
------------------------------------------------------------------------------

Did not reboot after Joining Domain

I am not seeing any place where the client even should have done a reboot besides the one instance it did (which is the exact same as in the other logs you posted), and so by all accounts 0.11.14 seems to be operating exactly as expected.

If there is some shutdown the snapin you run should do, then that is a problem with the snapin, not the client. (As a note, the snapin you run seems to be exiting early, while spawning some kind of new process that retains a file lock on the installer, so something is definitely strange with your snapin file)

[UWPVIOLATOR]

@joe-schmitt Correct but it should be rebooting after joining domain.

[Joe Schmitt]

@UWPVIOLATOR it does:

 2/20/2018 10:24 AM Power --> API call returned 1, will re-attempt in 5 minutes
 2/20/2018 10:26 AM Main Overriding exception handling

This reboot (which you said was successful) corresponds to these changes:

 2/20/2018 10:23 AM HostnameChanger Renaming host to MMSD-LPT-119719
 2/20/2018 10:23 AM HostnameChanger Joining domain
 2/20/2018 10:23 AM HostnameChanger Success, code =  0

The 0.11.X series performs all domain changes in a single reboot, whereas old versions required multiple reboots.

When the client starts back up after the single reboot, we can see that the name is correct, and the domain is joined:

 2/20/2018 10:26 AM HostnameChanger Checking Hostname
 2/20/2018 10:26 AM HostnameChanger Hostname is correct
 2/20/2018 10:26 AM HostnameChanger Attempting to join domain
 2/20/2018 10:26 AM HostnameChanger Host already joined to target domain

If there is an issue here, its not with reboots. Is there some extra information I’m unaware of? For example is the client reporting that its joined to the domain, but in reality its not?

[UWPVIOLATOR]

@joe-schmitt At what version did Rename and Join domain become one task? So I get a reboot but it doesn’t go back to the Lock Screen for Windows 10. After the 1 reboot it goes back in as admin. Is that how this new client is supposed to act?

Edit: I tested again without our Zen Snapin. The system stays logged in as Admin without intervention. It should be at the Lock Screen when its finished imaging, joining domain, and apply snapins.

[x23piracy]

@uwpviolator is it possible that you have a autologon in your unattend.xml? If so i had two autologons in the past until the client doesnt needed reboots twice anymore, since that point i reduced auto logons to 1 instead of 2.

I am not sure but i think it was 11.12…

https://news.fogproject.org/fog-1-4-0-officially-released/

New Features

New languages: es-ES, eu, no
Renaming a Windows computer and then joining a domain is now 2 times faster
Renaming a Windows computer inside a domain is now 3 times faster

[UWPVIOLATOR]

@x23piracy Yeah I do see a AutoLogon but its at 1. This was never an issue on previous FOG Clients. After the rename reboot it would put you back to lock screen.

[Joe Schmitt]

@UWPVIOLATOR - @x23piracy is correct, fog version v1.4.0 shipped with the client domain improvements. The fact that admin is staying logged in points to a simple unattend.xml configuration issue. I would assume that if you manually restarted, OR even just examine the computer while admin is logged in, you’d see the computer is domain joined.

I can’t speak to why its happening, but this is definitly outside the scope of the client’s responsibility.

[UWPVIOLATOR]

@joe-schmitt So question, Do we need Auto Login at all? I think it’s a legacy setting we had.

[Joe Schmitt]

@UWPVIOLATOR I don’t really see a need for it with the client, unless you have some special steps your image takes during that period.

[UWPVIOLATOR]

@joe-schmitt All we need is for FOGService to do its thing. So if that is not needed for it then I will remove it.

[UWPVIOLATOR]

@Joe-Schmitt @x23piracy With Windows 10 Fast Boot. If its enabled a reboot is not being registered so could that be why it keep logging back in? I know Fast Boot messes with run time as a reboot wont “reset” the counter but a shutdown will.

[Joe Schmitt]

@UWPVIOLATOR I’m not really sure to be honest, it could also be that the client is performing the first restart before admin can even log-in.

[x23piracy]

Hi,

in normal you don’t need any autologons, i just use it because i am working with windows 10 pro oem where you cannot have setupcomplete.cmd executed automatically, therefore i used the autologon stuff with first logon commands in my unattend.xml.

If you don’t need to do anything special remove autologons in your unattend.xml

Regards X23