Windows 10 failing to join domain

[Sebastian Roth]

@chunter2 Great you have looked into this! Thanks a lot. So far I don’t have any idea on why this is the case. But I will take a closer look tomorrow.

[chunter2]

@sebastian-roth Sounds good. One more point of interest. If I remove that if completely the computer gets renamed and joins the domain correctly. I guess leaving it that way will make the client try to change the name and attempt to join the domain over and over again.

Thanks

[Sebastian Roth]

@chunter2 said in Windows 10 failing to join domain:

It looks like Environment.MachineName is being updated before the name is actually changed.

The actual rename is done using Windows API call SetComputerNameEx. You might want to add further debug output to that part of the code to see if something goes wrong here. Searching the web I couldn’t find an obvious issue with that API call yet.

Have you tried using the hostname command (in cmd prompt) to see if hostname change is reflected there?

[chunter2]

@sebastian-roth Not sure if I’m reading the code correctly but doesn’t the RenameComputer function in HostnameChanger.cs happen before the RenameComputer function in the WindowsHostName.cs file? If so I think the Environment.MachineName.Equals call is already incorrect meaning it thinks the computer has already been renamed. I thought the RenameComputer function call to the WindowsHostName.cs file was in the try right after the “Renaming host to” log message which in my case I never get to. Hope this makes sense.

Thanks

[Sebastian Roth]

@chunter2 said in Windows 10 failing to join domain:

Not sure if I’m reading the code correctly but doesn’t the RenameComputer function in HostnameChanger.cs happen before the RenameComputer function in the WindowsHostName.cs file? If so I think the Environment.MachineName.Equals call is already incorrect meaning it thinks the computer has already been renamed.

Yes you are reading the code correctly. Though my thinking was, that the fog-client running this code in a loop over and over again might do a rename on the first run and then when it gets to the Environment.MachineName.Equals check next time is what we see in the logs you posted. You might want to grab a full log, upload that somewhere and post a link here (or maybe upload in the forum directly if it works).

I am hoping to get a test setup in the next few days. Though it’s kind of hard for me in between many other things needing my attention and time at the moment. So I appreciate all you do very much! It’s very helpful you started debugging this already.

I am wondering if you’d be willing and able to come up with a very simple command line tool coded in C# that only does the SetComputerNameEx call. This way we could more easily test this on several different setups and even let other people test to see the differences.

[chunter2]

@sebastian-roth I think I may have tracked down my issue and I think it may be my fault. In my testing I was able to manually change the computer name and then the client would join the domain. I then disconnected from the domain and changed the name back to the original name and rebooted. The client then renamed the computer and joined the domain by itself. I decided to take an image of the machine at this point by first disabling the change hostname and join domain options in the fog web gui for that machine and then rename the computer back again and disconnect from the domain. I then loaded this new image on the same machine after re-enabling the change hostname and join domain in the fog web gui, and loaded it on a second machine and they both renamed and joined properly. My guess is I had never joined the domain with the first image I created. It was as clean an image as I could get. If this makes sense I think this was my issue.

Thanks

[Sebastian Roth]

@chunter2 Sorry for the long delay! Seeing that you’ve solved this issue I put this a little further down on the prio list. Good to hear you found what was causing this!!

I don’t think we’ve ever had anyone run into this issue before. As well I can’t find any reference to the return code 2725 in the forums.

Maybe we should add this return code to the list of known return codes and spit out an appropriate message for other users running into this as well. What do you think?

Background: With some more recent Windows 10 build version AD joining seems to have changed a bit. Microsoft tends to push people to use their Azure AD stuff and you need to manually switch over to AD joining. Maybe there something behind the sceen that has changed and is now causing machines to fail a local AD join using the fog-client if they were not joined to a local domain before. Not sure - just a wild guess.

[chunter2]

@sebastian-roth Thanks for the reply. Yes, I think adding an appropriate message would be nice. I’ll keep the image that causes the 2725 error around just in case but at this point I’m not quite sure how or what else to debug. If you have any thoughts in the future and would like me to test just let me know.

Thanks

[Sebastian Roth]

@chunter2 Finally got back to this one. Doing a little research on the error code 2725 I found the code to mean: The domain controller does not meet the version requirement for this operation.

Doesn’t really make sense to me as the very same domain controller succeeds to join that machine via fog-client if it was manually joined before. So I went ahead and found a header file containing the error code as well. It’s in a section called “Error codes used for offline domain join and completion”. I didn’t even know you can do an offline join.

So my guess is the machine was in a state were it was trying to do an offline join and failed. So instead of telling the user “The domain controller does not meet the version requirement for this operation” I would rather say something like “Machine seems to be in an offline join state - do a manual join/unjoin of your master before capturing the image”.

What do you think?

[Sebastian Roth]

@chunter2 Bump…