Netdom on Windows Server 2008 R2

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) :

Netdom Error
The procedure entry point I_NetNameValidate could not be located in the dynamic link library NETAPI32.dll.

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 :

Path Variable
Path Variable

OK back out to your desktop, open a new command window and run your “netdom query fsmo” command again, then watch the results :

Correct Netdom Output
Correct Netdom Output

Hopefully, this little tip will save somebody hours of time, that I wish I’d been able to save myself!

The Zoo Keeper


By TheZooKeeper

An Azure Cloud Architect with a background in messaging and infrastructure (Wintel). Bearded dog parent who likes chocolate, doughnuts and Frank's RedHot sauce, but has not yet attempted to try all three in combination!


  1. 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.

    1. 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.

    2. 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.

  2. 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!

    1. 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!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.