Computers Join Domain before Hostname Changes

[george1421]

For clarity, will you confirm that you DO NOT have the following section in your unattend.xml file? The reason why I ask is that I could see a potential for a race condition between the unattend.xml connecting the device to the domain and then the fog client doing its bit since the fog client does have a check in interval that also impacts timing of when things happen.

<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

[zpoling]

@Wayne-Workman The error stated in the OP doesn’t occur if I tell the machine to join the domain after the fog service is done with post-image tasks.

 6/8/2016 11:57 AM Client-Info Client Version: 0.10.6
 6/8/2016 11:57 AM Client-Info Client OS:      Windows
 6/8/2016 11:57 AM Client-Info Server Version: 7541
 6/8/2016 11:57 AM Middleware::Response Success
 6/8/2016 11:57 AM HostnameChanger Checking Hostname
 6/8/2016 11:57 AM HostnameChanger Removing host from active directory
 6/8/2016 11:57 AM HostnameChanger ERROR: Required ADDom information is missing
 6/8/2016 11:57 AM HostnameChanger Renaming host to DIESEL-1
 6/8/2016 11:57 AM Power Creating shutdown request
 6/8/2016 11:57 AM Power Parameters: /r /c "FOG needs to rename your computer" /t 0
 6/8/2016 12:00 PM Client-Info Client Version: 0.10.6
 6/8/2016 12:00 PM Client-Info Client OS:      Windows
 6/8/2016 12:00 PM Client-Info Server Version: 7541
 6/8/2016 12:00 PM Middleware::Response Success
 6/8/2016 12:00 PM HostnameChanger Checking Hostname
 6/8/2016 12:00 PM HostnameChanger Hostname is correct

***Hostname Logs show same as above 6 lines until told to join domain***

 6/8/2016 12:09 PM Client-Info Client Version: 0.10.6
 6/8/2016 12:09 PM Client-Info Client OS:      Windows
 6/8/2016 12:09 PM Client-Info Server Version: 7541
 6/8/2016 12:09 PM Middleware::Response Success
 6/8/2016 12:09 PM HostnameChanger Checking Hostname
 6/8/2016 12:09 PM HostnameChanger Hostname is correct
 6/8/2016 12:09 PM HostnameChanger Success, code =  0
 6/8/2016 12:09 PM Power Creating shutdown command in 60 seconds
 6/8/2016 12:09 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  \"message\": \"This computer needs to perform maintenance.\"\r\n}"
}
 6/8/2016 12:09 PM Bus Emmiting message on channel: Power
 6/8/2016 12:09 PM Service Power operation being requested, checking back in 30 seconds
 6/8/2016 12:11 PM Main Overriding exception handling
 6/8/2016 12:11 PM Main Bootstrapping Zazzles
 6/8/2016 12:11 PM Controller Initialize
 6/8/2016 12:11 PM Entry Creating obj
 6/8/2016 12:11 PM Controller Start

 6/8/2016 12:11 PM Service Starting service
 6/8/2016 12:11 PM Bus Became bus server
 6/8/2016 12:11 PM Bus {
  "self": true,
  "channel": "Status",
  "data": "{\r\n  \"action\": \"load\"\r\n}"
}
 6/8/2016 12:11 PM Bus Emmiting message on channel: Status
 6/8/2016 12:11 PM Client-Info Client Version: 0.10.6
 6/8/2016 12:11 PM Client-Info Client OS:      Windows
 6/8/2016 12:11 PM Client-Info Server Version: 7541
 6/8/2016 12:11 PM Middleware::Response Success
 6/8/2016 12:11 PM HostnameChanger Checking Hostname
 6/8/2016 12:11 PM HostnameChanger Hostname is correct
 6/8/2016 12:11 PM HostnameChanger Host is already joined to target domain

[zpoling]

@george1421 That string is not in our unattend file.

[george1421]

@zpoling ok as a final test (just to say absolutely the fog client is suspect here).

Can you either disable the fog service when you deploy to this computer so that it never runs on the target even for 1 second? In my case when I install the fog client on the reference image I stop and disable the service immediately, then proceed with the MDT install of the other applications.

Then when the target system completes the installation process just before the login screen comes up I run the commands in the setupcompleted.cmd to set the service to auto start and then start the service. At that time then the fog client does what ever it has to do. If you enable the fog client the same way, then just disable the code that changes the fog client startup from disabled to auto. This way the fog client never runs.

So then the things to check for becomes this:

1. The client should never ever connect to AD
2. The name of the machine will be what ever windows selects as the default computer name. And this will not change.

Make sure these settings are consistent for 30 minutes. Then set the fog service to auto start and then start the service. Observe and report what happens. Understand I’m not doubting that this is happening, I’m trying to isolate the fog service running from the OOBE setup doing something unexpected.

[zpoling]

@george1421 That’s how I have our fog service set up as well; Setupcomplete.cmd sets it back to auto. I’m assuming you want me to disable the early hostname changer too since you said the name of the machine should be the Windows default.

To note before I start this; if the client isn’t told to join the domain, it wont, even if the fog service is running.

I’ll get back to you with the results!

[Wayne Workman]

@zpoling I would leave early host name change turned on, and disable the code that re-enables the fog service just as George described. This test is to determine what’s going on with the hostname.

[george1421]

@Wayne-Workman I would suggest to turn off everything that could change the machine. We need to establish a normal baseline. I know it is a bit of a pain to go this route. But the first step is to turn everything off, then one thing on at a time. The next step after getting a baseline is to turn on the early name changer and see what that does.

I have to revert to the old adage of: You have to find out where the problem isn’t to be able to find out where it really is.

[zpoling]

I’m starting the image process as I am typing this.

