Active Directory Management with PowerShell in Windows Server 2008 R2

Leave a comment

July 20, 2011 by Rakesh Boraiah

Getting Started

Once you have the Active Directory Web Service installed, either as part of a native Windows Server 2008 R2 installation or using one of the downlevel versions as described above, you can start to manage Active Directory with the PowerShell module. To use this module you can either Remote Desktop to connect to a Domain Controller in your environment or more typically, and also better practise, use tools on your management workstation.

To do this from a Windows 7 based workstation you obviously already have PowerShell 2.0 installed by default, you should also install the Microsoft Remote Server Administration Tools for Windows 7 (RSAT). Amongst the many tools available in this package for remotely managing Windows Server is the Active Directory PowerShell module. After installation of RSAT the feature can be turned on by navigating to Control Panel, Programs and Features, Turn Windows Features On or Off.

The next step is to open a PowerShell session and use the Import-Module cmdlet to enable the use of the ActiveDirectory module. If this is something you would regularly use on your management workstation then it would be well worth your while adding this line to your PowerShell profile so that this module is available to you in every session without having to type this command.

Import-Module ActiveDirectory

Active Directory Provider

Windows PowerShell 1.0 shipped with a number of providers which gave you access to navigate and update data stores, such the file system or the registry in the Windows OS. Some other products also lend themselves to the concept of a provider and in Windows Server 2008 R2 the Active Directory module ships with a provider. This provider allows you to traverse and update Active Directory just like you were using the old style command prompt to navigate the Windows file system.

After importing the ActiveDirectory module, running the below cmdlet:


will display the list of providers available to you on the system.



To begin you can use the familiar cd (which is an alias in PowerShell for Set-Location) to change your location to that of the Active Directory hierarchical navigation system.



You can use other familiar commands to navigate your way around and make changes. We can use the well known dir to show us what is available. Then cd ‘DC=test,DC=local’ to start exploring the domain and then dir again will give a well-known view to that seen when first opening the Active Directory Users and Computers GUI tool.

If we then drill down further into the Users OU below the Sales OU we can observe some user accounts again by using dir.

This time we would like to update the Description field for the Joe Bloggs user account to read ‘Marketing Manager’. To do that we can use the Set-ItemProperty cmdlet with the path to the object we wish to change and the values we wish to set:

Set-ItemProperty -Path “CN=Joe Bloggs” -Name Description -value “Marketing Manager”

We can then read this property back with the Get-ItemProperty cmdlet:

Get-ItemProperty -Path “CN=Joe Bloggs” -Name Description

Or in a GUI view:

Active Directory Cmdlets

There are 76 cmdlets which make up the Active Directory module in Windows Server 2008 R2. You can view details of them via the Get-Command cmdlet and specifying the module of interest:

Get-Command –Module ActiveDirectory

The best way to learn about what each one does is to check them out in your test environment and also use the built-in PowerShell help documentation via the Get-Help cmdlet. For example:

Get-Help Get-ADUser -Full

This will give you detailed information about the cmdlet and how you should go about using it. Tip: I often find using the –Examples parameter of the Get-Help cmdlet to be a great kick start to learning how a cmdlet works; rather than wade through the text help you can instantly see how you might use it via some examples.

So let’s check out some of these cmdlets.

Creating User Accounts

Earlier in the article we talked about how when creating even a small number of users, repeatedly working through an individual wizard for each one could be a dull task and prone to consistency mistakes. Let’s say the HR department supplies you with a CSV file containing information about 10 new users and needs you to create these accounts ASAP before Monday.

For simplicity’s sake we’ll keep it to a few basic properties like Name and Description, of course you could and normally would have significantly more. Let’s also say to make your life easier you’ve added a few extra columns of you own like the SamAccountName and the Path (OU) where you would like the account to be created.

We can take of advantage of a standard PowerShell cmdlet Import-CSV which will read in a standard CSV file and create a set of objects based on the data inside the file. We can then send the results of this cmdlet down the pipeline to the New-ADUser cmdlet from the ActiveDirectory module and create the 10 accounts in a matter of seconds.

Import-CSV C:\scripts\users.csv | New-ADUser

It really is as simple as that and now you also can leave early on that Friday night like everyone else! Some of the results of those commands are shown below, nicely created in the OU specified in the CSV file.

You might be wondering how we made the leap from the information specified in the CSV to the New-ADUser cmdlet without having to specify any parameters with this cmdlet. In fact you could create a new user account with something like this:

New-ADUser –Name “John Smith” –SamAccountName “john.smith” –Description “Sales Manager” –Department “Sales” –EmployeeID “45896” –Path “ou=users,ou=sales,dc=test,dc=local” –Enabled $true

We have actually taken advantage of something known as ‘Pipeline Parameter Binding’. Since we gave the columns in the CSV file the same names as the parameters of the New-ADUser cmdlet and these parameters ‘Accept Pipeline Input ByPropertyName’ PowerShell is clever enough to match them up and use them. It’s almost like someone has thought to try and make your administrator life just that little bit easier.

Administering Groups

Another frequent maintenance task for the Active Directory administrator is the upkeep of groups and in particular membership of them. Let’s take the scenario of the newly created Marketing user accounts and a request to add all of them to the ‘Marketing Application’ group which is used to provide access to one of their main tools.

