Networking with Windows Server 2008 R2

Active Directory: Improving and Automating Identity and Access



      1. Using Windows PowerShell with Active Directory 66
      2. Selecting Functional Levels in Windows Server 2008 R2 78
      3. Active Directory Recycle Bin: Recovering Deleted Objects 82
      4. Offline Domain Join: Securing and Facilitating Deployment 86
      5. Service Accounts 87
      6. Best Practices Analyzer 88

For the Windows Server 2008 release, Microsoft consolidated and renamed its various
identity and access services to create the following five roles:
    1. Active Directory Certificate Services (AD CS)
    2. Active Directory Domain Services (AD DS)
    3. Active Directory Federation Services (AD FS)
    4. Active Directory Lightweight Directory Services (AD LDS)
    5. Active Directory Rights Management Services (AD RMS)
For Windows Server 2008 R2, these five roles remain in place and the visible Active
Directory infrastructure is functionally the same. You can still install the roles the same
way, by using Server Manager or Windows Optional Component Setup (Ocsetup.exe)
from the command line, although the Add Roles Wizard now requires you to install the
Microsoft .NET Framework 3.5.1 feature with Active Directory Domain Services, Active
Directory Lightweight Directory Services, and Active Directory Rights Management
Services roles. This requirement is to support the new Active Directory Web Services
module.
Note For more information on Active Directory Web Services, see the section “Introducing
Active Directory Web Services,” later in this chapter.

Once you have installed the Active Directory roles you need, you will find that all of the
familiar Active Directory objects and attributes are still the same, and all of your familiar
tools are still there. However, although the Active Directory roles in Windows Server 2008 R2
appear to be the same as those in Windows Server 2008, there are some substantial innovations
beneath the surface, particularly in the area of Active Directory administration.
The R2 release includes a new set of tools for managing Active Directory from Windows
PowerShell, a new graphical management utility that is based on those same Windows
PowerShell
cmdlets, and a long-requested mechanism for restoring Active Directory objects
that administrators have inadvertently deleted. There is also a new facility for joining workstations
to an AD DS domain when they do not have access to a domain controller, and an
Active Directory implementation of the Best Practices Analyzer (BPA) technology that should
be familiar to administrators of Microsoft Exchange Server.
These are all improvements that administrators can avoid entirely, if they so desire. You can
skip right over this chapter if you want to and continue to work with Active Directory the way
you always have on your new Windows Server 2008 R2 servers, and everything will function
just as it always has. However, if you choose to persevere and examine these new features,
you might find yourself approaching your Active Directory management tasks in a completely
new and better way. You might even learn to love the command prompt.


Using Windows PowerShell with Active Directory:
     
      As in many other areas of its operating system, Windows Server 2008 R2 leverages Windows
PowerShell as a major new management tool for Active Directory. Windows Server 2008
R2 includes no fewer than 85 new cmdlets for AD DS and AD LDS, which are designed to
replace the existing (non–Windows PowerShell) command prompt tools, such as Dsget.exe, Dsmod.
exe, and Dsadd.exe. For administrators not comfortable working from the command
prompt, Windows Server 2008 R2 also includes Active Directory Administrative Center
(ADAC), a new management console that provides a graphical interface to the functionality of
the Windows PowerShell cmdlets.

Using Active Directory Module for Windows PowerShell:

      You have already read about the enhanced capabilities of Windows PowerShell 2.0 in Chapter
1, “What’s New in Windows Server 2008 R2,” and you have seen some of what Windows
PowerShell can do with Hyper-V and Remote Desktop Services in Chapter 3, “Hyper-V: Scaling
and Migrating Virtual Machines,” and Chapter 4, “Remote Desktop Services and VDI: Centralizing
Desktop and Application Management.” Another major innovation in Windows Server
2008 R2 is the ability to use Windows PowerShell cmdlets to manage the AD DS and AD LDS
roles.
Using Windows PowerShell with Active Directory
Windows Server 2008 R2 implements the cmdlets for Active Directory management as a
Windows PowerShell module called ActiveDirectory. A Windows PowerShell 2.0 module is a
self-contained unit consisting of cmdlets, scripts, or other code that you must import into a
Windows PowerShell session before you can access its features.

