Summary: Learn about the Microsoft Active Directory Windows PowerShell cmdlets, and use them to find active and disabled users.
Hey, Scripting Guy! I am wondering what the best way is to use Windows PowerShell to work with Active Directory. I have seen all different methods talked about on the Internet, and many of them require downloading and installing third-party software. Can you possibly discuss how to work with Active Directory and Windows PowerShell, and maybe even discuss the pros and the cons of each approach? It would help us at work as we try to set our strategic direction.
—TU
Hello TU,
Microsoft Scripting Guy Ed Wilson here. This week, the Scripting Wife and I are lying around on the beach in Kauai. Kauai, Hawaii, is a wonderful island that is like a garden paradise, with cobalt blue water that is so clear you can often see the ocean bottom while standing on the deck of a boat. Here is a picture of a turtle I took on my last dive trip to the island.
My first choice for working with Active Directory from within Windows PowrShell, is to use the Active Directory cmdlets that are supplied with Windows Server 2008 R2. There are actually a couple of ways to use these cmdlets. One way is to install the Remote Server Admin Tools (RSAT) for Windows Server 2008 R2 onto your Windows 7 computer. A link to these tools is on the Script Center Downloads page. There is a package for each version of Windows 7 (x86 and x64), as well as a build that is service-pack specific. Unfortunately, the installation cannot run from a server share, so the package must be copied locally. After it is copied, the installation proceeds without interruption. But that does not give you access to the actual tools; it simply places the files on your computer.
The first thing to do:
- Click the Start button, and then, on the Start menu, click Control Panel.
- Click Programs and Features and then click Turn Windows Features on or off.
- Click Windows Features to see if the RSAT tools are installed on the computer.
As shown in the following figure, on a default installation of Windows 7, the RSAT tools are not installed.
When I attempt to install the RSAT tools, I am prompted for administrative credentials, as shown in the following figure. A normal, non-elevated user cannot install the tool set.
I provide credentials. Everything should be groovy. Wait, not yet. I am now prompted to install update KB958830. What in the world is that? Well, it is the technical name for RSAT. Click Yes, accept the license agreement, and there will be no more prompts.
After the tools are installed, follow steps 1–3 above, find the Remote Server Administration Tools section, and choose the tools you want to make available. Unfortunately, this requires quite a bit of clicking because there is no way (that I know of) to click once and make all the tools available. The one tool you definitely do not want to inadvertently miss is under AD DS and AD LDS tools – Active Directory Module for Windows PowerShell. This critical check box is shown in the following figure.
After the RSAT tools have been installed and configured, the next step is to import the activedirectory module. To do this, use the Import-Module cmdlet, as shown here:
Import-Module activedirectory
On my system, at times this command generates this warning message: “WARNING: Error initializing default drive: 'Unable to find a default server with Active Directory Web Services running.'”
The warning is generated because I have several domain controllers, and not all of them have the Active Directory Management Gateway Service installed. Depending on which domain controller authenticated my workstation, the warning appears. The solution is to install the Active Directory Management Gateway Service on all of the non-Windows Server 2008 R2 domain controllers. The other solution is to ignore the warning and specify the server parameter each time when using one of the cmdlets (but that will mean the PSDrive will be unavailable).
More than six years ago, a different Microsoft Scripting Guy wrote an article called How Can I Get a List of All the Disabled User Account Accounts in Active Directory? it was an immediate classic that continues to generate discussion even today. The VBScript to retrieve disabled user accounts is cryptic at best and downright confusing at worst. It is not horribly long, as far as VBScripts go; it checks in at 16 lines of code. It also uses COM-based ADO, which as far as VBScripters go is part and parcel of the game. No, it is not the VBScript or the ADO that is confusing; it is the UserAccountControl bitmask attributes that are the game changer.
Luckily, for those of us who are using Windows PowerShell and the Microsoft Active Directory cmdlets, it takes a single line of code to retrieve the disabled users in the domain. The command is shown here (keep in mind that before running this command, I had imported the activedirectory module into the current Windows PowerShell host):
Get-ADUser -Filter 'enabled -eq $false' -Server dc3
Not only is the command a single line of code, but also it is a single line of readable code. I really do not need to explain the command at all because the code is clearly understandable. I get users from Active Directory, and I use a filter that looks for the enabled property set to false. I also specify that I want to query a server named dc3 (the name of one of the domain controllers on my network). The command and the associated output are shown in the following figure.
If I want to work with a specific user, I can use the identity parameter. The identity parameter accepts several things: DistinguishedName, SID, GUID, and SamAccountName. Probably, the easiest one to use is the SamAccountName. This command and associated output are shown here.
PS C:\Users\ed.IAMMRED> Get-ADUser -Server dc3 -Identity teresa
DistinguishedName : CN=Teresa Wilson,OU=Charlotte,DC=iammred,DC=net
Enabled : True
GivenName : Teresa
Name : Teresa Wilson
ObjectClass : user
ObjectGUID : 75f12010-b952-4d16-9b22-3ada7d26eed8
SamAccountName : Teresa
SID : S-1-5-21-1457956834-3844189528-3541350385-1104
Surname : Wilson
UserPrincipalName : Teresa@iammred.net
To use the DistinguishedName value for the identity parameter, I need to supply it inside a pair of single or double quotation marks. This command and associated output are shown here.
PS C:\Users\ed.IAMMRED> Get-ADUser -Server dc3 -Identity 'CN=Teresa Wilson,OU=Charlotte,DC=iammred,DC=net'
DistinguishedName : CN=Teresa Wilson,OU=Charlotte,DC=iammred,DC=net
Enabled : True
GivenName : Teresa
Name : Teresa Wilson
ObjectClass : user
ObjectGUID : 75f12010-b952-4d16-9b22-3ada7d26eed8
SamAccountName : Teresa
SID : S-1-5-21-1457956834-3844189528-3541350385-1104
Surname : Wilson
UserPrincipalName : Teresa@iammred.net
It is not necessary to use quotation marks when using the SID for the value of the identity parameter. This command and associated output are shown here.
PS C:\Users\ed.IAMMRED> Get-ADUser -Server dc3 -Identity S-1-5-21-1457956834-3844189528-3541350385-1104
DistinguishedName : CN=Teresa Wilson,OU=Charlotte,DC=iammred,DC=net
Enabled : True
GivenName : Teresa
Name : Teresa Wilson
ObjectClass : user
ObjectGUID : 75f12010-b952-4d16-9b22-3ada7d26eed8
SamAccountName : Teresa
SID : S-1-5-21-1457956834-3844189528-3541350385-1104
Surname : Wilson
UserPrincipalName : Teresa@iammred.net
Once again, I can also use the ObjectGUID for the identity parameter value. It does not require quotation marks either. This command and associated output are shown here.
PS C:\Users\ed.IAMMRED> Get-ADUser -Server dc3 -Identity 75f12010-b952-4d16-9b22-3ada7d26eed8
DistinguishedName : CN=Teresa Wilson,OU=Charlotte,DC=iammred,DC=net
Enabled : True
GivenName : Teresa
Name : Teresa Wilson
ObjectClass : user
ObjectGUID : 75f12010-b952-4d16-9b22-3ada7d26eed8
SamAccountName : Teresa
SID : S-1-5-21-1457956834-3844189528-3541350385-1104
Surname : Wilson
UserPrincipalName : Teresa@iammred.net
TU, that is all there is to using Windows PowerShell with Active Directory. Active Directory Week will continue tomorrow.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy