Monday, June 30, 2014

Overview of Advanced Group Policy Management

By providing change control, offline editing, and role-based delegation, Microsoft® Advanced Group Policy Management (AGPM) can help you better manage Group Policy objects (GPOs) in your environment. AGPM is a key component of the Microsoft Desktop Optimization Pack (MDOP). AGPM 4.0 introduces support for searching, cross-forest management, and the latest Windows® operating systems. This white paper offers an overview of AGPM: its benefits, how it works, and how to evaluate it.

Contents

Imagine a tool that could help you take control of Group Policy. What would this tool do? It could help you delegate who can review, edit, approve, and deploy Group Policy objects (GPOs). It might help prevent widespread failures that can result from editing GPOs in production environments. You could use it to track each version of each GPO, just as developers use version control to track source code. Any tool that provided these capabilities, cost little, and was easy to deploy would certainly be worth a closer look.
Such a tool indeed exists, and it is an integral part of the Microsoft® Desktop Optimization Pack (MDOP) for Software Assurance. MDOP can help organizations reduce the cost of deploying applications, deliver applications as services, and better manage desktop configurations. Together, the MDOP applications shown in Figure 1 can give Software Assurance customers a highly cost-effective and flexible solution for managing desktop computers.
Figure 1. MDOP applications
Microsoft Advanced Group Policy Management (AGPM) is the MDOP application that can help customers overcome the challenges that can affect Group Policy management in any organization, particularly those with complex information technology (IT) environments. A robust delegation model, role-based administration, and change-request approval provide granular administrative control. For example, you can delegate Reviewer, Editor, and Approver roles to other users—even users who do not typically have access to production GPOs. (Editors can edit GPOs but cannot deploy them; Approvers can deploy GPO changes.)
AGPM can also help reduce the risk of widespread failures. You can use AGPM to edit GPOs offline, outside of the production environment, and then audit changes and easily find differences between GPO versions. In addition, AGPM supports effective change control by providing version tracking, history capture, and quick rollback of deployed GPO changes. It even supports a management workflow by allowing you to create GPO template libraries and send GPO change e-mail notifications.
This white paper describes the key features of AGPM, such as change control and role-based delegation. The paper then describes how Software Assurance customers can begin evaluating AGPM today.
The AGPM archive provides offline storage for GPOs. As Figure 2 shows, changes that you make to GPOs in the archive do not affect the production environment until you deploy the GPOs. By limiting changes to the archive, you can edit GPOs and test them in a safe environment, without affecting the production environment. After reviewing and approving the changes, you can then deploy them with the knowledge that you can quickly roll them back if they have an undesired effect.
Figure 2. Offline editing
AGPM has a server component (the AGPM Service) and a client component (the AGPM snap-in), each of which you install separately. First, you install Microsoft Advanced Group Policy Management - Server on a system that has access to the policies that you want to manage. Then, you install the Microsoft Advanced Group Policy Management - Client on any system from which Group Policy administrators will review, edit, and deploy GPOs.
The AGPM snap-in integrates completely with the Group Policy Management Console (GPMC), as Figure 3 shows. Click Change Control in the console tree to open AGPM in the details pane and to manage the AGPM archive on the Contents tab. Here, you can review, edit, and deploy controlled GPOs (that is, GPOs in the archive). You can also take control of uncontrolled GPOs (that is, GPOs that are not in the archive), approve pending changes, and manage GPO templates. On the Domain Delegation tab, AGPM Administrators (Full Control) delegate roles to AGPM users and configure e-mail notifications. Configure the AGPM Server connection on the AGPM Server tab. AGPM 3.0 introduced the Production Delegation tab, which AGPM Administrators can use to delegate permission to edit GPOs in the production environment.
Figure 3. AGPM integration with the GPMC
AGPM provides advanced change control features that can help you manage the lifecycle of GPOs. Many of the AGPM change control concepts will be familiar to administrators who have experience using common version-control tools, such as the version control feature in Microsoft Office SharePoint® Server 2007. The following steps are necessary to change and deploy a GPO:
1.      Check out the GPO from the archive.
2.      Edit the GPO as necessary.
3.      Check in the GPO to the archive.
4.      Deploy the GPO to production.
Change control means more than locking a GPO to prevent multiple users from changing it at the same time. AGPM keeps a history of changes for each GPO, as shown in Figure 4. You can deploy any version of a GPO to production, so you can quickly roll back a GPO to an earlier version if necessary. AGPM can also compare different versions of a GPO, showing added, changed, or deleted settings. Therefore, you can easily review changes before approving and deploying them to the production environment. In addition, a complete history of each GPO enables you to audit not only changes but also all activities related to that GPO.
Figure 4. GPO history
Group Policy already provides a rich delegation model that allows you to delegate administration to regional and task-oriented administrators. However, Group Policy also lets administrators approve their own changes. In contrast, AGPM provides a role-based delegation model that adds a review and approval step to the workflow, as shown in Figure 5.
Figure 5. Role-based delegation
An AGPM Administrator has full control of the AGPM archive. In addition to the AGPM Administrator role, AGPM defines three special roles to support its delegation model:
·        Reviewer. Reviewers can view and compare GPOs. They cannot edit or deploy GPOs.
·        Editor. Editors can view and compare GPOs. They can also check out GPOs from the archive, edit GPOs, and check in GPOs to the archive. Editors can request deployment of a GPO.
·        Approver. Approvers can approve the creation and deployment of GPOs. (When Approvers create or deploy a GPO, approval is automatic.)
As an AGPM Administrator, you can delegate these roles to users and groups for all controlled GPOs within the domain (domain delegation). For example, you can delegate the Reviewer role to users, allowing them to review any controlled GPO in the domain. You can also delegate these roles to users for individual controlled GPOs. Rather than allow users to edit any controlled GPO in the domain, for example, you can give them permission to edit a specific controlled GPO by delegating the Editor role for that GPO only.
AGPM 4.0 introduces the ability to filter the list of GPOs that it displays. For example, you can filter the list by name, status, or comment. You can even filter the list to show GPOs that were changed by a particular user or on a specific date. AGPM displays partial matches, and searches are not case sensitive.
AGPM supports complex search strings using the format column: string, where column is the name of the column by which to search and string is the string to match. For example, to display GPOs that were checked in by Jerry, type state: “checked in” changed by: Jerry in the Search box. Figure 6 shows another example. You can also filter the list by GPO attributes by using the format attribute: string, where attribute is the name of the GPO attribute to match. To display all GPOs that use the Windows® Management Instrumentation (WMI) filter called MyWMIFilter, type wmi filter: mywmifilter in the Search box.
Figure 6. Search example
When searching for GPOs, you can use special terms to search by date, dynamically. These special terms are the same terms that you can use when using Windows Explorer to search for files. For example, you can filter the list to display GPOs that were changed today, yesterday, this week, last week, and so on.
In addition to filtering, AGPM 4.0 also introduces cross-forest management. You can use the following process to copy a controlled GPO from a domain in one forest to a domain in a second forest:
1.      Export the GPO from a domain in the first forest to a CAB file, by using AGPM (Figure 7).
Figure 7. GPO export
2.      On a computer in a domain in the first forest, copy the CAB file to a portable storage device.
3.      Insert the portable storage device into a computer in a domain in the second forest.
4.      Import the GPO into the archive in a domain in the second forest, by using AGPM.
When you import the GPO into the second forest, you can import it as a new controlled GPO. You can also import it to replace the settings of an existing GPO that is checked out of the archive.
The obvious benefit of cross-forest management is testing. Combined with offline editing and change control, cross-forest management enables you to test GPOs in a controlled test environment (the first forest). After verifying the GPO, you can move it into the production environment (the second forest).
Three versions of AGPM are available: AGPM 2.5, AGPM 3.0, and AGPM 4.0. Each is incompatible with the others and supports different Windows operating systems. For more information about choosing the right version of AGPM for your environment and about the Windows operating systems that each supports, see Choosing Which Version of AGPM to Install.
AGPM 4.0 introduces support for Windows 7 and Windows Server® 2008 R2. Additionally, AGPM 4.0 still supports Windows Vista® with Service Pack 1 (SP1) and Windows Server 2008. Table 1 describes limitations in mixed environments that include newer and older Windows operating systems.
Table 1. Limitations in Mixed Environments
If the AGPM Server 4.0 runs on:
And the AGPM Client 4.0 runs on:
AGPM 4.0 is:
Windows Server 2008 R2 or Windows 7
Windows Server 2008 R2 or Windows 7
Supported
Windows Server 2008 R2 or Windows 7
Windows Server 2008 or
Windows Vista with SP1
Supported, but cannot edit policy settings or preference items that exist only in Windows Server 2008 R2 or Windows 7
Windows Server 2008 or
Windows Vista with SP1
Windows Server 2008 R2 or Windows 7
Unsupported
Windows Server 2008 or
Windows Vista with SP1
Windows Server 2008 or
Windows Vista with SP1
Supported, but cannot report or edit policy settings or preference items that exist only in Windows Server 2008 R2 or Windows 7
Forsyth County covers the Winston-Salem, North Carolina, metropolitan area. The county’s population of nearly 325,000 is located in a 410-square-mile area. The county’s IT department supports approximately 1,400 users and 1,650 desktop computers.
Forsyth County needed a solution for managing desktop computers—a solution that did not compromise server security, helped the County nimbly update desktop computer configurations, and provided a rich history of changes. Michael Wilcox, MIS client services supervisor, said, “I attended a seminar on Group Policy and learned about Microsoft Advanced Group Policy Management. I was impressed with how it could enhance the delegation capabilities for administrators.” Forsyth County went on to implement AGPM.
After deploying AGPM, Forsyth County immediately began realizing benefits. “It’s amazing. Managing our desktop configurations is so much easier. We’d be floundering without it,” Wilcox said. Using AGPM, the county can easily and safely build GPOs. It can create and change GPOs without affecting the production environment. Importantly, administrators at Forsyth County don’t need to manually document their changes, because AGPM keeps a rich history of such changes. According to Wilcox, “Advanced Group Policy Management has been like a magic bullet for us. Its automated change management and workflow-enabled delegation capabilities are impressive. I wouldn’t be able to manage GPOs without it.”
AGPM is an add-on license available only to Software Assurance customers. Begin your evaluation today:
·        Download and evaluate AGPM as part of MDOP
MDOP is available to Volume Licensing customers, Microsoft Development Network (MSDN®) subscribers, and Microsoft TechNet subscribers. The evaluation includes a step-by-step guide that walks you through most AGPM capabilities.
·        See Microsoft Desktop Optimization Pack on Microsoft.com
To learn how AGPM and MDOP for Software Assurance can help you better manage GPOs, see http://go.microsoft.com/fwlink/?LinkId=160297.
·        See Microsoft Desktop Optimization Pack on TechNet

