Slow to Join Domain/Rename Host with Windows 10 / Server 2008

[george1421]

What is your client check in timer? The fog client will only do stuff when it checks into the fog server. [FOG Configuration->FOG Settings->FOG CLient->FOG_CLIENT_CHECKIN_TIME]

I can say I don’t use the fog client for renaming or connecting to the domain. I use the unattend.xml file and a post install script to bring it in line with FOG. While its a bit more complex to setup its pretty fast.

[Wayne Workman]

said in Slow to Join Domain/Rename Host with Windows 10 / Server 2008:

however after the client boots up after image and has a few restarts and gets to the desktop

Can you explain that part more? Where are these reboots happening? And can you post a full FOG Client log from one of the systems from the moment that it is done rebooting after domain joining please? The log will let us know what’s happening. It’s here: C:\fog.log

[Tom Elliott]

From the sounds of things, your image is using legacy or the new client?

Sorry if it’s the new one, but this sounds an aweful lot like it.

[rstockham23]

@Tom-Elliott I thought I was using one of the newer clients. It is version 0.11.1
Is that too old to work properly with Win10?

[rstockham23]

@george1421 It is set to 60, which I assume is seconds. However it’s taking about 10 minutes consistently before it changes the name.

[rstockham23]

@Wayne-Workman Wayne…Ignore the first part of that message about reboots. I was just referring to the sysprep stuff and it actually only reboots once. Once it settles and autologins to the desktop, it is taking consistently and approximately 10 minutes before it restarts to change the name of the computer and then it will restart one more time after that to join the domain. It’s that 10 minute time period that I’d like to trim down. Attached is my fog.log file from a computer that I just imaged. For your reference, the time that the computer first auto logged in to the Desktop was 12:57. The reboot for the name change happened at 1:07 and the domain join reboot at 1:09. 0_1485540857343_fog.log

[Joe Schmitt]

@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?

[george1421]

@Joe-Schmitt And I noticed the reboot delay was set to 60 seconds. So that would put it just over 10 minutes from cold start to reboot.

[rstockham23]

@Joe-Schmitt Good catch. I did not set it to delay. Not sure why it’s taking so long to start. That is a bit strange though, because early on when we were having this issue, I looked at services.msc and confirmed that the Fog Client service was running and it still wasn’t rebooting for quite some time. Unless the gui said it was running when in fact it wasn’t. I’ll have to watch that more closely next time and see if indeed that’s what is going on. Still strange that it’s taking that long for the service to kick on.

[george1421]

@rstockham23 OK just to be clear here.

You are installing the fog client in the reference image, but as soon as you install it you shut it down and disable the fog client service then sysprep the image and capture it with fog.

When you clone the image to a new computer, you have the setupcomplete.cmd script re-enable the service and then start the service? Is that the basic workflow?

[rstockham23]

@george1421 That’s correct…I have done all of those things. Install client, disable service, run sysprep command to start service again. I just tried reimaging one to follow it and after it gets to the desktop for the first time, I checked windows services and it shows Fog Service as Automatic and Running, but yet it isn’t renaming/rebooting. I then manually restarted the Service and it still sits there for about 10 minutes after restarting the service before it actually does anything.

[rstockham23]

@george1421 @Joe-Schmitt @Tom-Elliott @Wayne-Workman Looking closer at the Fog Log it appears to me that at first, it’s not Authenticating correctly. It’s checking every 60 seconds and the first few times it checks, it’s getting this:

1/27/2017 2:04 PM Middleware::Communication Download: http://10.23.8.45/fog/management/other/ssl/srvpublic.crt
1/27/2017 2:04 PM Data::RSA FOG Server CA cert found
1/27/2017 2:04 PM Data::RSA ERROR: Certificate validation failed
1/27/2017 2:04 PM Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: The signature of the certificate cannot be verified. (NotSignatureValid)
1/27/2017 2:04 PM Middleware::Authentication ERROR: Could not authenticate
1/27/2017 2:04 PM Middleware::Authentication ERROR: Certificate is not from FOG CA

Then when it does finally authenticate, it’s just a minute or two before it actually get’s the name change in order and reboots. Any ideas why the authentication errors early on after it boots up?

[george1421]

@rstockham23 It sounds like you are doing everything right there. Unfortunately I can’t give you a base line of what it should look like since I use the unattend.xml file to rename the computer, and connect it to AD. I don’t use the fog client for that part. Possibly one of the other @Moderators that use the FOG client properly can give an idea if this 10 minute wait period is normal.

[Joe Schmitt]

@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]

@Joe-Schmitt I tried manually rebooting after the first login and it didn’t make a difference. After the reboot, it still took the same amount of time to restart on it’s own, rename, etc. I did try changing the FOG_CLIENT_CHECKIN_TIME from 60 seconds to 30 seconds and it did approximately cut the wait time down in half. I’m not sure what time is too short…if that’s too much network chatter or not, but it helps. Problem not really solved, but it is better than 10 minutes. Problem still seems to be that it takes multiple attempts for the client to Authenticate to the server.

[Joe Schmitt]

@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.