Hostnamechanger not working
-
Yet another update. Now that my host has correct name to match what’s in FOG console, and the host is joined to the domain I decided to test to see what would happen if I rename it in the FOG console. Log is below. Host does not restart on it’s own:
------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 5/5/2016 2:33 PM Client-Info Client Version: 0.10.5 5/5/2016 2:33 PM Client-Info Client OS: Windows 5/5/2016 2:33 PM Client-Info Server Version: 7488 5/5/2016 2:33 PM Middleware::Response Success 5/5/2016 2:33 PM HostnameChanger Checking Hostname 5/5/2016 2:33 PM HostnameChanger Removing host from active directory 5/5/2016 2:33 PM HostnameChanger ERROR: Required ADDom information is missing 5/5/2016 2:33 PM HostnameChanger Renaming host to MOSSIMAGEVMTEST 5/5/2016 2:33 PM Power Creating shutdown command in 60 seconds 5/5/2016 2:33 PM Bus { "self": true, "channel": "Power", "data": "{\r\n \"action\": \"request\",\r\n \"period\": 60,\r\n \"options\": 2,\r\n \"command\": \"/r /c \\\"FOG needs to rename your computer\\\" /t 0\",\r\n \"message\": \"This computer needs to perform maintenance.\"\r\n}" } 5/5/2016 2:33 PM Bus Emmiting message on channel: Power ------------------------------------------------------------------------------ 5/5/2016 2:33 PM Service Power operation being requested, checking back in 30 seconds 5/5/2016 2:34 PM Service Power operation being requested, checking back in 30 seconds 5/5/2016 2:34 PM Power Creating shutdown request 5/5/2016 2:34 PM Power Parameters: /r /c "FOG needs to rename your computer" /t 0 -
@gwhitfield Small question why are you trying to rename the computer before sysprepping? Your master image should never join the domain. This can cause issues when you sysprep and that image still has some of the policies of your domain in the image.
This can cause auto logon to not work along with a bunch of other issues. That being said I have done it to get some software to work then dropped it back, reset the Admin password to blank and it worked fine but I really don’t recommend it.
-
@Psycholiquid - good question. I do not let my master image ever join the domain before sysprep. When I sysprepped my master image and deployed it last night, it didn’t rename or join domain on it’s own so I’m troubleshooting that issue. The client version was 7.2 which I am now attempting to bringing up to 10.5 to keep up with the latest server version.
The server is new, this is the only image on it. The image was sysprepped and uploaded with no apparent problems yesterday, but obviously something is wrong when it’s deployed. I had hoped it was just a bad client but the new client isn’t working either.
What I’m doing now is testing what will happen when the sysprepped image is deployed. Since all my fog servers (up til now) have made hostname and AD joins happen automatically with reboots, I’m hoping to get back to that. Unfortunately it looks like it’s needing a manual restart to complete the task which I’m sure isn’t right.
-
@gwhitfield Yeah that was the same issue I was having and had to deploy the disabled service and start after sysprep to overcome. Now I agree that the old server didnt do that and nor did mine, but once I went to using trunk I had to switch to this method.
-
I think the FOG gods are laughing at me. I uninstalled client v10.5 installed my oldest client back from 2010 with the encrypted password in hostnamechanger.dll and as soon as I started the service it renamed and restarted the host. I’m tempted to stay with it and use it for my master image - it works awesome like it always has. Not sure of the downside to staying with old client though… any thoughts?
-
@gwhitfield The old client has several security issues. You switched to the new client right after we did a major upgrade of it, so these kinds of bugs are to be expected. If you can wait until tommorow, I can take a look at this then.
-
No worries! I’m not complaining, FOG has never let us down!
-
Confirmed the bug exists. For some reason Windows isn’t receiving the client’s shutdown request.
-
Bug found, and patched. Long story short, Zazzles was killing the service right before it was about to run the shutdown command (a.k.a a race condition). See https://github.com/FOGProject/zazzles/commit/f7e199c93f8ac894b495d336355afae8674d6e6f for the fix.
I’ll post here when we release v0.10.6 (more work needs to be done to fix some of the MSI issues first). Thank you for reporting this.
-
v0.10.6 should fix this issue. Can you verify?
-
@Jbob - sorry didn’t see this for so long. I will test as soon as I can but it may be several days yet due to other commitments. Hopefully someone else will give it a go much sooner if they haven’t already!
-
@gwhitfield There are some other issues going on, the issue is no longer present in the current FOG Client, they are server side issues at this point. Please follow this thread for updates: https://forums.fogproject.org/topic/7382/fogservice-errors-for-all-modules
-
@Wayne-Workman Thank you, I’ll post if I see anything else happening.