It was pointed out in a comment that in my series of posts on administering Active Directory (started with http://msmvps.com/blogs/richardsiddaway/archive/2012/01/03/get-ad-users-in-an-ou-tree.aspx and the posts coming forward)
I hadn’t actually discussed the tools I was using in the posts – in the spirit of better now then never I’ll put that right.
There are two areas of Active Directory administration we should think about:
- Data – users, groups, OUs, computers (possibly plus domains and forests)
- Service – sites, subnets, site links, replication, schema
Up to now I have concentrated on the data – mainly user administration. I will expand to other areas as we proceed.
Any one who has spent any time administering AD soon becomes familiar with AD Users and Computers and the associated tools. These are great for doing the odd ad hoc job but for bulk investigation or processing we need scripts. In years gone by this would have been VBScript but the world has moved on and PowerShell is the scripting tool of choice for the savvy Windows administrator.
If you need to get started with PowerShell look a the books available at www.manning.com. PowerShell in a month of lunches is a great starter. PowerShell in Practice and PowerShell and WMI will extend that knowledge to actually using PowerShell in the real world.
Now that we’ve decided PowerShell is our admin tool of choice – how do we work with AD. The starting point is that there are no AD admin cmdlets built into PowerShell v2 (or v3 for that matter). However, we do have access to a number of tools that we can use through PowerShell.
The Quest AD cmdlets have been available for a number of years. First issued in 2007 they are a free download in 32 and 64 bit versions from http://www.quest.com/powershell/activeroles-server.aspx. A pdf manual is also available. They install as a snapin on your workstation.
These cmdlets have a good coverage of AD data administration and also include PKI and Quest’s Active Roles administration. They have a number of advantages – especially the fact that you don’t have to install anything on your domain controllers and that they work with AD versions from Windows 2003 to Windows 2008 R2 out of the box. The main draw back is that they are non-Microsoft which is a big negative in some organisations.
Microsoft introduced a set of cmdlets for administering AD and a provider with Windows 2008 R2. If your domain controllers are running an earlier version of WIndows you can download versions of the cmdlets for Windows 2003 and Windows 2008 from the links provided at ttp://blogs.msdn.com/b/adpowershell/archive/2009/09/18/active-directory-management-gateway-service-released-to-web-manage-your-windows-2003-2008-dcs-using-ad-powershell.aspx.
The Microsoft cmdlets work through a web service that runs on the domain controllers. This is installed by default on Windows 2008 R2 but needs a specific install for older versions. I find this a drawback for legacy versions as I like to keep my domain controllers as clean as possible. If your domain is Windows 2008 R2 then install the RSAT tools on your workstation and you will get the AD cmdlets and provider.
Having looked at the Microsoft provider in a fair amount of detail recently I have to admit that it is better than I thought. I don’t like the navigational requirement to use ou = xxx to determine path but it is liveable with especially in scripts.
Scripting has a venerable tradition for AD administration. In PowerShell we use the [adsi] type accelerator which is a shortcut to System.DirectoryServices.DirectoryEntry. The class is a wrapper for standard ADSI access to AD. ADSI is COM based to add another level of complexity. All of these wrappers modify the objects returned to a greater or lesser extent. This can create some confusion as the methods you are used to from VBScript are available but not visible. You need to know how to use these objects to get the most from them – which is where the posts come in.
Searching AD in VBScript was painful but in PowerShell we get [adsisearcher] which is a type accelerator for System.DirectoryServices.DirectorySearcher. We have seen this in a number of posts – and will see it in the future.
Also available in the .NET fold for access through scripts is the System.DirectoryServices.ActiveDirectory namespace. This provides access to a number of classes that make it easier to deal with the service side – sites etc as we will see later. The latest addition with .NET 3.5 (needed for ISE and out-gridview) is System.DirectoryServices.AccountManagement. This namespace provides access to users and groups. The syntax is more complex but it supplies easy access to a number of pieces of functionality that we can’t do using other .NET classes.
Finally the System.DirectoryServices.Protocols supplies access to some deep level aspects of AD – for instance we can use it to return an object from being tombstoned. This namespace is not well documented and is not easy to decipher its usage.
I still turn to the Quest cmdlets – I’ve been using them since I was involved with the original beta testing. if you have Windows 2008 R2 you have the Microsoft cmdlets which provide analogous functionality. I would recommend using one (or better still both) sets of cmdlets. Use scripting to fill in the gaps and leave the provider alone except for specific jobs – it is very good for bulk creation of OUs!
I have been asked if I will be pulling all of the code I’m publishing on AD into a book. I hadn’t thought about it up to now. Is there enough interest for such a book?