For technical information about AGPM and MDOP for Software Assurance, see http://www.microsoft.com/technet/mdop on TechNet.

Thursday, June 26, 2014

Active Directory Rights Management Services

      Active Directory Rights Management Services (AD RMS) is an information protection technology that works with AD RMS-enabled applications to help safeguard digital information from unauthorized use. Content owners can define who can open, modify, print, forward, or take other actions with the information.
AD RMS Documentation Roadmap

Installed Help

Help installed with Windows Vista and Windows Server 2008 is also available in the Windows Server 2008 Technical Library.

Design the WSUS Server Layout

This topic describes simple Windows Server Update Services (WSUS) 3.0 SP2 deployments that use a single WSUS server and complex scenarios that include a WSUS server hierarchy or a WSUS server on an isolated network segment.
In this topic:

WSUS deployment that uses a single WSUS server

The most basic WSUS deployment consists of a WSUS server that serves client computers on a private network, as shown in the following image:

Simple WSUS Deployment
The WSUS server connects to Microsoft Update to download updates. This process is known as synchronization. During synchronization, WSUS determines whether any new updates are available since the last synchronization. The first time that a WSUS server synchronizes, all updates are available for download. The first synchronization can take an hour or longer to complete. Subsequent synchronizations take significantly less time.

WSUS deployment that uses multiple connected WSUS servers

