Hostname Changer doesn't change hostname

  • Hey all, minor issue but searched around and couldn’t find a fix from any recent thread.

    I am booting a laptop to the iPXE and doing the full host registration step. Which is really nice because I can apply a lot of settings before imaging!

    I give the computer a hostname, windows key, etc. When I deploy the image, it changes the key and activates no problem, but the hostname doesn’t change. The unattend file doesn’t specify a hostname either. The log for fog on the C drive says under the Hostname Changer section that the key is correct, activated and nothing else to do.

    The host on the fog server sees the hostname that I give it during registration.

    I checked the command: hostname, and the hostname in the registry and they all show the same thing that the System properties show (which is a randomly generated name).

    Running Fog 1.3.0 RC8 on Centos 7.

    Appreciate any help and support.

  • Thanks for the tip @george1421 I’m not sure it works for the scenario I am working on, but none the less, good idea for future items too, more than just name changes.

  • Moderator

    @MattPayerle I’m just throwing this out there… You don’t “need” the fog client to change the target computer’s name. You can do the name change via a FOG post install script. This script runs just after the image has been deployed to the target computer and before the first oobe boot. A quick sed script will replace the computer name value in the unattend.xml file with the host name defined in FOG. But to use this method you do have to sysprep the image and use an unattend.xml file. This way the computer name is set the way it should be on the first oobe boot. You can also adjust the target OU and have the unattend.xml file connect the system to AD too. I’m not saying this is the best for your case, only an alternative that is pretty quick to setup and then forget about.

  • @Wayne-Workman hey, thanks for the information back. Sorry, I am certainly not trying to be a PITA for you guys, this product is awesome 🙂

    I do like the idea of having it automatically enabled during the full registration, or maybe allowing a setting that would make it automatic during full registration in case not everyone likes it. Also, totally understand the instantaneous name change part. That explains the reboot just fine and you are right, it would be normal to reboot at that time, just making sure that is what it was.

    Thanks again, happy to help test certain features out.

  • @Tom-Elliott I would suggest moving this enforce checkbox to the computer’s general page, somewhere close to the hostname. It would be more sensible there. Or perhaps even the host’'s Service Settings page, this would also be a better fit. Because this feature doesn’t just deal with Active Directory, it deals with the hostname too. Having it on the Active Directory page is a little misleading because of this. And I’d suggest it being defaulted to on since people so often ask about problems that are due to this, and since it cannot be set during full host registration. It should just be on.

    I’d also recommend new labeling for the checkbox. Something that specifically states exactly what it does, like:
    Enforce hostname and Active Directory settings even when users are logged in?

    I’d also suggest changing the legacy password field from what it is to:

    Domain Password Legacy
    (Must use FOG Crypt)

  • @MattPayerle Alright, you asked a few questions and made some good points that I’ve also thought about in the past too.

    The option to enforce should be a default IMO - @Tom-Elliott.

    With the checkbox ticked, Yeah it would reboot to change the hostname whether anyone is logged in or not - and not give warning either because it’s being “Enforced”. This is not a half-hearted enforce, this is full-hearted enforcing, it gets it done. This is a good thing. If you want a computer’s name changed or joined to the domain - and you’re enforcing this, yes you’d absolutely want it to happen immediately whether people are logged in or not. Most cases, they will not be logged in though. You’d be imaging, or provisioning new computers, or be dealing with a specific issue where someone asked you to fix said thing - so they would expect you to be working on it.

    Active directory settings are not required for hostname changing to be enforced. If you look at the picture I posted below, that’s for one of my test boxes at home. You see that the Active Directory fields are blank - because at the moment I don’t have a test domain setup at home. But I still use the enforce option in there.

  • @Wayne-Workman Yes, sorry, I thought I had this in my notes. Not adding these machines to a Domain, just imaging on a workgroup. But yes, we have the same issue at my company, +/- 5 minutes of the DC’s time or else Kerberos authentication will block domain activity. Sadly, not joining one here.

    So I tested that checkbox and it looks like it worked. But, it didn’t work during the initial setup. Also, its a little tricky because that checkbox isn’t available until the host is registered with the server. So in my example, I am doing a full registration, which means it isn’t on the server at all. When I do the full registration, then I would need to go in and check that box for all of my devices, and if I’m doing a bunch of machines, it would be a little annoying. That’s why I wasn’t sure if there was a way around this.

    Something new that happened during this deployment, with that checkbox ticked, was it booted to the OS, I was able to work in there for about 2 minutes, and then the computer randomly rebooted. I can’t remember if it changed the name during that time, or if it had done it earlier. I’ll test this a bit, but would love to know if there was a way to get it to do the hostname change without having a domain or without having to check that box on each machine on the server.

    Thanks all, this product is awesome!

  • @MattPayerle The time on the hosts does need to be correct, authentication relies on correct time to a degree, if it’s too far off it just won’t work.

    The log says people are logged in and enforcing of hostname and AD settings is disabled, so that’s why it’s not doing anything. You can enforce this via the host’s Active Directory settings or via groups on many hosts at once with the same method.

    It is this:

    0_1472875965094_Enforce hostname changes.png

  • Thanks, yes, I saw the client setup with sysprep. I confirmed it is disabled before I take the sysprep, and enable it in setupcomplete. I know this is working, because the windows 7 key is activating.

    I just checked the FOG settings and saw the experimental feature that changes the hostname early. I unchecked this and deployed an image, but that didn’t change the issue.

    The Administrative username I use for the computers is DRSAdmin. The computer names are: DRSAdmi-xxxxxx (perhaps some sort of serial), but those are all random.

    Below are the logs, you can see in my most recent test (not 1:55 am, its a VM and the time is off which I don’t think is the issue because it happens on laptops too)
    You can see the computer name: DRSADMI-FTJ0QC3

    Then below in the “Hostname Changer” log section, that same log repeats itself every 2 minutes, along with a few other items, but this is the one I’m most interested in. Curious to see if others have this issue.

     9/3/2016 1:54 AM Client-Info Client Version: 0.11.5
     9/3/2016 1:54 AM Client-Info Client OS:      Windows
     9/3/2016 1:54 AM Client-Info Server Version: 1.3.0-RC-8
     9/3/2016 1:54 AM Middleware::Response Success
     9/3/2016 1:54 AM Middleware::Communication URL: http://fog/fog/service/\Student&mac=00:0C:29:CE:06:7A||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService&json
     9/3/2016 1:54 AM Middleware::Communication URL: http://fog/fog/management/index.php?sub=requestClientInfo&configure&newService&json
     9/3/2016 1:54 AM Middleware::Response Success
     9/3/2016 1:54 AM Service Sleeping for 81 seconds
     9/3/2016 1:55 AM Middleware::Communication URL: http://fog/fog/management/index.php?sub=requestClientInfo&mac=00:0C:29:CE:06:7A||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService&json
     9/3/2016 1:55 AM Middleware::Response Success
     9/3/2016 1:55 AM Middleware::Communication URL: http://fog/fog/service/getversion.php?clientver&newService&json
     9/3/2016 1:55 AM Middleware::Communication URL: http://fog/fog/service/getversion.php?newService&json
     9/3/2016 1:55 AM Service Creating user agent cache
     9/3/2016 1:55 AM Middleware::Response Invalid time
     9/3/2016 1:55 AM Middleware::Response No Printers
     9/3/2016 1:55 AM Middleware::Response Module is disabled globally on the FOG server
     9/3/2016 1:55 AM Client-Info Client Version: 0.11.5
     9/3/2016 1:55 AM Client-Info Client OS:      Windows
     9/3/2016 1:55 AM Client-Info Server Version: 1.3.0-RC-8
     9/3/2016 1:55 AM Middleware::Response Success
     9/3/2016 1:55 AM HostnameChanger Users still logged in and enforce is disabled, delaying any further actions

  • First,

    What sort of randomly generated name? Quick registration sets the MAC as the hostname. Sysprep scripts usually set a “randomly generated name”

    We need a full c:\fog.log to help. Without that we would just be guessing.

Log in to reply