AD Gold Nuggets

Like any complex system, Active Directory (AD) and its related support tools have literally hundreds of commands and techniques to make administering it a little easier and more efficient. As you acquire AD skills and knowledge, your administrator toolkit will grow larger and you’ll branch into using less-well-known tools and methods. In this article I present several AD nuggets you might not have discovered yet.

Free GPO Disaster Recovery
Backup and recovery is a key area any AD administrator must pay attention to. But just instituting a domain controller (DC) backup and recovery plan isn’t enough. You also need a separate backup and recovery plan for Group Policy. Unlike DCs, Group Policy Objects (GPOs) are typically delegated to a larger group of organizational unit (OU) administrators, rather than just the overall AD service administrators. The more people who work with GPOs—especially relatively inexperienced admins—the greater the chance that a GPO will be accidentally (or intentionally) altered or deleted. Because changes to a production GPO almost always affect multiple users, restoring the GPO quickly is a high priority. You can restore a GPO from DC backups, but the process can be slow and obtrusive.

Setting up basic GPO backup and recovery is easy. Group Policy Management Console (GPMC), which is included in Windows Server 2008 and Windows Server 2008 R2 and available as a download for Windows Server 2003 (at http://bit.ly/4DpDVp), has a great library of 32 sample scripts to perform Group Policy maintenance. After you install GPMC in Server 2003, these scripts are located in C:Program FilesGPMCScripts. Although Server 2008 and R2 no longer include the scripts by default, they will work with these OS versions. You can download the scripts from Microsoft at http://bit.ly/1Jef98. In Server 2008 and R2, the scripts will install in C:Program FilesMicrosoft Group PolicyGPMC Sample Scripts. All the scripts let you perform various useful operations on GPOs; but the backup and recovery scripts we’re interested in for the purpose of this discussion include BackupGPO.wsf, BackupAllGPOs.wsf, RestoreGPO.wsf, and RestoreALLGPOs.wsf. From an AD administrator’s viewpoint, we’re most interested in BackupAllGPOs to back up all the GPOs in a domain and RestoreGPO to restore a single GPO.

The scripts are written in either VBScript or JScript. If cscript.exe isn’t your default scripting host, you’ll need to explicitly specify cscript.exe on the command line. To back up all the GPOs in your domain, navigate to the script directory and run

Cscript backupallgpos.wsf  [/Comment:] [/Domain:] 

The script will back up all the GPOs in your domain to the location you specify and create subfolders for each GPO, named by the 128-bit GUID that uniquely identifies the GPO. Once you’ve backed up all the GPOs, you can use RestoreGPO.wsf to restore them individually:

Cscript restoreGPO.wsf   /domain: 

Although these scripts will back up and restore both the GPOs in AD and the Group Policy templates on SYSVOL, they don’t back up or restore the links between the GPOs and the OUs they’re applied to. You must track these links separately, or you can use the ListSOMPolicyTree.wsf script to list the relationships between the GPOs and the site, domains, and OUs they could be linked to.

Monitoring FRS
An area related to Group Policy is SYSVOL, the folder structure on every DC that contains the domain’s Group Policy templates and logon scripts. A replication mechanism—File Replication Service (FRS) in Server 2003, Distributed File System Replication (DFSR) in Server 2008 and R2—ensures that the SYSVOL structure stays synchronized between all the DCs in a domain. Using DFSR for SYSVOL replication is a huge improvement over the trouble-prone FRS replication method. However, because DFSR requires both Server 2008 and a manual FRS-to-DFSR upgrade process, the majority of production domains still run FRS.

You should monitor FRS for two reasons. First, a properly functioning SYSVOL is critical to a healthy domain. However, most AD administrators don’t proactively check or monitor FRS—partly because FRS Event Log messages are infrequent and not especially informative, and partly because FRS problems take a while to surface. Second, you need to ensure that FRS is functioning properly before you attempt an upgrade to DFSR replication, or you might corrupt your SYSVOL.

Microsoft has an FRS monitoring tool called Ultrasound, which you can download at http://bit.ly/gMy6S. An unusual name for a Microsoft utility, the tool was christened Ultrasound because it was the successor to a simpler tool named Sonar. (Don’t ask me how Sonar got its name.) Ultrasound consists of three major components. One component is a small Windows Management Instrumentation (WMI) provider that’s installed on every DC. It gathers FRS status information and sends it to the next component: the Ultrasound controller. This component consists of a service and a database that holds the FRS status data the controller pulls from the monitored servers. The database can be either Microsoft SQL Server Desktop Engine (MSDE—which you can download at http://bit.ly/20HiM) or SQL Server, and it doesn’t have to be on the same system as the controller. The final component is the Ultrasound administrator’s console, which must be installed on the same system as the controller component. This is where you can add and remove members (DCs) that are being monitored and view the general health of the monitored FRS set. You can also drill down into a great level of detail. Because the administrative console is limited in where it can run, keeping it constantly open for operators is inconvenient and probably unnecessary. I recommend that you install it, use it to clean up any existing SYSVOL replication problems, then revisit it once a week. Although Ultrasound has been around for a while, and it has the unique look and feel of a tool that grew out of Microsoft’s Product Support Services (PSS) group, it gets the job done.

NTDSUTIL Scripting
We all use NTDSUTIL for relatively common tasks, such as metadata cleanup from unplanned DC failures. But did you know that you can build simple scripts to run NTDSUTIL actions in the task scheduler or interactively? Simply list the NTDSUTIL commands one after another on a single line. If the command has multiple arguments, enclose them in quotes.

A good script example is the AD snapshot feature available in Server 2008. This feature lets you use the Volume Shadow Copy Service (VSS) to create a snapshot of a domain’s data. You create the snapshot with the NTDSUTIL “snapshot” command. You can then use this information to quickly restore an object and all its attributes (including the hard-to-restore backlinks such as memberOf), through a combination of tombstone reanimation and PowerShell scripts.

For the snapshot feature to be useful, however, you must take snapshots on a regular basis. NTDSUTIL scripting lets you easily do so with the following one-line script:

Ntdsutil snapshot "activate instance ntds" create quit quit

Figure 1 shows the output from running this script. Add this script to Task Scheduler in a batch file. Similarly, you can create a script to view all the available snapshots, which is useful when you’re in a hurry to restore an object:

Ntdsutil snapshot "act inst ntds "list all" quit quit

You can then quickly look through the listings to determine which snapshot you want to mount with the database mounting tool (dsamain.exe, available at http://bit.ly/X4prc).

Preventing Accidental Deletion of OUs
Much of an AD administrator’s job involves one simple task: preventing accidental deletion of AD objects. The difficulty of this task is directly related to the number of people who have rights in the domain. A good AD security model includes some speed bumps to minimize this risk. Although these practices don’t constitute a complete solution by themselves, the “defense in-depth” principle ensures that their cumulative effect will make the domain a little safer.

One such speed bump is using AD’s own access control to prevent accidental deletion of OUs. Although security principals (users, groups, and computers) in an OU come and go, OUs are part of an organization’s structure and are rarely deleted. Starting with Server 2008, the Microsoft Directory Services Team made it easy to do what experienced AD admins had already been doing on their own: setting a Deny ACE (i.e., access control entry) on objects to prevent them from being inadvertently deleted.

In the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, you can enable a setting to protect an object from accidental deletion, as Figure 2 shows. This check box, located in the OU Properties page’s Object tab, sets Deny ACEs for the Delete and Delete Subtree permissions for the Everyone group. The check box must be clear for a deletion to take place.

You need to be aware of a few details when using this feature. First, this check box applies only to OUs. You can create, modify, and delete security principals in the OU with no problem. Second, the feature lacks inheritance—in other words, if you enable the feature for the top-level OU of an OU structure, it applies only to the OU for which you enabled it, not the OUs beneath that one. Although you can use .NET to write a script to apply the feature to other OUs, unless you have a particularly large OU structure, selecting the check box manually will probably take less time than writing (and exhaustively testing) a script. Because this feature sets a Deny ACE, you can apply this protection to any object in AD, but only the New OU wizard features an easy-to-use check box.

Attribute Access for Everyone
One of the AD challenges that small and medium-sized companies face is correctly populating data without the use of expensive add-on tools. AD is pre-populated with an attribute for practically everything you can think of—and a few things you can't (e.g., Telex-Number). The employeeID attribute is intended to store an employee’s unique ID number. However, there's no place in Active Directory Users and Computers where this attribute is exposed. An HR staff member or account administrator adding a new employee must use command-line tools such as dsmod or joeware's admod. Most account administrators aren't comfortable working with distinguished names (DNs), so a simple UI solution would be nice. Fortunately, an update to Active Directory Users and Computers for Windows 7 and Windows Vista provides an answer. The Remote Server Administration Tools (RSAT) for Vista (http://bit.ly/cnwzD) or Windows 7 (http://bit.ly/TYGxd) features an updated version of Active Directory Users and Computers (dsa.msc) with a welcome new feature: the Attribute Editor.

The Attribute Editor adds a key bit of functionality that’s in ADSIEDIT or the LDP editor, but not in the familiar Active Directory Users and Computers interface: You can edit any AD object attribute, not just the ones the Active Directory Users and Computers interface traditionally exposed. Using our previous scenario, Figure 3 shows how to add an employee ID number to the new employee Sosumi Areti (the new staff Liability Director). By default, the Attribute Editor shows only a subset of all attributes for the object. You can filter the attribute list by whether they have values, are writeable, are mandatory or optional, are constructed, are backlinks, or are system-only. The ability to expose a constructed attribute can be very handy; if you’re using fine-grained password policies in Server 2008, you can expose the effective password setting (effectivePso) for a user. Doing so is analogous to looking at the resultant set of policies for a user if you want to see what GPOs are affecting the user.

In addition to installing on Windows 7 or Vista, the Attribute Editor requires that you upgrade your Server 2003 forest schema to Server 2008 to update the forestwide display specifiers. An alternative manual workaround is available at http://bit.ly/ysFP1.

Note that the RSAT installation works differently in Windows 7 and Vista than in Windows XP and Server 2003. When you install the toolset, the Start menu doesn’t change—nothing appears to have installed. To make the tools appear, open the Control Panel Programs and Features applet, select Turn Windows features on or off, select Remote Server Administration Tools, Role Administration Tools, and drill down to the Active Directory Domain Services (AD DS) tools. (I encountered an R2 bug that requires you to check each tool individually, which I hope is fixed in RTM.) Finally, check the Advanced section of the View menu to see the Attribute Editor.

Controlling Replication
Although AD replication typically works well without administrator intervention, every AD administrator should know how to control it manually. Suppose that you accidentally delete an object and don’t notice it right away. Being able to quickly stop replication outside your site will prevent the deletion from affecting outside users. Several replication control methods are available.

The best-known method is to use Active Directory Sites and Services (dssite.msc) to manage AD’s sites and site links. Site links are the pathways upon which data is replicated. Start Active Directory Sites and Services and navigate to Sites, Inter-Site Transports, IP, then open the properties of the site link on which you want to disable replication, as Figure 4 shows. Click Change Schedule, select the entire range of days and hours in the schedule grid, and select Replication Not Available. This action disables replication between all sites that use the site link.

Using Active Directory Sites and Services disables replication only at the site level. You might need to disable replication at the DC level as well, perhaps to isolate schema changes or accidental deletions (if you’re quick and have a script already set up). To disable replication at the DC level, you need to use the kitchen sink of replication tools—REPADMIN.

REPADMIN has so many command switches, sub-options, and complexities that someone could write an entire book about it. For this article, let’s focus on the /options switch. If you use the standard /? switch to search REPADMIN’s help files, you won’t even see the /options switch. You must use /experthelp, which lists the more powerful switches that Microsoft clearly states “could break your Active Directory installation.” And if you’re running Server 2008, using /options is even more complicated; you must enter repadmin /?:options.

Once you figure out REPADMIN’s syntax, it’s the same for Server 2008 and Server 2003. Although replication is always a “pull” operation—meaning that a DC will always request replication to it, rather than push replication out from it—you’ll typically want to disable outbound replication because it applies to our schema and object deletion scenarios. To disable outbound replication on a single DC, run

Repadmin /options  +disable_outbound_repl

If you want to disable outbound replication for multiple DCs, you’ll have to write a simple script. To re-enable replication, change the “+” to a “-” and rerun the command.

The one exception to the REPADMIN /options command is that in Server 2008 you can disable outbound replication for an entire site—which is very handy in case of accidental deletion:

Repadmin /options site:  disable_outbound_repl

Several other advanced methods exist for controlling replication between individual DCs or groups of DCs, but they can be an administrative nightmare because the settings are so far outside where an AD administrator would typically look to resolve a replication problem. If you didn’t clearly document the actions, your DCs might need to be entirely rebuilt. Even the /options method isn’t easy for the casual troubleshooter to find. A solid production change-control process is extremely important.

Obscurely Useful
AD is a complex structure with numerous tricks and tools to make administration easier. Some methods are more obvious and more widely used. The approaches I present in this article are less well known, but I hope they add to your arsenal of useful techniques for managing your AD environment.

Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.