HostnameChanger question
-
I’ve just tried deploying a Windows 7 image to two computers and it doesn’t seem to want to join the domain. I’m getting the following error. I’ve deployed other Windows 7 images and they joined the domain properly. I’m guessing I’ve done something wrong with the image but I’m not sure what the error code means.
------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 06/09/2019 7:17 PM Client-Info Client Version: 0.11.16 06/09/2019 7:17 PM Client-Info Client OS: Windows 06/09/2019 7:17 PM Client-Info Server Version: 1.5.6 06/09/2019 7:17 PM Middleware::Response Success 06/09/2019 7:17 PM HostnameChanger Checking Hostname 06/09/2019 7:17 PM HostnameChanger Hostname is correct 06/09/2019 7:17 PM HostnameChanger Attempting to join domain 06/09/2019 7:17 PM HostnameChanger Unknown Return Code: 1219 ------------------------------------------------------------------------------
Thanks
-
@chunter2 The error 1219 literally means that there is a SMB/CIFS connection from this particular client to the same server (where the AD join is supposed to happen) but using different user credentials.
ERROR_SESSION_CREDENTIAL_CONFLICT
1219 (0x4C3)
Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.https://forums.fogproject.org/topic/2175/join-domain-error-1219
Do you have some other tool running on your client that might open a SMB/CIFS connection to the server - e.g. to load drivers or something??
-
@Sebastian-Roth This may all just be confusion on my part. I’m learning this system that was already set up as I go. One thing I had to do was change the Domain Password from what looked like a guid to the actual password for the join to work from the fog client. I think this had to do with my 1.2.0 to 1.5.6 upgrade.
This was on the image that “worked”. This different image I just tried has the error message. Could you maybe explain the difference in the following settings in fog?Under a hosts Active Directory section what’s “join domain after deploy”? Is that different than what the fog client tries to do?
What does “Name Change/AD Join Forced reboot?” in the Active Directory section do?
What’s the “Domain Password Legacy” for? Certain types of domains? We’re still running a Samba NT4 domain.
Under Service Settings for a host, what’s “Host Registration” do?
Under Service Settings what’s “Hostname Changer” do? I’m pretty sure this is the one that I’m getting the error message in the fog.log file from.
Thanks
-
@chunter2 said in HostnameChanger question:
Could you maybe explain the difference in the following settings in fog?
I will try to.
Under a hosts Active Directory section what’s “join domain after deploy”? Is that different than what the fog client tries to do?
This is more or less just the switch to enable AD join. As well there is another feature behind this. When global AD settings are set (FOG Configuration -> FOG Settings -> Active Directory Detfaults) then enabling the checkbox will also populate the default settings for those fields that were empty before. See here: https://wiki.fogproject.org/wiki/index.php/Active_Directory_-_FOG_Setting#Syntax
What does “Name Change/AD Join Forced reboot?” in the Active Directory section do?
In case a user is logged on the so called HostnameChanger module of the fog-client software won’t do anything unless you have this checkbox enabled. In that case it will still try to do the rename and schedule a reboot within 60 seconds.
What’s the “Domain Password Legacy” for? Certain types of domains? We’re still running a Samba NT4 domain.
No, legacy means the old (legacy) fog-client software. Back when this was used the password needed to be stored encrypted using a special tool. This is history - make sure you don’t use the legacy client anymore!
Under Service Settings for a host, what’s “Host Registration” do?
Find information on this in the wiki - I am not exactly sure but I think this is still valid: https://wiki.fogproject.org/wiki/index.php/Managing_FOG#Host_Register
Under Service Settings what’s “Hostname Changer” do? I’m pretty sure this is the one that I’m getting the error message in the fog.log file from.
Yes, this is the actual module doing the work (check hostname matches the one set for this host in FOG web UI/DB, if not rename, check if should do domain join and try joining).
As far as I see it all of that has nothing to do with the 1219 error code you got in the fog-client logs. Have you read this whole topic yet? https://forums.fogproject.org/topic/2175/join-domain-error-1219
-
@Sebastian-Roth I read through your reply a few times and I think the settings all makes sense now. The Host Registration one explains why I kept getting “new” MAC addresses for a couple machines even though I would remove them from the pending list. These machines had wifi modules that we don’t use. I also read through the link you posted to the other forum thread about the 1219 error. I’m wondering if I may have something similar in a way but I’m not exactly sure how to test. We have a logon.cmd script that runs to map a bunch of drives for the user logging in. Originally this wasn’t working because of linux file permissions on the logon.cmd file itself. I wonder if when “joining the domain” was working I hadn’t fixed that script yet. The strange thing is if I manually join the domain now and reboot it works fine. I checked and the fog service is set to delayed start like it suggested in that thread but that 1219 error still happens. Does the join happen without someone logging into the newly imaged host? I’m assuming it would? And would a logon.cmd script run on the join attempt? I figured it would only run on a user login.
Thanks
-
@chunter2 said in HostnameChanger question:
Does the join happen without someone logging into the newly imaged host? I’m assuming it would? And would a logon.cmd script run on the join attempt? I figured it would only run on a user login.
Absolutely right, the join happens without someone logging into the machine! And logon.cmd shouldn’t cause trouble in that case. Do you have other scripts like machine startup scripts in your AD GPO? Or other special tools or scripts running on bootup?
-
@Sebastian-Roth I’m still running an NT4 domain not an AD domain so I’m pretty sure I don’t have any GPO’s? I’m not sure where I’d look for any other tools or scripts on my server. Or are you thinking in the Windows 7 images itself? I’ve been putting off figuring out how to migrate a Samba NT4 domain to a Samba AD domain although I know I need to do that soon.
Thanks
-
@chunter2 While I am not exactly sure I’d still think this has nothing to do with Samba NT 4 vs. Samba AD!
I’d suggest you try this:
- Start the client, login as admin, open services.msc and set FOGService to manual start
- Reboot the client
- Login as admin again, open cmd shell and run
net session
, take a picture and post here - Try to disconnect all open sessions
net del ...
- Open services.msc, start FOGService and keep an eye on the log to see if it still fails with the same 1219 error
-
@Sebastian-Roth I just tried your suggestion. The
net session
command saysThere are no entries in the list.
Starting the FOG service again produces the same error message as my first post. Strange how there’s no sessions. I figured there’s be something. If I manually join the domain and reboot I then get the following in the fog log.09/09/2019 7:36 PM HostnameChanger Checking Hostname 09/09/2019 7:36 PM HostnameChanger Hostname is correct 09/09/2019 7:36 PM HostnameChanger Attempting to join domain 09/09/2019 7:36 PM HostnameChanger The machine is already joined to the domain, code = 2691
-
@chunter2 said in HostnameChanger question:
The machine is already joined to the domain, code = 2691
This is known in Samba NT 4 domains. See details here: https://github.com/FOGProject/fog-client/issues/110
The net session command says There are no entries in the list.
I really wonder if I am on the wrong track here or if it has some kind of hidden IPC connection open that is causing this. But why are you able to manually join the domain then? Maybe I was wrong and it actually is an issue that has to do with the methods we use to join and your Samba NT 4 domain. But why does it work for others - see issue on github in the link above. Those users are able to join.
-
@Sebastian-Roth I just tried disconnecting from the domain on a computer with a different image and the fog client reconnected correctly. Here’s the log.
------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 10/09/2019 4:46 AM Client-Info Client Version: 0.11.16 10/09/2019 4:46 AM Client-Info Client OS: Windows 10/09/2019 4:46 AM Client-Info Server Version: 1.5.6 10/09/2019 4:46 AM Middleware::Response Success 10/09/2019 4:46 AM HostnameChanger Checking Hostname 10/09/2019 4:46 AM HostnameChanger Hostname is correct 10/09/2019 4:46 AM HostnameChanger Attempting to join domain 10/09/2019 4:46 AM HostnameChanger Success, code = 0 10/09/2019 4:46 AM Power Creating shutdown command in 60 seconds 10/09/2019 4:46 AM Bus Emmiting message on channel: Power ------------------------------------------------------------------------------
And then this.
------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 10/09/2019 4:50 AM Client-Info Client Version: 0.11.16 10/09/2019 4:50 AM Client-Info Client OS: Windows 10/09/2019 4:50 AM Client-Info Server Version: 1.5.6 10/09/2019 4:50 AM Middleware::Response Success 10/09/2019 4:50 AM HostnameChanger Checking Hostname 10/09/2019 4:50 AM HostnameChanger Hostname is correct 10/09/2019 4:50 AM HostnameChanger Attempting to join domain 10/09/2019 4:51 AM HostnameChanger The machine is already joined to the domain, code = 2691 ------------------------------------------------------------------------------
I really think it’s just something specific with this image but I can’t seem to figure out what’s different. It doesn’t make sense that I can join the domain manually either. I’m almost at the point of just re-installing Windows 7 from scratch to see if that cleans it up.
-
@chunter2 said in HostnameChanger question:
I’m almost at the point of just re-installing Windows 7 from scratch to see if that cleans it up.
Although it might cost some time I would certainly try it. Just install a fresh Windows 7 from scratch and try fog-client domain join as very first thing. This way you don’t spend too much time in case this is a dead end.
-
@Sebastian-Roth I tried re-installing last night but ran out of time. I had an old version of Windows 7 that needed a bunch of updates before the fog client would install and run. I’ll have to try again another time.
I did try your debug Module.dll from the other thread and got the following in the log.
------------------------------------------------------------------------------ --------------------------------HostnameChanger------------------------------- ------------------------------------------------------------------------------ 12/09/2019 4:14 PM Client-Info Client Version: 0.11.16 12/09/2019 4:14 PM Client-Info Client OS: Windows 12/09/2019 4:14 PM Client-Info Server Version: 1.5.6 12/09/2019 4:14 PM Middleware::Response Success 12/09/2019 4:14 PM HostnameChanger Checking Hostname 12/09/2019 4:14 PM HostnameChanger Hostname is correct 12/09/2019 4:14 PM HostnameChanger RenameComputer returned properly, trying register/join next. 12/09/2019 4:14 PM HostnameChanger Checking AD params before join. 12/09/2019 4:14 PM HostnameChanger Attempting to join domain 12/09/2019 4:14 PM HostnameChanger Unable to resolve domain DNS name: The local computer is not joined to a domain or the domain cannot be contacted. 12/09/2019 4:14 PM HostnameChanger Unknown Return Code: 1219 ------------------------------------------------------------------------------
Does that extra log message help at all? When I ran out if time I just re-imaged back to the image that has the join problem.
Thanks
-
@chunter2 said:
... 12/09/2019 4:14 PM HostnameChanger Unable to resolve domain DNS name: The local computer is not joined to a domain or the domain cannot be contacted ...
Ok, this really seems to be a similar issue to what we discussed in https://github.com/FOGProject/fog-client/issues/110 - somehow I got confused because all the others seem to be able to properly join the domain but just complain about the client trying to re-join ever loop cycle.
It’s very interesting you get the
1219
error code although it seems to be more a problem with resolving the domain at all. As well I find it awkward that you can join the domain manually. Sounds a bit like our fog-client just is not able to cope with those different Samba setups.I am not sure were we are headed with this. I won’t find the time to setup a Samba domain and try to replicate the issue any time soon. But on the other hand I am not sure what to suggest to you to fix or get around this problem - hmmmmm.
-
@Sebastian-Roth Do you know what function produces that log message? Just wondering if I can do some googling on the error message.
-
@chunter2 Take a look at the code: https://github.com/FOGProject/fog-client/blob/master/Modules/HostnameChanger/Windows/WindowsHostName.cs#L203
You see the
try
andcatch
block in functionIsJoinedToDomain
. In the current code there is no error handling in thecatch
block and this is why you don’t see the reason but only the 1219 error when using the official 0.11.16 Modules.dll. Now the Modules.dll I build for you has error logging added.So the “domain cannot be contacted” error comes from
Domain.GetComputerDomain()
orDns.GetHostAddresses(..)
.When you look a little further down the code you get to the part where it tries to join the domain and where the 1219 error occurs. Function used here is NetJoinDomain.
Hope you can find something!
-
@Sebastian-Roth Would it be possible to get a dll with logging showing which of the following is failing? And maybe the return value of the ones that aren’t?
using (var domain = Domain.GetComputerDomain()) { var currentIP = Dns.GetHostAddresses(domain.Name); var targetIP = Dns.GetHostAddresses(idealDomain); return (currentIP.Intersect(targetIP).Any()); }
-
@chunter2 Will do so in a few hours.
-
@Sebastian-Roth I was actually able to compile that dll myself. Looks like it’s throwing on the GetComputerDomain() line in both cases. Trying to join the domain and after I manually join the domain. So I don’t think that’s the problem. It’s failing on the NetJoinDomain() function. I think I need to print out the variables to see if they’re the same for a good image and a bad one.
-
@Sebastian-Roth I decided to remove the client and re-install it on this machine and now I get a different error in the fog log. It keeps looping on this.
------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 13/09/2019 3:06 PM Client-Info Version: 0.11.16 13/09/2019 3:06 PM Client-Info OS: Windows 13/09/2019 3:06 PM Middleware::Authentication Waiting for authentication timeout to pass 13/09/2019 3:08 PM Middleware::Communication Download: http://xxx.xxx.xxx.xxx/fog/management/other/ssl/srvpublic.crt 13/09/2019 3:08 PM Data::RSA FOG Server CA cert found 13/09/2019 3:08 PM Middleware::Authentication Cert OK 13/09/2019 3:08 PM Middleware::Authentication No token found at C:\Program Files (x86)\FOG\token.dat, this is expected if the client has not authenticated before 13/09/2019 3:08 PM Middleware::Authentication ERROR: Could not get security token 13/09/2019 3:08 PM Middleware::Authentication ERROR: Could not find file 'C:\Program Files (x86)\FOG\token.dat'. 13/09/2019 3:08 PM Middleware::Communication POST URL: http://xxx.xxx.xxx.xxx/fog/management/index.php?sub=requestClientInfo&authorize&newService 13/09/2019 3:08 PM Middleware::Response Invalid security token
I’m wondering if maybe this is the real problem. Do you know what this means?
Thanks