Windows 7 is Missing NETDOM.EXE
Friday, October 23rd, 2009UPDATE: 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)
Windows PE 3.0 and the Missing WMI Class
Monday, October 12th, 2009Since I maintain the Windows XP Image for our lab machines, I was tasked with doing the same thing with Windows 7. When I rewrote our imaging tools last Spring, I created a WinPE 2.0 image that included the WMI package so that the imaging application could perform WMI queries in PE. I used WMI only to get basic information about the machine (Such as the Manufacturer, Model, Serial Number, and Disk Information).
While upgrading the WinPE image from 2.0 to 3.0 in anticipation of deploying Windows 7, I discovered that the Windows PE 3.0 base image (the same one that comes with the Windows AIK) was missing Win32_DiskPartition. I use this class to retrieve the number of partitions on the system disk so that I can make sure that each partitition (and its volume) has been assigned a drive letter so that I can search each drive for a preexisting configuration file. But why would Microsoft remove this class!? On a standard Windows 7 machine, the command “WMIC.EXE PARTITION” returned a list of partitions on the system, confirming that I wasn’t losing my mind. However, the command returned nothing when I tried it in Windows PE 3.0.
After lots of searching, I finally came across a post on Microsoft Technet where another developer ran into the same issue. Fortunately, he found a simple, but somewhat obscure, solution:
- On a fully-installed Windows 7 machine, copy the contents of C:\Windows\System32\wbem
- Mount the Windows PE 3.0 image and replace the contents of <mountdir>\Windows\System32\wbem with the wbem folder from the previous step
Using the Windows 7 wbem folder in your WinPE 3.0 image will make it several Megabytes larger, but at least you will be able to get to the missing WMI class(es) that you need!
SCCM 2007
Tuesday, October 7th, 2008At work I have been assigned the task of creating an automated Windows Vista deployment using Microsoft System Center Configuration Manger 2007. With Windows XP, we manually created an automated deployment using BartPE and batch files. After the operating system was installed and the machine was joined to the domain, group policy would handle software deployment via MSI files.
Why are we looking to use SCCM when there is an additional per-machine cost? Well, we see several advantages that we need in order to be able to continue to expand out Computer Management project:
- No MSIs required – SCCM will hopefully allow us to deploy software without needing an expensive packaging application such as WISE. Not to mention, there are a lot of applications that work very poorly when packaged with MSIs, such as Office 2007 and Adobe Creative Suite). Furthermore, there are some MSI packages that conflict with others and can inevitably make a machine build fail.
- Better software deployment management – Hopefully, SCCM will allow us to be more granular when it comes to choosing which computers get what software.
- Machine Inventory/Queries – Currently, we use applications developed in-house to perform WMI queries against machines for Inventory purposes. Inventory is stored in a SQL database and queries can be performed using a web page. Quite frankly, this is code we would rather not maintain in the future. The SCCM Configmgr interface should allow us to inventory machines while also to grant access to are partners to that they can query their machines. In other words, we no longer have to reinvent the wheel. Inventory should also be more reliable.
- Offsite deployment – Currently, any machines in CLM must be connected to the Penn State network in order to be managed and receive software. This makes managing offsite devices, such as laptops, impossible. SCCM has functionality that could allow us to manage and deploy software to offsite systems through HTTPS.
- Streamlined Operating System Deployments – Thanks to the Operating System Deployment (OSD) portion of SCCM, we will hopefully be able to rapidly create, configure, and deploy Windows to machines using a variety of distribution mechanisms including PXE, USB Drives, and DVD Media. We hope to incorporate all of the features of our current imaging process into this. SCCM OSD also uses ImageX to create images similar in the way that Symantec Ghost does. This should eliminate our dependency on Ghost licensing.
We’re still investigating SCCM and there are several experiments under way. One thing that I have found is SCCM does not support OS deployments via a restore partition on the physical disk. This is a requirement for us because we have a lab environmment where an entire lab of 50+ machines may need rebuilt over. Pushing out the OS over the network could eat up a lot more bandwidth than is necessary. We will have to find a way to work around this, which probably means throwing out the native SCCM boot shell (TSBootShell.exe) and writing a simple one that meets our needs.
ResCom Increases Bandwidth Limit to 4GB
Monday, March 17th, 2008For some time now, I have been a supporter of improving the ResCom service for students living in the residence halls. This is partly because I was formerly the ResCom student supervisor at Penn State Mont Alto and saw firsthand the shortcomings of internet service in University residence halls. With help and support on behalf of students from CCSG, I have advocated for both an increase in bandwidth restrictions as well as improvements to the registration process.
On Friday, an announcement was made that beginning this week, bandwidth limits will increase from 2GB/week to 4GB/week. Additionally, network throughput during the day would increase 120%. This is a major improvement for the residence halls. However, it should not make us forget about improving the service in the long-term. Here are my suggestions for ResCom, which I presented to University administrators 2 weeks ago in a formal letter: (more…)
Save Bandwidth: Use Penn State’s WSUS Server for Windows Updates
Monday, November 26th, 2007At the last SACITS meeting, someone brought up an interesting idea for saving commodity internetbandwidth in the residence halls. Because ResCom counts all internet traffic outside of Penn State against a student’s bandwidth limit, any Windows Updates also get counted against this limit. The reality is that there doesn’t seem to be any way to exclude the Windows Updates website from counting against bandwidth limits. This is where the Windows Server Update Service (WSUS) may be able to fix the problem. WSUS allows client computers to download updates from a server on the LAN instead of windowsupdate.microsoft.com. If a WSUS server were placed on the Penn State network for students living in the residence halls to use, it would allow them to download Windows Updates without facing the possibility of bandwidth penalties.