A WSUS deployment can consist of multiple connected servers. When you connect multiple WSUS servers, you create at least one upstream WSUS server and at least one downstream WSUS server. This configuration creates a hierarchy of WSUS servers, as shown in the following image:
WSUS Servers Chained Together
You can synchronize a WSUS server to another WSUS server instead of to Microsoft Update. The WSUS server that connects to Microsoft Update is known as the root WSUS server.
ImportantImportant
The downstream server must always synchronize to an upstream server. If you attempt to synchronize an upstream server to a downstream server, you effectively create a closed loop. This configuration is not supported.

A WSUS server hierarchy deployment offers the following benefits:
  • You can download updates one time from the Internet and then distribute the updates to client computers by using downstream servers. This method saves bandwidth on the corporate Internet connection.
  • You can download updates to a WSUS server that is physically closer to the client computers, for example, in branch offices.
  • You can set up separate WSUS servers to serve client computers that use different languages of Microsoft products.
  • You can scale WSUS for a large organization that has more client computers than one WSUS server can effectively manage.
noteNote
We recommend that you do not create a WSUS server hierarchy that is more than three levels deep. Each level adds time to propagate updates throughout the connected servers. While there is no theoretical limit to a hierarchy, only deployments with a hierarchy of five levels deep have been tested by Microsoft Corporation.

You can connect WSUS servers in Autonomous mode (to achieve distributed administration) or in Replica mode (to achieve centralized administration). You do not have to deploy a server hierarchy that uses only one mode: you can deploy a WSUS solution that uses both autonomous and replica WSUS servers.

Autonomous mode (distributed administration)