Importing the Active Directory Module:

      When you add the AD DS or AD LDS role on a computer running Windows Server 2008 R2,
the system installs the Active Directory Module for Windows PowerShell and creates a shortcut
with the same name in the Administrative Tools program group. This shortcut launches
the Windows PowerShell environment and uses the Import-Module cmdlet to load the Active
Directory module. You can also import the module manually from a standard Windows
PowerShell
prompt by using the following command:
Import-Module ActiveDirectory
Once you have imported the module, the Active Directory cmdlets it contains become
available, but only within that Windows PowerShell session. If you open up another Windows
PowerShell window (without importing the module), the Active Directory cmdlets are not
available in that session.

Using the Active Directory Module Cmdlets:

      Active Directory Module for Windows PowerShell contains 90 cmdlets not found in a standard
Windows PowerShell session. Most (but not all) of the cmdlets in the module include the
initials AD as part of their names, so you can list them using the following command:
Get-Command *-AD*
The Active Directory cmdlets, which you can use individually or combine using the standard
PowerShell piping techniques, provide almost universal administrative access to AD DS
and AD LDS resources. For example, to create new AD DS objects, you can use any of the
following cmdlets:
  1. New-ADUser
  2. New-ADComputer
  3. New-ADGroup
  4. New-ADOrganizationalUnit
  5. New-ADObject
Each of these cmdlets supports parameters representing the possible attributes of the new
object. For example, the New-ADUser cmdlet has 60 possible parameters, as shown in Figure
5-1, generated by the Get-Help New-ADUser command.

        Figure 5-1 Command-line parameters for the New-ADUser cmdlet.

These parameters not only enable you to create a new object, but you can also specify
values for many of the object’s attributes using a single command, such as in the following
example:
New-ADUser –Name “Mark Lee” -SamAccountName “MarkLee” -GivenName “Mark”
-Surname “Lee” -DisplayName “Mark Lee” -Path ‘CN=Users,DC=example,DC=local’
-OfficePhone “717-555-1212” -Title “Account Manager”
-EmailAddress “mlee@example.com” -ChangePasswordAtLogon $true
Consider how many different processes you would have to perform and how many screens
you would have to access to create the user object for Mark Lee and set all the attributes
defined in this example using the Active Directory Users and Computers console. For custom
attributes, and those not specifically covered by a cmdlet’s parameters, you can use the
–OtherAttributes parameter, and to create objects not explicitly supported by a cmdlet, you
can use New-ADObject, and specify the type of object you want to create.
Of course, for any serious Windows PowerShell user, command-line parameters are only
one way to specify attribute values when creating a new object with the New-ADUser cmdlet.
Another possible method is to use an existing object as a template. When you specify the
name of the object you want to use as a template on the New-ADUser command line, using
the –instance parameter, the system copies all of the attribute values from the template to
the new object, except for those overridden by other parameters on the command line.
Yet another method, suitable for creating multiple Active Directory objects using a single
command, is to create a comma-separated value (CSV) file containing a list of the objects you
want to create and their attribute values. You can then use the Import-CSV cmdlet to pipe the
contents of the CSV file to the New-ADObject cmdlet, and the system will create each object
listed in the file in turn.
In addition to cmdlets for creating Active Directory objects, there are also cmdlets for
manipulating them, such as the following examples:
   1. Set-ADObject Modifies the properties of an Active Directory object
   2. Get-ADObject Gets or performs a search to retrieve one or more Active Directory
objects
   3. Move-ADObject Moves an Active Directory object or container from one container
to another or from one domain to another
   4. Restore-ADObject Restores a deleted Active Directory object
   5. Rename-ADObject Renames an Active Directory object
   6. Remove-ADObject Removes an Active Directory object
A comprehensive treatise on managing Active Directory using the capabilities provided by
the Active Directory Module for Windows PowerShell could easily fill this book. The preceding
are some extremely basic examples of how, with a little study and a little practice, you
can learn to enhance and streamline the processes by which you perform your regular Active
Directory management tasks, using the tools provided in Windows Server 2008 R2.