The fog service has been disabled in this image and the setupcomplete.cmd has been removed, so the service should not start again. The early hostname changer has been disabled as well.

Imaging is complete. The unattended setup is occurring now.

Just logged on for the first time. It has a default hostname and the fog service is not running.

After 30 minutes, nothing has changed. Nothing has called for the computer to restart.

After a manual restart, the same has been observed. The hostname is still default and the service is not running. I am going to start the service and see what happens. It should try to change the hostname and join the domain, as both settings are there. I will check the default computers OU and see what appears after the first reboot.

After the manual reboot, the computer made it to the log on screen but soon rebooted. The default computer name never showed up into the default OU, but the specified name on fog did. This means that the original issue did not occur.

 6/9/2016 12:43 PM Client-Info Client Version: 0.10.6
 6/9/2016 12:43 PM Client-Info Client OS:      Windows
 6/9/2016 12:43 PM Client-Info Server Version: 7541
 6/9/2016 12:43 PM Middleware::Response Success
 6/9/2016 12:43 PM HostnameChanger Users still logged in and enforce is disabled, delaying any further actions
 6/9/2016 12:45 PM Client-Info Client Version: 0.10.6
 6/9/2016 12:45 PM Client-Info Client OS:      Windows
 6/9/2016 12:45 PM Client-Info Server Version: 7541
 6/9/2016 12:45 PM Middleware::Response Success
 6/9/2016 12:45 PM HostnameChanger Users still logged in and enforce is disabled, delaying any further actions
 6/9/2016 12:48 PM Client-Info Client Version: 0.10.6
 6/9/2016 12:48 PM Client-Info Client OS:      Windows
 6/9/2016 12:48 PM Client-Info Server Version: 7541
 6/9/2016 12:48 PM Middleware::Response Success
 6/9/2016 12:48 PM HostnameChanger Checking Hostname
 6/9/2016 12:48 PM HostnameChanger Removing host from active directory
 6/9/2016 12:48 PM HostnameChanger The machine is not currently joined to a domain, code =  2692
 6/9/2016 12:48 PM HostnameChanger Renaming host to TESTLP
 6/9/2016 12:48 PM Power Creating shutdown request
 6/9/2016 12:48 PM Power Parameters: /r /c "FOG needs to rename your computer" /t 0
 6/9/2016 12:48 PM HostnameChanger Unknown Return Code:  1364
 6/9/2016 12:49 PM Client-Info Client Version: 0.10.6
 6/9/2016 12:49 PM Client-Info Client OS:      Windows
 6/9/2016 12:49 PM Client-Info Server Version: 7541
 6/9/2016 12:49 PM Middleware::Response Success
 6/9/2016 12:49 PM HostnameChanger Checking Hostname
 6/9/2016 12:49 PM HostnameChanger Hostname is correct
 6/9/2016 12:49 PM HostnameChanger Success, code =  0
 6/9/2016 12:49 PM Power Creating shutdown request
 6/9/2016 12:49 PM Power Parameters: /r /c "Host joined to Active Directory, restart required" /t 0

Does this look normal? If any of you would like me to test another factor, just let me know what to do and I’ll get it done.

On another note, I imaged 20 computers this morning while I was watching this test machine was working. I told them not to join the domain until after they were all correctly named and they all joined the domain correctly. The issue only happens when the machine has not been renamed already.

[Tom Elliott]

@zpoling said in Computers Join Domain before Hostname Changes:

6/9/2016 12:49 PM Client-Info Server Version: 7541

Why such an old version of FOG?

[zpoling]

@Tom-Elliott We never update fog unless we have major issues with it. Windows 10 was actually what made us get away from .32. Should I try updating it?

[Quazz]

@zpoling Basic rule of thumb for the trunk version is if you’re running into issues, updating might resolve it.

[zpoling]

@Quazz Ah. I was taught on the principle of “if it’s working, don’t fix it.” So even if it’s a small issue such as this, updating is the goto option? Fog’s updating as I type. I’ll try that from now on. I’ll report back if the issue keeps happening.

Thanks for all of your help, everyone!

[Quazz]

@zpoling I probably update it 3 times a day or more, but then again I’m in the testers group for a reason.

[george1421]

Just be aware that the update process is a little aggressive on the development trunk (or sometimes just called trunk). Once 1.3.0 is finally released then the need to update every so often will stop (until they are ready to release fog 2.0, which I would expect to have a pretty long trunk release too).

[zpoling]

After updating Fog, the issue is still occurring.

[zpoling]

@Quazz After updating Fog, should I reboot the server?

[Wayne Workman]

@zpoling so at this point, after those tests, we can safely say the actions of the fog client are causing the issue.

However I still don’t understand why… there’s a thread around here where joe lists the order in which the client does things. I’ll try to find it.

[Wayne Workman]

@Joe-Schmitt said in Fog Client - Snapins run after computer rename/domain join:

@networkguy Here is the order in which the modules are run every time:

• ClientUpdater
• TaskReboot
• HostnameChanger
• SnapinClient
• PrinterManager
• GreenFOG
• UserTracker

Here he lists the order of operations. Host name changer also does the domain joining, but as you see in the logs, the name change happens first.

Something is causing the client to think the host name isn’t correct after having set it already once.

What other third party applications do you have installed?

[george1421]

@Wayne-Workman While I can’t comment of the fog client, typically after you do a name change (via powershell or vbscript) you must reboot to update all of the services. Just changing the registry isn’t sufficient. Once that was done then you could connect it to AD.

Now that I think about it, you may be able to get away with updating the registry, restarting the workstation service then connecting the workstation (but I haven’t tried that).

[Wayne Workman]

@zpoling what is the fog client Grace time out and check in timeout set to on your system?