Distributed management by using autonomous mode is the default installation option for WSUS. In autonomous mode, an upstream WSUS server shares updates with downstream servers during synchronization. Downstream WSUS servers are administered separately and they do not receive update approval status or computer group information from the upstream server. By using the distributed management model, each WSUS server administrator selects update languages, creates computer groups, assigns computers to groups, tests and approves updates, and makes sure that the correct updates are installed to the appropriate computer groups.
The following image shows how you might deploy autonomous WSUS servers in a branch office environment:
WSUS Distributed Management

Replica mode (centralized administration)

In replica mode, an upstream WSUS server shares updates, approval status, and computer groups with downstream servers. Downstream replica servers inherit update approvals and are not administered separately from the upstream WSUS server.
The following image shows how you might deploy replica WSUS servers in a branch office environment.
WSUS Centralized Management (Replica Role)
If you set up several replica servers to connect to a single upstream WSUS server, do not schedule synchronization to run at the same time on each replica server. This practice will avoid sudden surges in bandwidth usage.

WSUS deployment for disconnected networks

If the corporate network includes a network segment that is not connected to the Internet, you can deploy WSUS in the manner shown in the following drawing to support update management on that segment. In this case, you create a WSUS server that is connected to the Internet but is isolated from the intranet. After you download updates to the WSUS server, you can export the updates to removable media, hand-carry the removable media to a WSUS server on the disconnected network segment, and import the updates to that server.
Distributing Updates on an Isolated Segment This method of using WSUS is also appropriate for organizations that have high-cost or low-bandwidth links to the Internet. Downloading updates for all Microsoft products throughout an organization can be bandwidth intensive. This method enables organizations to download updates one time and then distribute updates locally by using inexpensive removable media. For more information about this scenario, see Configure a Disconnected Network to Receive Updates.

WSUS deployment with Network Load Balancing clusters

Network Load Balancing (NLB) can increase the reliability and performance of a network. You can set up multiple WSUS servers that share a single SQL Server failover cluster, as shown in the following image. For more information about how to deploy WSUS with NLB, see the Configure WSUS for Network Load Balancing section of the WSUS Operations Guide.
c5b8a565-1d8f-40ba-b63c-6259d27692e7

WSUS deployment with roaming client computers

If the network includes mobile users who log on to the network from different locations, you can configure WSUS to let roaming users update their client computers from the WSUS server that is closest to them geographically. In this configuration, shown in the following image, one WSUS server is deployed in each region, and each region is a DNS subnet. All client computers are directed to the same WSUS server name, which resolves in each subnet to the nearest physical WSUS server. For more information about how to configure DNS to support roaming client computers, see the Configure WSUS for Roaming Client Computers section of the WSUS Operations Guide.
fabc9790-e6b5-43d8-8c6b-eeaf41ff8980

Wednesday, June 25, 2014

Implement Role-Based Administration

You can use role-based administration to organize certification authority (CA) administrators into separate, predefined CA roles, each with its own set of tasks. Roles are assigned by using each user's security settings. You assign a role to a user by assigning that user the specific security settings that are associated with the role. A user that has one type of permission, such as Manage CA permission, can perform specific CA tasks that a user with another type of permission, such as Issue and Manage Certificates permission, cannot perform.
noteNote
Role-based administration is supported by both Windows Server® 2008 and Windows Server 2003 enterprise and stand-alone CAs.

The following table describes the roles, users, and groups that can be used to implement role-based administration. To assign a role to a user or group, you must assign the role's corresponding security permissions, group memberships, or user rights to the user or group. These security permissions, group memberships, and user rights are used to distinguish which users have which roles.

 

Roles and groups Security permission Description
CA administrator
Manage CA
Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager
Issue and Manage Certificates
Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.
Backup operator
Back up file and directories
Restore file and directories
Perform system backup and recovery. Backup is an operating system feature.
Auditor
Manage auditing and security log
Configure, view, and maintain audit logs. Auditing is an operating system feature. Auditor is an operating system role.
Enrollees
Read
Enroll
Enrollees are clients who are authorized to request certificates from a CA. This is not a CA role.
All CA roles are assigned and modified by members of local Administrators, Enterprise Admins, or Domain Admins. On enterprise CAs, local administrators, enterprise administrators, and domain administrators are CA administrators by default. Only local administrators are CA administrators by default on a stand-alone CA. If a stand-alone CA is installed on a server that is joined to an Active Directory domain, domain administrators are also CA administrators.
The CA administrator and certificate manager roles can be assigned to Active Directory users or local users in the Security Accounts Manager (SAM) of the local computer, which is the local security account database. As a best practice, you should assign roles to group accounts instead of individual user accounts.
Only CA administrator, certificate manager, auditor, and backup operator are CA roles. The other users described in the table are relevant to role-based administration and should be understood before assigning CA roles.
Only CA administrators and certificate managers are assigned by using the Certification Authority snap-in. To change the permissions of a user or group, you must change the user's security permissions, group membership, or user rights.