Again you could do that through Active Directory Users and Computers, edit the membership of the ‘Marketing Application’ group and manually enter all of their names to add them to the group. Or you could be smart, use the Get-ADUser cmdlet with a filter to select those users, pipe the results to the standard PowerShell cmdlet ForEach-Object and then use the Add-ADGroupMember cmdlet to populate the group. OK it might not make that big a difference for only five users, but imagine if that was five thousand.

Get-ADUser -filter * -SearchBase “ou=users,ou=marketing,dc=test,dc=local” | ForEach-Object {Add-ADGroupMember -Identity ‘Marketing Application’ -Members $_}

Note: the $_ at the end of that command refers to the ‘current object in the pipeline’, i.e. imagine it cycling through each of those users in the filter and substituting that user account for $_ each time.

The results of those cmdlets displayed in the GUI view of the group.

Fine-Grained Password Policies

You may be aware that in Windows Server 2008 a new feature was introduced whereby you were able to add multiple password policies into a single domain. In previous versions of Windows Server there was a restriction of a single password policy in a domain and consequently many organisations ended up deploying multiple domains just for that reason.

So a great new feature, but unfortunately the management tool for configuring these new password policies was wait for it……ADSI Edit! Whilst there were a number of freeware tools available around the time 2008 shipped which made this easier for the administrator, there are now out of the box PowerShell cmdlets with Windows Server 2008 R2 to help you manage these policies.

The first cmdlet deals with the Default Domain Password Policy Get-ADDefaultDomainPasswordPolicy, this will retrieve information about the policy which will apply to all users if there are no Fine-Grained polices.

There’s an equivalent Set-ADDefaultDomainPasswordPolicy which will allow you to make changes to any of the above settings.

You could though have done all of this through Group Policy Editor. The real gains come from being able to create and manage a Fine-Grained Password Policy. Use:

New-ADFineGrainedPasswordPolicy -Name “Standard Users PSO” -Precedence 500 -ComplexityEnabled $true -Description “Standard Users Password Policy” -DisplayName “Standard Users PSO” -LockoutDuration “0.00:12:00” -LockoutObservationWindow “0.00:15:00” -LockoutThreshold 10

to create a new Fine-Grained Password Policy called ‘Standard Users PSO’ and policy settings defined as per the parameter values.

In the above example the Lockout parameters should be specified in the format Day.Hour:Minutes:Seconds, i.e. LockoutDuration has been set to 12 minutes.

Fine-Grained Password Polices are applied to Users or Groups, so to apply the Standard Users PSO policy to the Marketing Users group the Add-ADFineGrainedPasswordPolicySubject cmdlet is available to you. Use:

Add-ADFineGrainedPasswordPolicySubject ‘Standard Users PSO’ -Subjects ‘Marketing Users’

to make this change.

Of course you may now have more than one Fine-Grained Password policy. To view details of them all use:

Get-ADFineGrainedPasswordPolicy -Filter {name -like “*”}

and you will see results similar to the below so that you can compare them.

Consequently some users may have more than one policy applied to them, so how do you tell which policy will be effective on them?

  • If a user is directly linked to a particular policy then that policy wins. (Generally it is bad practise to link a policy directly to a user; groups should be used for more effective management.)
  • If a user is a member of different groups which each have different policies applied to them then the policy with the lowest Precedence value will win.
  • If there are no Fine-Grained polices created then the Default Domain Policy will apply.

The best way to determine what policy will be applied to a user is to use the Get-ADUserResultantPasswordPolicy cmdlet.

For example, George Maker is in the Marketing Users and High Security Users groups, both of which have different Fine-Grained Password Policies applied to them. By running the command:

Get-ADUserResultantPasswordPolicy -Identity ‘George.Maker’

we will be given the resulting answer of which password policy will be applied to him. In this case it’s the ‘High Security Users PSO’ which is applied because it had the lowest precedence value.

FSMO Roles

In an Active Directory environment all Domain Controllers are equal, although some are more equal than others. There are five roles known as Flexible Single Master Operation roles which typically will live on different domain controllers.

  • Domain Naming Master
  • Schema Master
  • Infrastructure Master
  • PDCEmulator
  • RID Master

You can use the Get-ADForest and Get-ADDomain cmdlets to determine which Domain Controllers are holding these roles. (In my test environment there is only one DC, but you get the idea)

Whilst you could use the Netdom.exe command line tool to obtain the same information, you would need to use an alternative command line tool Ntdsutil.exe, with a different style and syntax, to transfer a FSMO role between Domain Controllers. Consequently by using the Move-ADDirectoryServerOperationMasterRole cmdlet to transfer FSMO roles between Domain Controllers, the administrator using the PowerShell module benefits from a consistent command line experience.

Move-ADDirectoryServerOperationMasterRole -Identity “2008R2DC2” -OperationMasterRole PDCEmulator,RIDMaster


Windows Server 2008 R2 ships with both PowerShell 2.0 and an Active Directory module containing a provider and cmdlets to enable you to manage Active Directory from the command line. This module has also now been made available for downlevel versions of Windows Server making it more readily accessible to those who might not be in a position to upgrade their Active Directory environments just yet.

It is highly worth spending some time with this module, even if it just getting to grips with the basics; it will help make you a better and more effective administrator of Active Directory.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: