Yay, it’s time for another technical post!
I manage and am responsible for Active Directory for a number of customers, both public and private sector. Rather than searching my documentation to find the FSMO role holders, it’s easier to log on to a server and run “netdom query fsmo” in a command prompt.
Sometimes though, especially after installing the Windows Support Tools on a server, you can get the following error when running netdom (and other system tools) :
Turns out the problem is related to the path variable!
To fix the issue, close your existing command window (it’ll retain the old path), and go to your Environment Variables in advanced system properties. In the bottom box, double click “Path” and make sure you put %SystemRoot%\system32; before all other paths :
OK back out to your desktop, open a new command window and run your “netdom query fsmo” command again, then watch the results :
Hopefully, this little tip will save somebody hours of time, that I wish I’d been able to save myself!
Thanks mate…..it works
You’re welcome.
I’m glad it helped.
Good tip, worked a treat. Thanks!
Works like charm. Thanks buddy 🙂
You’re welcome!
Thanks for the feedback…
Thank you very much for this port. I had the same problem.
I applied your procedure and it’s solved.
You’re welcome!
I’m glad it helped…
Excellent dude..Works like a charm 🙂
Awesome! Thanks for the feedback!
Hi ZK
Having the same error message when I’m trying to add a Win 2008 R2 server to an existing AD domain thru
dcpromo. I tried to reset the path like you explained above but, I had the same error. I’ve run adprep/ forest on an existing DC and it worked fine. Any clue.
Sorry Ron, I’ve never come across the error when using DCPROMO. It might be worth you looking in the %system32%\debug folder for the dcpromo log and seeing if there’s anything useful in there!
Hope this helps.
I had this issue using dcpromo as well, but it was when I was demoting a DC. I’m pretty sure the issue will be the exact same though.
Check which domain controller DCPROMO is complaining about, and then perform the fix above on that DC. That was my issue – I was trying to demote a DC, and one of the other (existing) DCs had this issue. Corrected the path on the offending DC, and then I was able to demote the one that I originally wanted to.
Excellent advice David – thanks for the input!
Thanks, it resolved my problem…
Thank you! That worked like a charm. I found that there was another path in front of SYSTEM32, and since it was to the left of SYSTEM32 it took precedence. Therefore my nltest.exe command (netdom in your case) was running from the wrong path. That wrong path happened to be for Windows Support Tools that were downloaded separately and installed in C:\Program Files (x86)\Support Tools\.
There was nothing wrong with the path and all the executables were in there, including nltest.
The problem is that it was an outdated version of nltest.exe an therefore it failed. This last statement is a good lesson – the SYSTEM32 files (built-in support tools that come with role installation) are updated from time to time as a part of windows updates. Separate installations like in my case are not updated. So if the PATH variable finds the command (nltest or netdom or a hundred others) at a location different from SYSTEM32, there WILL be problems. Thanks again!
No problem Max, you’re very welcome.
You’re absolutely right, the SYSTEM32 files are regularly updated, and if the tool you’re using doesn’t match the version that other system files are expecting, you’ll get that error.
Thanks for your feedback!
Thank you! That works.
Thanks so very much for this tip buddy, worked like a charm!!
You’re welcome!
I’m so glad it’s been useful.
Dam, it did the trick ! thx