To set CA administrator and certificate manager security permissions for a CA

  1. Open the Certification Authority snap-in.
  2. In the console tree, click the name of the CA.
  3. On the Action menu, click Properties.
  4. Click the Security tab, and specify the security permissions.

Roles and activities

Each CA role has a specific list of CA administration tasks associated with it. The following table lists all the CA administration tasks along with the roles in which they are performed.

 

Activity CA administrator Certificate manager Auditor Backup operator Local administrator Notes
Install CAs




X

Configure policy and exit modules
X





Stop and start the Active Directory Certificate Services (AD CS) service
X





Configure extensions
X





Configure roles
X





Renew CA keys




X

Define key recovery agents
X





Configure certificate manager restrictions
X





Delete a single row in the CA database
X





Delete multiple rows in the CA database (bulk deletion)
X
X



The user must be both a CA administrator and a certificate manager. This activity cannot be performed when role separation is enforced.
Enable role separation




X

Issue and approve certificates

X




Deny certificates

X




Revoke certificates

X




Reactivate certificates that are placed on hold

X




Renew certificates

X




Enable, publish, or configure certificate revocation list (CRL) schedules
X





Recover archived keys

X



Only a certificate manager can retrieve the encrypted key data structure from the CA database. The private key of a valid key recovery agent is required to decrypt the key data structure and generate a PKCS #12 file.
Configure audit parameters


X


By default, the local administrator holds the system audit user right.
Audit logs


X


By default, the local administrator holds the system audit user right.
Back up the system



X

By default, the local administrator holds the system backup user right.
Restore the system



X

By default, the local administrator holds the system backup user right.
Read the CA database
X
X
X
X

By default, the local administrator holds the system audit and system backup user rights.
Read CA configuration information
X
X
X
X

By default, the local administrator holds the system audit and system backup user rights.

Additional considerations

  • Enrollees are allowed to read CA properties and CRLs, and can request certificates. On an enterprise CA, a user must have Read and Enroll permissions on the certificate template to request a certificate. CA administrators, certificate managers, auditors, and backup operators have implicit Read permissions.
  • An auditor holds the system audit user right.
  • A backup operator holds the system backup user right. In addition, the backup operator has the ability to start and stop the Active Directory Certificate Services (AD CS) service.

Assigning roles

The CA administrator for a CA assigns users to the separate roles of role-based administration by applying the security settings required by a role to the user's account. The CA administrator can assign a user to more than one role, but the CA is more secure when each user is assigned to only one role. When this delegation strategy is used, fewer CA tasks can be compromised if a user's account becomes compromised.

Administrator concerns

The default installation setting for a stand-alone CA is to have members of the local Administrators group as CA administrators. The default installation setting for an enterprise CA is to have members of the local Administrators, Enterprise Admins, and Domain Admins groups as CA administrators. To limit the power of any of these accounts, they should be removed from the CA administrator and certificate manager roles when all CA roles are assigned.
As a best practice, group accounts that have been assigned CA administrator or certificate manager roles should not be members of the local Administrators security group. Also, CA roles should only be assigned to group accounts and not individual user accounts.
noteNote
Membership in the local Administrators group on the CA is required to renew a CA certificate. Members of this group can assume administrative authority over all other CA roles.

Using Loopback Processing to Configure User Settings

The User Group Policyloopback processing mode policy setting is an advanced option that is intended to keep the configuration of the computer the same regardless of who logs on. This option is appropriate in certain closely managed environments, such as servers, terminal servers, classrooms, public kiosks, and reception areas. Setting the loopback processing mode policy setting applies the same user settings for any user who logs onto the computer, based on the computer.
When you apply Group Policy objects to users, normally the same set of user policy settings applies to those users when they log on to any computer. By enabling the loopback processing policy setting in a GPO, you can configure user policy settings based on the computer that they log on to. Those settings are applied regardless of which user logs on. When you use this option, you must ensure that both the computer and user portions of the GPO are enabled.
You can set the loopback policy in the Group Policy Object Editor snap-in by using the User Group Policy loopback processing mode policy setting under Computer Settings\Administrative settings\System\Group Policy. Two options are available:
Merge mode   In this mode, the list of GPOs for the user is gathered during the logon process. Then, the list of GPOs for the computer is gathered. Next, the list of GPOs for the computer is added to the end of the GPOs for the user. As a result, the computer’s GPOs have higher precedence than the user’s GPOs.
Replace mode   In this mode, the list of GPOs for the user is not gathered. Instead, only the list of GPOs based on the computer object is used. The User Configuration settings from this list are applied to the user.

