Hostnamechanger fail while renaming client inside the domain
-
hey folks,
sometimes i have to place a client to another department. so i have to change the name of this client.
with fog it is very simple, i change it in the web gui, the hostnamechanger renames it and will reboot.
so far so good. the problem is an error when trying to log in:
The security database on the server does not have a computer account for this workstation trust relationship
So i have to unjoin this client manually from the domain. fog service will automatically join it in the domain and all works.
thanks in advance for suggestions
greets
jt -
@BSZAdmin Thanks for reporting this. From what I get this is an issue in how the fog-client is doing the rename. Possibly this is something that has worked with Windows 7 but doesn’t work the same way in Windows 10. But it could be also an issue even in Windows 7 and just not too many people have come across it. I think I’ve never seen anyone reporting this so far.
I will take a look at the fog-client code over the weekend and let you know.
-
@BSZAdmin I have dug through a lot of fog-client stuff over the weekend to get it updated to newer libs and all that. Have not found the time to actually get into this.
Please confirm you are using Windows 10 - which version exactly?
-
@Sebastian-Roth
Thx 4 ur support.
The Image was a win 10 x64 1809.
Greets -
Hey guys,
are there any suggestions meanwhile?
Thx -
@BSZAdmin said in Hostnamechanger fail while renaming client inside the domain:
Hey guys,
are there any suggestions meanwhile?
ThxI myself do not have any suggestions, but we appreciate your patience through @Sebastian-Roth looking through the client stuff this weekend. I feel that you already know this, but as a volunteer developed platform, sometimes we have to wait a bit for the developers to find free time to look into issues. I’ve been in that boat myself before. If anyone does have anything to add, I’m sure they will chime in.
-
In the meantime I would suggest writing a powershell script to unbind and rebind and you could push it out as a snapin after executing the name change. I don’t know how many of these you are doing and how coordinated you are with the machines so YMMV
-
@fry_p
hey guys,
it was not my intention to be impatient.
i am thankful 4 the good work of the fog developers and volunteers.
keep on :))
Greets -
@BSZAdmin Sorry for taking so long!!
Today I found some time to play with this. Unfortunately I can’t reproduce the issue as described. For me it renamed to the new name, rebooted and I was able to login without issue. Though I only have access to a Windows 10 1803 test system I would find it very strange if a difference between 1803 and you 1809 would cause this to fail. The other thing that might be different is, I only have access to this machine via RDP, no real console login. Though if “trust relationship” is an issue I am fairly sure it would fail on RDP login as well.
So I think you need to help with more information here. You said you need to “place a client to another department”. Does that also mean you move it within Active Directory from one OU to another? If yes, then just don’t do that yet and see if just renaming it via fog-client and login works.
If the above does not aply to your situation I want you to do a test. Make sure you have a local admin account on the PC (just to be able to logon later on in case), log off (so fog-client can do its work), rename the host in FOG web UI and wait till it reboots. Now check in AD Users and Computer managment to see if the computer object is actually being renamed in AD! Make sure login still fails with the exact same error message as mentioned above. If so, then you want to check the AD attribute servicePrincipalName of the computer object using ADSI Edit as mentioned here: https://bloggymcblogface.blog/cannot-log-on-to-a-renamed-member-server/
-
@BSZAdmin Possibly this issue has to do with the computer having been turned off for a fair amount of time before you get the request to move it to another department?? See here: https://www.prajwaldesai.com/workstation-trust-relationship/
The more I read about this the less I think this is caused be the fog-client. But we’ll see. Please try things as suggested and we’ll take it from there.