Computers Join Domain before Hostname Changes

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

[zpoling]

@Wayne-Workman

Grace timeout is set to 60, check in timeout is 600.

As far as third party apps, we have Office 2016, Java, and Silverlight. The install is just standard Windows 10 Enterprise.

[Wayne Workman]

@zpoling This issue just makes no sense to me. Why only you? Why only your site? At work, we have 6 independent stand-alone fog servers at 6 sites, and are in the process of building a large 14 node system with a central server for all the other sites and everything is fine. Also, everything is fine for everyone else here on the forums. I imagine we’d be swamped with threads related to this issue if it was a genuine bug of some kind.

So the question remains is… why you?

The questions I’ve been asking have kinda been about that question. 3rd party apps, what’s different, etc.

Maybe pick your own brain for a bit and figure out what it is that you guys do differently?
What does DNS? Do you have DNS issues? What is doing DHCP? What settings in fog are unique to you?

[Tom Elliott]

Are your images sysprepped? If they are sysprepped, are they setup to define a random computer name?

The only thing I can think is the “active computer name” is not matching the “set computer name”.

Is HOSTNAME_EARLY enabled under FOG Configuration Page->FOG Settings -> (I forget the sub menu item)?

If you disable HOSTNAME_EARLY does the hostname rename and join AD appropriately?

I ask these questions because there have been some work to the init’s in an attempt to correct similar type bugs where the hostname would say it was correct, but to the admin’s the hostname was not correct. The join domain would work, but would use the “incorrect” name (if I do indeed recall correctly – maybe it was the other way around, joining AD would be correct, but hostname would still be displayed incorrectly). I ask about sysprep because in the case they are, if the <ComputerName>*</ComputerName> is set, there’s not much the hostname_early feature can do as the computer name is randomly generated. Where this get’s tricky is the OS hasn’t loaded quite yet and the AD Join element might work perfectly but setup the “incorrect hostname” leaving FOG to appear as if it IS joining the domain before the hostname change has taken place, but really the FOG Client had checked the hostname before the “randomly generated” name was recreated. The hostname check sees it is correct, then continues on (at which point SYSPREP has renamed the host) and it tries to join the Domain, but it’s joining using the incorrect hostname.

This is just a guess, a wild stab in the dark. This further adds credence to the last paragraph of the FOG Client wiki: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

I’m going to guess, all this troubleshooting and the client is actually ACTIVE in the SYSPREP state causing unforeseen consequences?