PowerShell and Active Directory

Since its release, Windows PowerShell has become the automation platform of choice for Windows. Its power and flexibility have been proven in many environments against many Windows technologies. Unfortunately, when it came to Active Directory (AD) support, PowerShell 1 didn't have a very good story out of the box. Basically, Microsoft provided the ADSI “type-accelerator” and that was about it. If you needed to do more advanced tasks, you had to access the native .Net classes that provided AD support—which required more advanced skills than most administrators were interested in learning. Many shops turned to third parties such as Quest Software and its AD PowerShell snap-in to fill the bill.

But with the release of Windows 7 and Windows Server 2008 R2, the wait for full-fledged PowerShell AD support is over. Microsoft has shipped an AD module and PowerShell Drive provider in these new releases to make managing AD from PowerShell a snap.

How Do I Get It?
If you install a Windows Server 2008 R2 domain controller by adding the Active Directory Domain Services role within Server Manager, the AD PowerShell module will be installed by default. However, if you want to install the module (a module is a just a collection of PowerShell cmdlets, providers, scripts, and so on) on your Windows 7 workstation, you’ll need to install the Remote Server Administration Tools (RSAT).

Once you’ve installed RSAT, go to the Programs and Features category in the Control Panel, choose Turn Windows Features on or off and scroll down until you see the RSAT node. Expand that until you get to the Active Directory Module for Windows PowerShell node, as shown in Figure 1. Check that box and select OK to add the module.

Once the module is installed, you can select either the Active Directory Module for Windows PowerShell item from the Start Menu, Program, Administrative Tools program group, or you can easily add it to your existing PowerShell session by typing:

 Import-module ActiveDirectory

After a brief flash, the prompt will return and you'll be able to access all the power that PowerShell and AD have to offer. However, before we start using the AD PowerShell module, let me add one important piece of information. Unlike any prior implementations that allowed PowerShell-based AD automation, this new module requires that you have at least one domain controller in your domain running the new Active Directory Web Services (ADWS). ADWS is installed by default on an R2 domain controller, but you’ll need a special add-on to your Windows Server 2003 or Windows Server 2008 domain controllers in order to use the module.

If you don’t have an ADWS server in your domain, you'll get an error when you try to import the AD module into PowerShell. The interesting thing to note about ADWS, and these PowerShell cmdlets in general, is that they don’t use LDAP to talk to AD. Specifically, they use XML Web Services–based protocols to interact with AD. This is a significant departure from all previous AD toolsets and it will be interesting to see if Microsoft continues this trend in future AD management tools. Note that once you install ADWS on your non-R2 domain controller, you'll still be able to manage these servers using normal LDAP-based tools such as AD Users and Computers.

Using the Cmdlets
Once you’ve installed the cmdlets and have a DC with ADWS running, you’re ready to explore the power of PowerShell for AD. Microsoft provides two main tools for automating AD management using PowerShell. The first is a set of cmdlets that let you do everything from searching for AD objects to creating computer accounts to modify user accounts. The second tool is a PowerShell Drive Provider for AD that lets you navigate AD like a file system. This tool can be powerful for interactive use and I’ll show you some nifty things you can do with it against AD.

Let’s start by looking at some of the AD cmdlets. If you want a list of all the AD-related cmdlets exposed by the AD PowerShell module, open PowerShell and type the following:

 get-command -module ActiveDirectory

This will return a list of 76 cmdlet names that are part of the AD module. As you'll see from the list, there are obvious cmdlets such as Get-ADGroupMember to retrieve members from groups and New-ADComputer to add computer accounts to the domain. Let’s take a look at how you can use a few of these cmdlets. Let’s say you want to quickly retrieve a list of members from the “Marketing Users” group in your domain. You can do that easily by using the following cmdlet:

 get-ADGroupMember -identity "Marketing Users"

The identity parameter is common throughout the AD cmdlet as a way of referencing a particular AD object. The identity parameter can take the form of a distinguished name (e.g., DC=cpandl,DC=com), an object GUID, SID, or samAccountName.

Another powerful feature of PowerShell, and of these AD cmdlets, is the ability to pipe the output from one cmdlet to another. For example, let’s say you want to find a user object in AD, and then disable that user object. You know the user’s samAccountName is kmyer, so you can use the following two cmdlets to accomplish the task:

 get-ADUser -identity kmyer | Set-ADUser -enabled $false

In this example, we're using the get-ADUser cmdlet to search for the user account with a samAccountName of kmyer. Once we find that user, we pipe it to the Set-ADUser cmdlet and pass it the parameter—enabled with the PowerShell $false flag to indicate that we want the account to be disabled.

This is a simple example that illustrates the power and simplicity of PowerShell and the AD cmdlets. Because 76 cmdlets are within this module, you can imagine that you can do a lot more with this feature. Let’s look at one more feature within this module that's worth exploring: the Active Directory PowerShell Drive.

The Active Directory PowerShell Drive Provider
What is a PowerShell Drive provider? PowerShell supports the concept of managing resources as if they were like drive volumes. Just as you can CD into a file folder, PowerShell Drives let you navigate other types of resources the same way. For example, in PowerShell 1, Microsoft provided a registry PowerShell Drive so that you could treat registry keys and values as folders and files. You could change directories in PowerShell to HKEY_LOCAL_MACHINE, then navigate through keys, adding and removing keys and values using commands similar to what you would use in the file system. Microsoft has provided a PowerShell Drive provider for AD along with the cmdlets. This PowerShell Drive lets you treat your AD hierarchy like a file system. To use this feature, open PowerShell with the AD module loaded. Then type:

 cd AD: 

You’ll notice that the drive prompt changes to reflect the new drive you're working from. If you type DIR from here, you'll get a list of all the partitions within your current AD forest. Let’s say that you want to navigate into your AD domain and create a new OU. From the top-level AD: drive context, type (replace DC=cpandl,DC=com with your AD domain's directory name):

 cd “DC=cpandl,DC=com” 

Now let’s say we want to create a new HR OU under the Marketing OU. To change to the Marketing OU folder, type:

 cd “OU=Marketing” 

Finally, to create the HR OU under Marketing, type:

 md “OU=HR” 

It's as simple as that. Figure 2 shows the output from these commands.

Streamline AD Management
Of course, this example is only the tip of the iceberg when using the AD PowerShell Drive. Using this method you can perform most tasks against AD that you can perform within a file system. And, you can include PowerShell Drive commands in scripts to further automate AD management.

I've only scratched the surface of what you can do with the new AD capabilities in PowerShell. Between the cmdlets and the AD provider, you have a whole new set of options for command-line management of AD in Windows 7 and Windows Server 2008 R2. I highly recommend you spend time working with this new module to learn how it can help streamline your AD management.