Saturday, June 21, 2014

Active Directory Domain Services Database Mounting Tool (Snapshot Viewer or Snapshot Browser) Step-by-Step Guide

Applies To: Windows Server 2008
This guide shows how you can use an improved version of Ntdsutil and a new Active Directory® database mounting tool in Windows Server® 2008 to create and view snapshots of data that is stored in Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS), without restarting the domain controller or AD LDS server. A snapshot is a shadow copy—created by the Volume Shadow Copy Service (VSS)—of the volumes that contain the Active Directory database and log files.
noteNote
During product development, this feature has also been known by other names, including Snapshot Viewer, Snapshot Browser, and Active Directory data mining tool.

The Active Directory database mounting tool (Dsamain.exe) can improve recovery processes for your organization by providing a means to compare data as it exists in snapshots that are taken at different times so that you can better decide which data to restore after data loss. This eliminates the need to restore multiple backups to compare the Active Directory data that they contain.
This guide provides step-by-step instructions for using the Active Directory database mounting tool, including creating, listing, and mounting snapshots of AD DS; preparing them for viewing as a Lightweight Directory Access Protocol (LDAP) server; and viewing the data itself.
For more information about VSS snapshots, see Shadow Copies and Shadow Copy Sets (VSS) (http://go.microsoft.com/fwlink/?LinkId=90631).

Who should use this guide?

The following individuals should review this information about the Active Directory database mounting tool:
  • Information technology (IT) planners and analysts who are technically evaluating the product
  • Enterprise IT planners and designers for organizations
  • Administrators, operators, and managers who are responsible for IT operations, including recovery of deleted Active Directory data

Scenarios for using the Active Directory database mounting tool

This section describes common scenarios in which you can use the Active Directory database mounting tool.

Simplifying the forest recovery process

For organizations that have domain controllers running Windows Server 2003, the forest recovery process requires a determination of which backup is best to use for recovery. In general, you must consider whether to restore a recent backup of your data or an older backup that you believe may be safer. Choosing a more recent backup recovers more useful data, but it might increase the risk of reintroducing dangerous data into the restored forest.
To determine which backup is best, you must restore it to a domain controller to view its contents. Each restore operation requires that you restart the domain controller in Directory Services Restore Mode (DSRM).
For some organizations, the loss of productivity caused by the time required for such restore operations is great. These organizations often must keep detailed logs about the Active Directory health state on a daily basis so that, in case of a failure throughout the forest, the approximate time of failure can be identified.
In a forest recovery scenario, the ability to precisely determine which backup contains the best data to recover can drastically reduce downtime.

Auditing modified and deleted objects

Dsamain.exe helps you examine any changes that are made to Active Directory data. For example, if an object is accidentally modified, you can use this tool to examine the changes and to help you better decide how to correct them if necessary.
By scheduling a task to regularly create snapshots of the AD DS database, you can keep detailed records of AD DS data as it changes over time. You can create AD DS snapshots without devoting as much time and storage space as Windows Server Backup requires for critical-volume backups.

Requirements for using the Active Directory database mounting tool

You do not need any additional software to use the Active Directory database mounting tool. All the tools that are required to use this feature are built into Windows Server 2008 and are available if you have the AD DS or the AD LDS server role installed. These tools include the following:
  • A new ntdsutil snapshot operation that you can use to create, list, mount, and unmount snapshots of AD DS or AD LDS data

    noteNote
    You are not required to run the ntdsutil snapshot operation to use Dsamain.exe. You can instead use a backup of the AD DS or AD LDS database or another domain controller or AD LDS server. The ntdsutil snapshot operation simply provides a convenient data input for Dsamain.exe.
  • Dsamain.exe, which you can use to expose the snapshot data as an LDAP server
  • Existing LDAP tools, such as Ldp.exe and Active Directory Users and Computers
By default, only members of the Domain Admins group and the Enterprise Admins group are allowed to view the snapshots because they contain sensitive AD DS data. If you want to access snapshot data from an old domain or forest that has been deleted, you can allow nonadministrators to access the data when you run Dsamain.exe.
All permissions that apply to the data in the snapshot are enforced when you view the data. For example, suppose that members of the Domain Admins groups are explicitly denied Read permission for an object in AD DS. If you supply credentials for a member of that group when you try to view the snapshot data for that object, access is denied.
Moreover, you cannot change the existing permission to grant Read access in the snapshot that you are viewing because the Active Directory data is read-only. Any add, modify, or delete operations will fail.
However, a malicious user might be able to copy sensitive data that might be stored in AD DS snapshots to another forest and then use privileged credentials from that forest to examine the data. Therefore, you should protect them in a manner that is similar to how you protect domain controller backups. Use encryption or other data security precautions with AD DS snapshots to help mitigate the chance of unauthorized access to them.

Steps for using the Active Directory database mounting tool

You are not required to use the ntdsutil snapshotoperation to create the snapshots. You can use any backup of an AD DS or AD LDS database that uses VSS, including non-Microsoft backup solutions. The database must be in a consistent state; that is, the logs must be replayed. If you use Ntdsutil.exe or Windows Server Backup on a server running Windows Server 2008, the resulting snapshot or backup will be consistent.
noteNote
A domain controller backup contains more data than an AD DS snapshot because it also includes files that are needed to restore the operating system.

You can use either Ntdsutil.exe to mount the snapshot or use Windows Server Backup to restore the backup to an alternative location or to another computer. Then, you can use a tool such as Ldp.exe to view the data.
You can use the following process to use the Active Directory database mounting tool:
  1. Although it is not a requirement, you can schedule a task that regularly runs Ntdsutil.exe to take snapshots of the volume that contains the AD DS or AD LDS database.
  2. Run Ntdsutil.exe to list the snapshots that are available and then mount the snapshot that you want to view.
  3. Run Dsamain.exe to expose the snapshot volume as an LDAP server.

    Dsamain.exe takes the following arguments:

    • AD DS or AD LDS database (Ntds.dit) full file path. By default this file is opened as read-only. Only ASCII paths are supported. Network share paths are not supported.
    • Log path. This can be a temporary path, but you must have write access. This parameter is optional. If you do not specify the log path, logs and a temporary database are created in the Temp folder.
    • Four port numbers for LDAP, LDAP-SSL, Global Catalog, and Global Catalog–SSL. Only the LDAP port is required. If the other ports are not specified, they will use LDAP+1, LDAP+2, and LDAP+3, respectively. For example, if you specify LDAP port 41389 without specifying other port values, the LDAP-SSL port will use port 41390 by default, and so on.
    You can stop Dsamain by pressing CTRL+C in the Command Prompt window or, if you are running the command remotely, by setting the stopservice attribute on the rootDSE object.
  4. Run and attach Ldp.exe to the snapshot’s LDAP port that you specified when you exposed the snapshot as an LDAP server in the previous step.

    You can also try using the Active Directory Users and Computers snap-in that is installed by default on a Windows Server 2008 domain controller, as described in the procedure later in this guide.
  5. Browse the snapshot just as you would with any live domain controller.
If you specify different ports for each snapshot when you run Dsamain.exe, you can browse multiple snapshot instances on the same domain controller (or on the same workstation if you are browsing a restored backup) at the same time and easily compare their data.
If you have some idea which organizational unit (OU) or objects were deleted, you can look up the deleted objects in the snapshots and record the attributes and back-links that belonged to the deleted objects. You can reanimate these objects by using the tombstone reanimation feature on a domain controller in your production environment. Then, you must manually repopulate these objects with the stripped attributes and back-links as identified in the snapshots. For more information about tombstone reanimation, see Reanimating Active Directory Tombstone Objects (http://go.microsoft.com/fwlink/?LinkID=116204).
Although you must manually re-create the stripped attributes and back links, the Active Directory database mounting tool makes it possible for you to re-create deleted objects and their back-links without rebooting the domain controller into Directory Services Restore Mode. You can also use the tool to look up previous configurations of AD DS as well, including permissions that were in effect.

Step 1: Create, mount, and list snapshots

To create a snapshot, you must be a member of the Enterprise Admins groups or the Domain Admins group or you must have been delegated the appropriate permissions. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To create an AD DS or AD LDS snapshot

  1. Log on to a domain controller as a member of the Enterprise Admins groups or the Domain Admins group.
  2. Click Start, right-click Command Prompt, and then click Run as administrator.
  3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  4. At the elevated command prompt, type the following command, and then press ENTER:
    ntdsutil
  5. At the ntdsutil prompt, type the following command, and then press ENTER:
    snapshot
  6. At the snapshot prompt, type the following command, and then press ENTER:
    activate instance ntds
  7. At the snapshot prompt, type the following command, and then press ENTER:
    create
    The command returns the following output:
    Snapshot set {GUID} generated successfully.
    
    Where GUID is the globally unique identifier (GUID) for the snapshot.
  8. At the snapshot prompt, type the following command, and then press ENTER:
    mount { GUID }
  9. As an option, to see a list of all mounted snapshots, you can type the following command, and then press ENTER:
    list mounted
    The output lists each mounted snapshot and a corresponding index number. You can use the index number instead of the GUID to subsequently mount, unmount, or delete the snapshot.
  10. To unmount the snapshot after you have finished viewing the data, type either of the following commands, and then press ENTER:
    unmount index #
    -or-
    unmount { GUID }
  11. Delete old snapshots that you are no longer using because they consume disk space. To delete a snapshot, type either of the following commands, and then press ENTER:
    delete index #
    -or-
    delete { GUID }
  12. After you are done with snapshot operations, type quit to return to the ntdsutil menu, and then type quit again to return to the command prompt.
After you create and mount a snapshot, you can run Dsamain.exe to expose the AD DS or AD LDS data in the snapshot as an LDAP server.

Step 2 (Optional): Schedule a task that creates AD DS snapshots

You have the option to schedule a task that runs Ntdsutil.exe regularly to create snapshots.
To schedule a task to create AD DS or AD LDS snapshots, you must be a member of the Enterprise Admins group or the Domain Admins group. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To schedule a task to create AD DS or AD LDS snapshots

  1. Log on to a domain controller as a member of the Enterprise Admins group or the Domain Admins group.
  2. Click Start, click Administrative Tools, and then click Task Scheduler.
  3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  4. Click Action, and then click Create task.
  5. On the General tab, type a name for your task, and then select the appropriate security options to run the task.
  6. On the Triggers tab, click New.
  7. In New Trigger, select the appropriate settings for the task, and then click OK.
  8. On the Action tab, click New.
  9. In New Action, type the name or browse to the file path that contains Ntdsutil.exe and in Add arguments (optional), type the following command, and then press ENTER:
    ntdsutil "activate instance ntds" snapshot create quit quit
  10. On the Conditions tab and the Settings tab, select any additional settings that you want to apply to the task, and then click OK.
  11. If you are prompted, enter the password for a member of the Enterprise Admins group or the Domain Admins group, and then click OK.

Step 3: Expose an AD DS or AD LDS snapshot as an LDAP server

By default, you must be a member of the Enterprise Admins groups or the Domain Admins group to run Dsamain.exe and to access the Active Directory data that it exposes. If the snapshot is taken from a domain that no longer exits, you can specify the /allowNonAdminAccess parameter. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To expose an AD DS or AD LDS snapshot as an LDAP server

  1. Log on to a domain controller as a member Enterprise Admins groups or the Domain Admins group.
  2. Click Start, right-click Command Prompt, and then click Run as administrator.
  3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  4. At the elevated command prompt, type the following command, and then press ENTER. Be sure to include a space between the name of the parameter and the value that you specify.
    dsamain /dbpath /ldapport
    If you plan to view the snapshot data on a domain controller, specify ports that are different from the ports that the domain controller will use. For example, type:
    dsamain /dbpath E:\$SNAP_200704181137_VOLUMED$\WINDOWS\NTDS\ntds.dit /ldapport 51389
    A message indicates that Active Directory Domain Services startup is complete.
Allow Dsamain.exe to continue running in the command prompt window while you use an LDAP tool such as Ldp.exe or Active Directory Users and Computers to view the AD DS or AD LDS data in the snapshot.

Step 4: Access Active Directory data that is stored in snapshots

To use Ldp.exe or Active Directory Users and Computers to access the AD DS or AD LDS data, you must be a member of the Enterprise Admins groups or the Domain Admins group or you must have been delegated permission. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

To use Ldp.exe to access AD DS or AD LDS data that is stored in snapshots

  1. Click Start, click Run, type ldp, and then click OK.
  2. Click Connection, and then click Connect.
  3. In Server, type the name of the server, or type localhost and, in Port, type a port number that you specified previously with dsamain. For example, type 51389. Click OK.
  4. Click Connection, and then click Bind.
  5. In Bind type, click Bind as currently logged on user or click Bind with credentials and type a name, password, and domain for a user account that has permission to access the Active Directory data. Click OK.
  6. Click View, and then click Tree.
  7. In BaseDN, type the distinguished name of the parent container for the data that you want to view, and then click OK. For example, to view all objects in the Contoso domain, type:
    dc=contoso,dc=com
  8. Double-click the appropriate containers for the object that you want to view, and then double-click that object to view its properties.

To use Active Directory Users and Computers to access Active Directory data that is stored in snapshots

  1. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. In the console tree, right-click Active Directory Users and Computers [FQDN], and then click Change Domain Controller.
  4. Click , type the following, and then press ENTER:
    hostname:port
    where hostname is the name of the server where the snapshots are stored and port is the LDAP port number that you specified previously with dsamain. For example, type the following, and then click OK:
    DC1:51389
  5. Double-click the appropriate containers for the object that you want to view, and then double-click that object to view its properties.