Simple Talk is now part of the Redgate Community hub - find out why

Active Directory Management with PowerShell in Windows Server 2008 R2

One of the first things you notice with Windows Server 2008 R2 is that PowerShell 2.0 has become central to the admin function There is a powerful Active Directory module for Powershell that contains a provider and cmdlets that are designed to allow you to manage Active Directory from the command line. Now, you can also use versions for previous versions of Windows Server.

Windows Server 2008 R2 and Windows 7 both ship with PowerShell 2.0 installed by default, a fact which begins to demonstrate how important a consistent command line interface is becoming to Microsoft products. Which is why you as a sysadmin should be aware that, in order  to excel as a Windows administrator in the 21st Century you will need to get to grips with PowerShell. Starting with products like Exchange Server 2007 and System Center Virtual Machine Manager (SCVMM), moving into the core OS with Windows 2008 R2 and Windows 7, other product groups are now providing PowerShell support with their latest releases.

Active Directory Domain Services in Windows Server 2008 R2 ships with PowerShell support via cmdlets and a provider; in addition the new Active Directory Administrative Center is built on top of Windows PowerShell technology. In this article we will look at how you can use these new tools to more effectively manage your environment.

Active Directory Scripting

When responsible for an Active Directory environment the larger it becomes the more likely it is you are going to want to use some kind of automation tool to manage it effectively rather than be constantly clicking through a GUI interface to complete the same repetitive tasks. Even in environments of 100 users if you were tasked to provision 10 new users last thing on a Friday night ready for a Monday morning would you really want to click through the New User Wizard 10 times and could you guarantee you wouldn’t make any typing mistakes? Prior to the release of 2008 R2 some of the typical options for automating Active Directory with scripting were:

  • VBScript. There are hundreds of examples on the Internet, one of the best resources being the Microsoft Script Center.
  • PowerShell using ADSI, similar to how the VBScript examples are put together.
  • PowerShell using .NET Directory Services Classes.
  • PowerShell using Quest’s Active Directory cmdlets.

Each approach had its good and bad points, but going forward using the PowerShell cmdlets which ship as part of Active Directory in Windows Server 2008 R2 will be the route to take given that will be Microsoft’s focus for administrators compared to the above examples.

Active Directory Web Services

Introduced natively as part of Active Directory in Windows Server 2008 R2 is a new service, Active Directory Web Services. This technology permits remote management of any local directory service instance using web service protocols, which by default uses TCP port 9389. This service is included as part of an Active Directory Domain Services (or Active Directory Lightweight Directory Services) installation and is configured to run as an automatic service alongside the main ADDS service.

868-AD1.JPG

The Active Directory PowerShell cmdlets and provider which ship with Windows Server 2008 R2 are included as part of a module (modules are essentially the evolution of snapins from version 1 of PowerShell) and use this Web Service to manage Active Directory.

The good news for organisations who will not be immediately upgrading their Active Directory environments to Windows Server 2008 R2 and are currently running either Windows Server 2003 SP2 (or R2 SP2) or Windows Server 2008, with or without SP2, is that this Web Service has been made available as a Release To Web update. This means that you can have the same automation experience today with your current environment without going through the upgrade process for Active Directory which typically for most organisations involves significant planning and quite possibly cost.

There are some system requirements for this downlevel release which you should be aware of before you go diving straight in:

  • .NET Framework 3.5 with SP1 must be installed on the Windows Server 2003 or 2008 Domain Controller.

  • PowerShell 2.0 for Windows Server 2003 or 2008 must be installed, it’s available from Knowledge Base (KB) article 968929.
  • For Windows Server 2003 and 2008 based Domain Controllers, you must download and install the hotfix that is described in KB article 969166.
  • For Windows Server 2003& based Domain Controllers, you must download and install the hotfix that is described in KB article 969429.

  • For Windows Server 2008 based Domain Controllers without SP2, you must download and install the hotfix that is described in KB article 967574.

Note that it is not possible to install the Active Directory module on these downlevel servers and you will instead require a Windows Server 2008 R2 or Windows 7 instance to remotely manage these systems with the Active Directory module. Whilst not a requirement that you install the Web Service on every single downlevel Domain Controller, you may run into issues if you do not give enough coverage across your Domain Controllers. The majority of the Active Directory cmdlets though do include a Server parameter which allows you to specify a particular Domain Controller to connect to.

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

868-AD2.JPG

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:

Get-PSProvider

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

868-AD3.JPG

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.

868-AD4.JPG

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.

868-AD5.JPG

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

868-AD6.JPG

Or in a GUI view:

868-AD7.JPG

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.

868-AD8.JPG

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.

868-AD9.JPG

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.

868-AD10.JPG

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.

868-AD11.JPG

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.

868-AD12.JPG

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.

868-AD13.JPG

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)

868-AD14.JPG

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.

Further Information

If you want to know more the best place to look is the Active Directory PowerShell Blog maintained by the team who put the module together. Also, I have made an Active Directory PowerShell Quick Reference Guide which you might find useful for getting started or a handy reference to keep by your desk.

868-AD15.JPG

Summary

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.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue

Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.

Continue