I’m 100% certain that this is not the case of your issues. Your being logged in has no impact on how the hostname changing operates.

I have, however, found that many different key’s are used even if the “windows path” is the same. Linux, being case sensitive and all, is changing the keys, and most likely the client is checking the very same keys. Those keys are being updated, but it’s not the keys that the main windows system is actually looking at for the display of the names.

I’m updating the init’s in hopes to better approach this, but I really don’t know.

It occurs to me that I’m logging in to the machines running client using a user account that does not have admin rights. Any chance that is keeping the hostname check/set from happening correctly? I’m not on site right now, so I can’t do the simple test of logging in as an admin.

The hostname listed for DC:FE… does match what I set when I registered the host and what I see in the FOG host list, but locally that machine still displays the original hostname from the captured image.

See what name it says the host is registered as, or does it say the host is not registered? What we are doing here is manually passing MAC addresses to the boot.php mechanism, which generates iPXE boot scripts based on the MAC addresses given.

Only the DC:FE… address is an actual host. It was the source machine for the log file and does appear in my list of hosts. I also checked the MAC address of the FOG server and it does not match the other addresses from the log.

The local host names do not match the FOG interface. All of the machines show the same Windows generated host name from the machine that was used to capture the image. In the FOG interface I have registered the hosts as ebgc-001, ebgc-002, …

Can you check the actual hostname on the computer and compare it against the hostname set in the web interface? Maybe they are the same? Do you know that by default, fog attempts renaming during imaging?