Windows 7 is Missing NETDOM.EXE
UPDATE: I discovered that there is a working NETDOM.EXE for Windows 7. Here’s what you need to do (on a Windows 7 machine) to get it:
- Install the Remote Server Administration Tools (RSAT).
- Go to Control Panel -> Programs and Features -> Turn Windows features on or off
- In the treeview, go to Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools and select AD DS Tools. Click OK.
NETDOM should be located in your SYSTEM32 folder. If would rather use Powershell to join the domain, since it’s included with the Windows 7 RTM, then please continue reading. I apologize for any confusion.
(Begin Original Post)
Now that the title of this post has your attention, I can tell you that Windows 7 isn’t really missing this important tool that joins a machine to an Active Directory Domain in an automated fashion. Instead, this command-line utility has been superseded by a new command that’s included in Microsoft’s love-it-or-hate-it command line shell: Windows Powershell. Why? Well, Powershell is certainly more powerful than the standard command prompt. But more importantly, Windows 7 is the first version to include Windows Powershell in the RTM build. With Powershell built into Windows 7, perhaps Microsoft saw no reason to continue including and supporting our old pal, NETDOM.
Joining a Domain with Add-Computer
When you’re finished grieving over the loss of our beloved NETDOM, which has joined countless computers to countless Windows Domains (or far inferior Workgroups), it’s time to roll up your sleeves and start working with the successor command: Add-Computer. This command will only run in a Windows Powershell command prompt. The good news, however, is that you can easily run Add-Computer inside Powershell through a normal command prompt (or batch file). To do so, open a command prompt (with elevated privileges) and run this command:
powershell Add-Computer -DomainName "YOURDOMAIN"
See? That wasn’t so bad now was it? If you don’t mind entering credentials to join the domain on every single computer, that’s all you need. But unfortunately, some of us need to automate the process of joining the domain. For that, it gets more complex, and we’ll need a bit more Powershell to make it work.
Screenshot: Add-Computer -?
How to Use Add-Computer
From a command prompt, you can get more detailed usage instructions for Add-Computer by using this command:
powershell Add-Computer -?
In the syntax section, you’ll find syntax switches that can be used to specify the domain name, OU path, and credentials. For a more details and examples on Add-Computer, you can also use this command:
powershell get-help Add-Computer -detailed
The first thing you should notice is that, unlike NETDOM, there aren’t syntax switches to specify the username and password. Instead, there is a switch called “-Credential” that takes in a PSCredential object. Therefore, we need to create a PSCredential object with the credentials that will be used to join the computer to the domain before we can actually use the Add-Computer command in an automated way. To do this, we’ll need to create a Powershell script.
If you have never used Powershell before, you’ll probably say to yourself, “PSCredential object? What is that!?” I’ll give you this very brief explanation: PSCredential is an object that can securely store Windows credentials. Furthermore, Powershell is more like full-blown Object-Oriented scripting language than a shell language. Like DOS, it has a command prompt. However, the differences usually end there. Anyway, this article isn’t about Powershell, but if you want to know more about it, start Googling. Or you can just continue on to get the Powershell script.
A Powershell Script to Join the Domain
The Powershell script needed to join the domain contains only two commands. Create a new text file named “joinDomain.ps1″ and put the following powershell code into it:
$credential = New-Object System.Management.Automation.PsCredential("MY.DOMAIN.COM\user", (ConvertTo-SecureString "mypassword" -AsPlainText -Force))
Add-Computer -DomainName "MY.DOMAIN.COM" -Credential $credential -OUPath ("OU=Computers,DC=MY,DC=DOMAIN,DC=COM")
The first line of the script creates a new System.Management.Automation.PsCredential object. PsCredential takes in two parameters: a string containing a username and a secure string containing the password. You should change “MY.DOMAIN.COM\user” to the user that will join the computer to the domain. Change “mypassword” to the password of that account.
The second line is the Add-Computer command. “MY.DOMAIN.COM” should be changed to the domain that the computer is joining. Change OUPath to the OU String that points to the OU container that the computer object should be placed in.
Running the Script
To run the Powershell script above, you need to open an elevated command prompt. To run it, type powershell ./joinDomain.ps1 and press enter. In many cases, you will find that you’re not allowed to run the script, despite running the command as an administrator:
>powershell ./joinDomain.ps1
File joinDomain.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
The funny part about Powershell is that, by default, it is configured to only allow the execution of signed scripts. This is a security feature so that unauthorized or malicious scripts that could compromise the system can’t be executed. After all, Powershell is quite power-ful. Unfortunately, this really tends to confuse and frustrate people. To get around this, you can temporarily change the execution policy, and then change it back:
powershell Set-ExecutionPolicy Unrestricted powershell ./joinDomain.ps1 powershell Set-ExecutionPolicy Restricted
You can also change the execution policy to allow only signed scripts and scripts created by you. For more information about the Powershell execution policy, check out this article.
Final Thoughts
Now that you are able to automate a domain join with Powershell instead of NETDOM, there is one final thing that I want to mention. In the script above, the password String was converted to a SecureString by using the “-AsPlainText -Force” arguments. Using SecureString in this way is generally discouraged as it defeats the whole purpose of having a secure string. Furthermore, having account credentials in plain text with in the script is insecure and generally a bad idea. I’m guessing that this is the reason why Microsoft left out the “/userD” and “/passwordD” parameters from the NETDOM command and made it more slightly difficult to include the credentials in plain text. You should limit the rights of the account you’re using to automatically join the domain so that it cannot be used to delete Active Directory objects, access network shares, etc. You should also consider other methods of storing the credentials. This article has an alternative method for storing credentials used in Powershell that may meet your needs.
![[del.icio.us]](http://iboyd.net/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://iboyd.net/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://iboyd.net/wp-content/plugins/bookmarkify/facebook.png)
![[StumbleUpon]](http://iboyd.net/wp-content/plugins/bookmarkify/stumbleupon.png)
![[Twitter]](http://iboyd.net/wp-content/plugins/bookmarkify/twitter.png)
Themocracy
Windows 7 and Vista both have their own NETDOM.EXE, for 32-bit and 64-bit.
You have to install:
Install RSAT (After you have extracted the tools): (took me awhile to find the link)
http://www.microsoft.com/downloads/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en
start /w pkgmgr /n:%SystemDrive%\Install\RSAT\Windows6.1-KB958830-x86.xml
Enable some RSAT tools (including NETDOM)
start /w pkgmgr /iu:RemoteServerAdministrationTools-Roles-AD-DS-SnapIns;RemoteServerAdministrationTools-Roles-AD-DS;RemoteServerAdministrationTools-Roles-AD;RemoteServerAdministrationTools-Roles;RemoteServerAdministrationTools
You will then have a “c:\windows\system32\netdom.exe” that supports the ‘older’ Netdom syntax.
HOWEVER, IF YOU MOVE THE ‘NETDOM.EXE” FROM THE ‘SYSTEM32′ SUB-DIR IT WILL NOT WORK???!!
IT WILL JUST ‘EXIT’ UPON EXECUTION??
BUT , if you WANT to move it, which i did. you have to do ‘something’ EXTRA.
To whatever sub-dir you move the RSAT NETDOM.EXE to :
1) FOR EXAMPLE, create a sub-dir called : %temp%\EN-US
2) COPY /Y “%SYSTEMROOT%\SYSTEM32\EN-US\NETDOM.EXE.MUI” “%TEMP%\EN-US
Then if you execute NETDOM.EXE from “%TEMP%” you should ‘see’ the familiar ‘help’
messages..
NOTE: I have not, as of Dec 8, 2009 actually TESTED the FULL ‘moved’ NETDOM.EXE functionality,
but WILL in the next day or so,.
ALSO, someone made the comment that if it was moved’ to another compouter it would not work also,
I will verify that statement also.
Hope this helps, as i DONT like the Powershell approach..
J P Morgan james_p_morgan@hotmail.com
Thanks, I added an update to this post this morning as I stumbled upon netdom.exe after I needed to install some RSAT components for the dsquery and dsadd tools on a server. Thanks for the advice about moving NETDOM as well. I’m also wondering is whether NETDOM is platform (x86 vs. x64) specific. I’ll have to investigate.
James,
Thank you for your post it was very helpful on tracking down how to get NetDom to work on Windows 7 with out installing AD Tools or RSAT. I was able to grab both the netdom tool and associated mui from my Windows 7 x64 ENT machine for x64 and x86 architectures. I created a basic Windows 7 x64 ENT VM left it in a workgroup. I created a folder called temp on the root of C: inside of there I placed the netdom.exe and then created a folder within call EN-US and placed the mui file in there. I had to run command prompt as administrator but I was successfully able to join the workgroup vm to the domain.
Nice script, thanx. But … is there possibility for password prompt within script? Thank you M.
Yes… something like this should work:
$credential = get-credential Add-Computer -DomainName "MY.DOMAIN.COM" -Credential $credential -OUPath ("OU=Computers,DC=MY,DC=DOMAIN,DC=COM")Good, i have created these two files. domainjoin.ps1 & domainjoin.bat. now when i ran domainjoin.bat, it’s asking for the username/password to run. how can i run it under username/password privileges which i have specified in domainjoin.ps1 file.
I found that if you copy \sytem32\netdom.exe and \system32\en-us\netdom.exe.mui from a machine where you installed RSAT (only the AD tools) to the same location on any other machine (win7) that netdom will run fine. I did not try to mix 32/64 bit so I can’t comment on interchangebility. Anyway this let me continue using the methodology I had been using, for vista and now win7 ghost and \windows\setup\scripts\SetupComplete.cmd
(no powershell, rsat)
This works calling netdom from any folder so long as the file structure of the files, relative to each other, is preserved.
So the following would work.
c:\netdom.exe
c:\en-US\netdom.exe.mui
Share and enjoy.
I am new to Powershell and scripting. I am using the above script with an answer file to join our domain. We install a lot of new PC’s and I am trying to find a way to delete this script after the computer joins the domain. The script is in a syspreped image. I also am trying to find a way to join the domain on top of an existing computer account or delete the existing account before joining the domain. We do a lot of re-imaging of our computer labs. This is why I would like to join on top of an existing account. We use to be able to do this with a .vbs script with xp and Vista. We are now using windows 7 and want use Powershell to do this.
Hi Boyd,
Very useful page, thanks!
I created a .cmd file as in the article, including lowering the executionpolicy to unrestricted.
But, powershell still deems it necessary to warn me about the possible harm that could be done running the script, and it prompts me if I really want to continue.
So it still requires user intervention. Is there a way to avoid this message and thus the prompt to continue or not?
Oh and I forgot, the /OU parameter failes to put the computer in the correct OU, possible because there is a space in OU “Site brussel”, how do I go about fixing this?
Hey Geert,
If you call that .cmd file from the command line instead of clicking on it, I don’t think you’ll be prompted.
Regarding the OU path issue, make sure that you’re putting the complete OU string between parentheses. You may also want to verify that your OU string is complete and correct. Remember, it needs to include your domain, like this:
-OUPath (“OU=Computers,DC=MY,DC=DOMAIN,DC=COM”)
If it still doesn’t work, let me know!
Thanks for posting this script, this worked out great for us at our company. I ended up using it within a Landesk Provisioning script for our Windows 7 deployment. Some of our newer Dell systems (e6410, e4310) do lot properly load a network driver during Mini-setup, and therefore I needed to add the PC to the domain after it was in Windows. The other bonus that this script gives is being able to specify which OU to place the computer, which is great.
One note I just wanted to add is that I had to wrap the password in a single quotes because we use special characters that Powershell tries to interpret ($, %).
Hi Leleche,
Thanks for the heads up about the special characters. I’m sure there are plenty of other people that use special characters for their “domain join” accounts.
I’m not sure if the right way to join a domain is through mini-setup, but we’ve always done it after mini-setup… it just seems to be more reliable. To keep it unattended, I use the SetupComplete.cmd file:
Thanks for commenting!
[...] means no AD integration. Here's what I've found. Win7 has NETDOM, it's just not installed. This guy has a pretty good article on how to install it. However, that's only half of the battle because the [...]
[...] For more info check this page out http://iboyd.net/index.php/2009/10/23/windows-7-is-missing-netdom-exe/ [...]
Thank you so much man, you saved my life!
Thanks iBoyd! This exactly what I been looking for. I love using netdom and since we migrated to Windows 7 I was lost without it. I need to learn PowerShell commands, but netdom is to easy to use!