Active Directory operations can be automated in different ways. You can use C#, VB, command line tools (such as dsquery), VBScript, PowerShell, Perl, and so on. Since this book focuses on using PowerShell, let's examine the methodologies that are widely used to automate Active Directory operations using PowerShell.
There are three ways available to manage Active Directory using PowerShell. Each of these has its own advantages and operating environments:
The Microsoft Active Directory module
The Quest Active Directory PowerShell cmdlets
The native method of PowerShell
Let's dig into each of these and understand a bit more in terms of how to install, configure, and use them.
As the name indicates, this PowerShell module is developed and supported by Microsoft itself. This module contains a group of cmdlets that you can use to manage Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS). The Microsoft Active Directory module is introduced with the Windows Server 2008 R2 operating system and you need to have at least this version of OS to make use of the module. This module comes as an optional feature on Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 and gets installed by default when you install the AD DS or AD LDS server roles, or when you promote them as domain controllers. You can have this module installed on Windows 7 or Windows 8 by installing the Remote Server Administration Tools (RSAT) feature.
This module works by querying Active Directory through a service called Active Directory Web Services (ADWS), which is available in Windows Server 2008 R2 or later operating systems. This means your domain should have at least one domain controller with an operating system such as Windows Server 2008 R2 or above to make the module work.
Don't get disappointed if none of your domain controllers are upgraded to Windows Server 2008 R2. Microsoft has released a component called Active Directory Management Gateway Service that runs as the Windows Server 2008 R2 ADWS service and provides the same functionality on Windows Server 2003 or Windows Server 2008 domain controllers.
You can read more about ADWS and gateway service functionality at http://technet.microsoft.com/en-us/library/dd391908(v=ws.10).aspx
As mentioned earlier, if you promote a Windows Server 2008 R2 or later operating system to domain controller, there is no need to install this module explicitly. It comes with the domain controller installation process.
Installing Active Directory module on Windows 7, Windows 8, and Windows 8.1 is a two-step process. First, we need to install the Remote Server Administration Tool (RSAT) kit for the respective operating system; then we enable the Active Directory module, which is part of RSAT, as a second step.
First, download the RSAT package from one of the following links based on your operating system and install it with administrative privileges:
RSAT for Windows 8.1 http://www.microsoft.com/en-us/download/details.aspx?id=39296
RSAT for Windows 8 http://www.microsoft.com/en-us/download/details.aspx?id=28972
RSAT for Windows 7 with SP1 http://www.microsoft.com/en-us/download/details.aspx?id=7887
Once the RSAT package is installed, you need to enable Remote Server Administration Tools | Role Administration Tools | AD DS and AD LDS Tools | Active Directory module for Windows PowerShell via the Turn Windows features on or off wizard that you will find in the Control Panel of the Windows 7 or Windows 8 operating systems.
To install Active Directory module on Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 member servers, there is no need to install additional components. They are already part of the available features and it's just a matter of adding the feature to the operating system. This can be done using PowerShell or a regular GUI approach.
If you want to enable this feature using PowerShell in the aforementioned server operating systems, then use the following commands:
Import-Module ServerManager Add-WindowsFeature RSAT-AD-PowerShell
The RSAT package comes with the build on Windows Server 2008 R2 and Windows Server 2012. No need to install RSAT explicitly. The Server Manager PowerShell module in these operating systems contains the cmdlet, Add-WindowsFeature, which is used for installing features. In this case, we are installing Active Directory module for the Windows PowerShell feature in the AD DS and AD LDS tools.
If you want to perform this installation on remote servers, you can use the PSRemoting feature in PowerShell. This is the best approach if you want to deploy Active Directory module on all your servers in your environment.
This Active Directory module for Windows PowerShell can be installed using GUI interface as well. You need to use Server Manager to add Active Directory Module for Windows PowerShell using the Add Roles and Features Wizard as shown in following screenshot:
After installation, you can verify the functionality of Active Directory module by importing it and running a few basic cmdlets. A cmdlet is a simple command that is used in the Windows PowerShell environment. You can read more about cmdlets at http://msdn.microsoft.com/en-us/library/ms714395(v=vs.85).aspx.
Your installation is successful if you see your domain information after running the Get-ADDomain cmdlet, as shown in the following:
Import-Module ActiveDirectory Get-ADDomain
Note
One good thing about PowerShell is you can avoid the hassle of typing the whole command in the PowerShell window by using the Tab Expansion feature. You can type part of the command and press the Tab key to autocomplete it. If there are multiple commands (or cmdlets) that match the string you typed, then use Tab multiple times to select the one you need. It's pretty handy because some of the cmdlets in Active Directory are considerably long and it can get really frustrating to type them. Refer to the TechNet page at http://technet.microsoft.com/en-us/library/dd315316.aspx in order to understand how you can use this feature of PowerShell.
Previously, you learned that Microsoft Active Directory (MS AD) module was introduced with Windows Server 2008 R2. So, how did system administrators manage their Active Directory environments before the introduction of MS AD module? Quest Active Directory PowerShell cmdlets were present at that time to simplify AD operations. This Quest module has a bunch of cmdlets to perform various operations in Active Directory. Even after Microsoft released Active Directory module, many people still use Quest AD cmdlets because of its simplicity and the wide variety of management options it provides.
Quest AD module is part of the Quest ActiveRoles Server product, which is used for managing Active Directory objects. This Quest AD module is also referred to as ActiveRoles Management Shell for Active Directory because it is an integral part of the ActiveRoles product.
Quest software (now acquired by Dell) allows you to download ActiveRoles Management Shell for free and you can download a copy from https://support.software.dell.com/download-install-detail/5024645. You will find two versions of Quest AD Management Shell in the download page. Be sure to download the latest one: v1.6.0.
While trying to install the MSI, you might get a prompt saying Microsoft .NET Framework 3.5 Service Pack 1 or later is required. You will experience this even if you have .NET framework 4.0 installed on your computer. It seems the MSI is specifically looking for .NET 3.5 SP1. So, ensure that you have .NET Framework 3.5 SP1 installed before you start installing the Quest AD management Shell MSI. You might want to refer to the TechNet article at http://technet.microsoft.com/en-us/library/dn482071.aspx to understand NET Framework 3.5 installation process on Windows Server 2012 R2.
After the completion of MSI, you can start using this module in two ways. You can either search in Program Files for the application with the name ActiveRoles Management Shell for Active Directory or you can add the Quest snap-in into the regular PowerShell window.
It's preferred to add the snap-in directly into existing PowerShell windows rather than opening a new Quest AD Shell when you want to manage Active Directory using Quest cmdlets. Also if you are authoring any scripts based on Quest AD cmdlets, it is best to add the snap-in in your code rather than asking the script users to run it from a Quest AD Shell window.
The Quest AD Snap-in can be added to an existing PowerShell window using the following command:
Add-PSSnapin Quest.ActiveRoles.ADManagement
After adding the snap-in, you can list the cmdlets provided by this snap-in using the following command:
Get-Command -Module Quest.ActiveRoles.ADManagement
Get-Command is the cmdlet used to list cmdlets or functions inside a given module or snap-in after importing them. The version (v1.6.0) of Quest AD Shell has 95 cmdlets. Unlike Microsoft Active Directory module, the number of cmdlets will not change from one operating system to another in Quest AD Shell. The list of cmdlets is the same irrespective of the operating system where the tool is installed.
One advantage of Quest AD Shell is that it doesn't need Active Directory Web services, which is mandatory for Microsoft Active Directory module. Quest AD Shell works with Windows Server 2003-based domain controllers as well without the need to install Active Directory Management Gateway Service.
Both Microsoft AD module and Quest AD module have a dependency and require additional software or components installed. If your environment cannot afford the installation of new components, then you are left with only one option to manage Active Directory using native PowerShell, which uses .NET classes. This doesn't require any extra components to be installed and the only thing required is .NET, which is present by default on any Windows operating system.
To query all computers in the current domain, use a query given in the following command:
([ADSISearcher]"Objectclass=Computer").Findall()
The example shown in the following screenshot might look simple but, as you need to do more with the native method approach, the complexity of the code will increase. Also, you will find less help from the community when querying Active Directory using the native method. Because of these reasons, Microsoft AD module or Quest module are preferred for easy Active Directory operations. Use this approach only if you have no other option.
