Active Directory Domain Services Recovery in Win Server 2008 R2

Active Directory constitutes one of the primary infrastructure components of the majority of Windows-based business environments. Effectively, its resiliency and recoverability are inherently linked to operational continuity and any issues affecting its availability translate into monetary losses. Since the introduction of this technology (coinciding with the release of Windows 2000 Server platform), Microsoft has been continually improving its native restore capabilities.

In this article, we will present options that are included in Windows Server 2008 R2.

First, some context: Active Directory is implemented as a distributed database hosted on one or more domain controllers. Its content consists of objects and their attributes (as well as metadata defining characteristics of each of them) grouped into partitions, which collectively represent an entity called a forest. Taking into account this hierarchical structure, it is possible to approach the subject of recovery from the point of view of its scope. More specifically, we can identify the following scenarios that qualify as Active Directory recovery:

Restoring an object (or more specifically, attributes of which that object is comprised)

Restoring a single container (containing multiple objects and, potentially, other containers)

Restoring a domain (which can apply to a single- or multi-domain forest)

Restoring a multi-domain forest

Prior to Windows Server 2008 R2, you had, in essence, two options when recovering deleted objects. The first, by far more common, involved authoritatively restoring them from backup. The procedure required rebooting one of domain controllers in Directory Services Restore Mode (assuming that you had multiple domain controllers in the same domain — otherwise, any restore is automatically considered authoritative), restoring its System State backup taken prior to the deletion, and using ntdsutil.exe command-line utility to mark the newly restored object as authoritative (ensuring that they would replicate outbound to all other domain controllers in the same domain).

Unfortunately, it is typically also necessary to account for the fact that a restored object might include back-link attributes (most commonly, memberOf attribute of a user object, which represents its group membership) that are counterparts of forward-link attributes. In this case, it would be taking the form of the member attribute of a group. Since only the latter is replicated, while the former is simply evaluated locally on each domain controller, restoring a single object will re-establish forward links corresponding to its back-links only on the domain controller where the restore is carried out, without replicating them out. This holds as long as group objects included in the System State restore are not marked as authoritative. Thus, the forward attributes might be either retained or overwritten, depending on whether group membership changes took place since the backup was taken. The problem is even more severe in pre-Windows Server 2003 domains, where the member attribute does not take advantage of the Linked Value Replication (LVR) but instead it is implemented as single-valued rather than multi-valued.

To remediate this issue, once you authoritatively restore a user object, you must also authoritatively restore relevant forward links (representing membership of that user in Active Directory groups). Fortunately, starting with Windows Server 2003 Service Pack 1, ntdsutil.exe automatically recovers group membership in the local domain (including universal groups if the restore is performed on a global catalog) as part of the authoritative restore process. It also generates a pair of supplemental files to assist with any auxiliary changes. The first of them (in the .ldf format) must be imported (via the Ldifde command-line utility) manually on the recovery domain controller if the restored user was a member of pre-LVR groups. The second one, implemented as a text file, comes into play if the user was a member of domain local or universal groups in other domains in the same forest. If so, you must convert it to ldf format on a domain controller in each of these domains by following procedure described in the Active Directory Operations Guide, and subsequently import the resulting file using Ldifde utility.

The other of legacy options that facilitate recovery of Active Directory objects takes advantage of the fact that their deletion does not take effect immediately. Instead, objects are marked for deletion (tombstoned) by setting their isDeleted attribute to TRUE, moved to CN=Deleted Objects container in their partition (with exception of server objects), stripped of most of their attributes (by default, only mandatory ones are preserved), and retained for the period dictated by the value of tombstoneLifetime attribute residing in the CN=Directory Service,CN=Windows NT,CN=Services container of the configuration partition of the forest. This also determines the useful shelf life of a System State backup of Active Directory domain controllers. As a result, it is possible to retrieve these objects by following the procedure described in the Technet article Reanimating Active Directory Tombstone Objects. Unfortunately, the outcome is typically less than satisfactory since the recovered object is missing most of its attributes, including its group membership.

Starting with Windows Server 2008, this particular drawback of the tombstone reanimation procedure can be relatively easily remediated by taking advantage of the Active Directory snapshots. In addition, that operating system brings modifications in the way native backup is implemented. System State backup option is no longer available via a graphical interface but requires use of the wbadmin command-line utility with start systemstatebackup switch. Similarly, it is restored by executing wbadmin start systemstaterecovery. As in the past, to perform an authoritative restore, you must carry out this procedure after restarting the domain controller in Directory Services Restore Mode.

Restoring Deleted Objects in Windows Server 2008 R2

Truly revolutionary changes in regard to restoring deleted objects are introduced in Windows Server 2008 R2 thanks to the feature known as Active Directory Recycle Bin. This new functionality eliminates the most significant disadvantages associated with traditional recovery procedures described above — namely, the need to restart a domain controller in Directory Services Restore Mode during authoritative restores and dealing with missing attributes following tombstone reanimation. However, to take advantage of its benefits, you must first raise the forest functional level of Windows Server 2008 R2 such that all domain controllers in the forest must be running Windows Server 2008 R2 operating system and then enable it. In addition, while it is possible to roll back the first step of this process because unlike in earlier version of Windows, you are allowed to lower the functional level to Windows Server 2008, the second one invalidates this option. This makes the change irreversible.

Enabling Active Directory Recycle Bin alters the implementation of object deletion process. Rather than following the traditional mechanism that resulted in stripping non-mandatory attributes, objects moved to CN=Deleted Objects container retain all of them for the duration of the deleted object lifetime. Once that period passes, these objects become recycled (it is also possible to initiate this action manually), which roughly corresponds to the pre-AD Recycle Bin deleted status. However, unlike in pre-Windows Server 2008 R2 implementations, such objects cannot be recovered through tombstone reanimation, and they should not be authoritatively restored. They remain in this state until the recycled object lifetime expires. At that point, the garbage collection process removes them from Active Directory database. Extending the retention period and preserving all attributes while at the deleted stage is bound to contribute to its increased size. The duration of these two consecutive periods is controlled by Active Directory attributes msDS-deletedObjectLifetime and tombstoneLifetime. Both reside in the CN=Directory Service,CN=Windows NT,CN=Services container of the Configuration partition. If the first one is not explicitly configured, it takes on the value assigned to tombstoneLifetime, which defaults to 180 days. The smaller of the two determines the useful shelf life of a System State backup of Active Directory domain controllers.

It is important to realize that enabling Active Directory Recycle Bin changes the state of all of its tombstoned objects to recycled. It also introduces a learning curve, since there are no native GUI-based utilities dedicated to managing deleted objects. However, it is possible to recover deleted objects using ldp.exe. There are also several third-party tools that fill that void, such as PowerGUI-based Active Directory Recycle Bin PowerPack or ADRecycleBin from Overall Solutions.

Instead, Microsoft developed a number of PowerShell cmdlets that provide relevant functionality. For details regarding their syntax, refer to the Technet-based Active Directory Recycle Bin Step-by-Step Guide. The majority of administrative tasks (such as deleting objects, viewing deleted objects, viewing deactivated links, viewing tombstones, recovering deleted objects or recycling deleted objects) can be delegated. In addition, you should not treat the AD Recycle Bin as a substitute for valid backups of your domain controllers.

Recovery of deleted Active Directory containers that host objects and child containers can be performed using authoritative restore (as described in Active Directory Operations Guide) or by taking advantage of Recycle Bin capabilities (assuming, of course, this features has been enabled). In case of the latter, keep in mind that the restore process should be carried out starting from the top of the deleted hierarchy. An example documenting this approach can be found in Restoring multiple, deleted Active Directory objects section of Active Directory Recycle Bin Step-by-Step Guide.

Active Directory domain and forest recovery are considerably more complex topics since they typically extend beyond the scope of Directory Services. While Microsoft offers some assistance in this area (e.g., the Planning for Active Directory Forest Recovery guide published in the TechNet Library), you should consider creating your own detailed disaster recovery documentation that takes into account all relevant infrastructure dependencies specific to your environment. In addition, keep in mind that some components viewed as inherently tied to Active Directory (e.g., Group Policies or Sysvol shares hosted on domain controllers) warrant their own backup and restore strategy since they are not recoverable via the methods described above.

Active Directory Domain Services Recovery in Win Server 2008 R2

Active Directory constitutes one of the primary infrastructure components of the majority of Windows-based business environments. Effectively, its resiliency and recoverability are inherently linked to operational continuity and any issues affecting its availability translate into monetary losses. Since the introduction of this technology (coinciding with the release of Windows 2000 Server platform), Microsoft has been continually improving its native restore capabilities.

In this article, we will present options that are included in Windows Server 2008 R2.

First, some context: Active Directory is implemented as a distributed database hosted on one or more domain controllers. Its content consists of objects and their attributes (as well as metadata defining characteristics of each of them) grouped into partitions, which collectively represent an entity called a forest. Taking into account this hierarchical structure, it is possible to approach the subject of recovery from the point of view of its scope. More specifically, we can identify the following scenarios that qualify as Active Directory recovery:

• Restoring an object (or more specifically, attributes of which that object is comprised)
• Restoring a single container (containing multiple objects and, potentially, other containers)
• Restoring a domain (which can apply to a single- or multi-domain forest)
• Restoring a multi-domain forest

Prior to Windows Server 2008 R2, you had, in essence, two options when recovering deleted objects. The first, by far more common, involved authoritatively restoring them from backup (as described in the  article ). The procedure required rebooting one of domain controllers in Directory Services Restore Mode (assuming that you had multiple domain controllers in the same domain — otherwise, any restore is automatically considered authoritative), restoring its System State backup taken prior to the deletion, and using ntdsutil.exe command-line utility to mark the newly restored object as authoritative (ensuring that they would replicate outbound to all other domain controllers in the same domain).

Unfortunately, it is typically also necessary to account for the fact that a restored object might include back-link attributes (most commonly, memberOf attribute of a user object, which represents its group membership) that are counterparts of forward-link attributes. In this case, it would be taking the form of the member attribute of a group. Since only the latter is replicated, while the former is simply evaluated locally on each domain controller, restoring a single object will re-establish forward links corresponding to its back-links only on the domain controller where the restore is carried out, without replicating them out. This holds as long as group objects included in the System State restore are not marked as authoritative. Thus, the forward attributes might be either retained or overwritten, depending on whether group membership changes took place since the backup was taken. The problem is even more severe in pre-Windows Server 2003 domains, where the member attribute does not take advantage of the Linked Value Replication (LVR) but instead it is implemented as single-valued rather than multi-valued.

To remediate this issue, once you authoritatively restore a user object, you must also authoritatively restore relevant forward links (representing membership of that user in Active Directory groups). Fortunately, starting with Windows Server 2003 Service Pack 1, ntdsutil.exe automatically recovers group membership in the local domain (including universal groups if the restore is performed on a global catalog) as part of the authoritative restore process. It also generates a pair of supplemental files to assist with any auxiliary changes. The first of them (in the .ldf format) must be imported (via the Ldifde command-line utility) manually on the recovery domain controller if the restored user was a member of pre-LVR groups. The second one, implemented as a text file, comes into play if the user was a member of domain local or universal groups in other domains in the same forest. If so, you must convert it to ldf format on a domain controller in each of these domains by following procedure described in the Active Directory Operations Guide, and subsequently import the resulting file using Ldifde utility.

The other of legacy options that facilitate recovery of Active Directory objects takes advantage of the fact that their deletion does not take effect immediately. Instead, objects are marked for deletion (tombstoned) by setting their isDeleted attribute to TRUE, moved to CN=Deleted Objects container in their partition (with exception of server objects), stripped of most of their attributes (by default, only mandatory ones are preserved), and retained for the period dictated by the value of tombstoneLifetime attribute residing in the CN=Directory Service,CN=Windows NT,CN=Services container of the configuration partition of the forest. This also determines the useful shelf life of a System State backup of Active Directory domain controllers. As a result, it is possible to retrieve these objects by following the procedure described in the Technet article Reanimating Active Directory Tombstone Objects. Unfortunately, the outcome is typically less than satisfactory since the recovered object is missing most of its attributes, including its group membership.

Starting with Windows Server 2008, this particular drawback of the tombstone reanimation procedure can be relatively easily remediated by taking advantage of the Active Directory snapshots. In addition, that operating system brings modifications in the way native backup is implemented. System State backup option is no longer available via a graphical interface but requires use of the wbadmin command-line utility with start systemstatebackup switch. Similarly, it is restored by executing wbadmin start systemstaterecovery. As in the past, to perform an authoritative restore, you must carry out this procedure after restarting the domain controller in Directory Services Restore Mode.

Restoring Deleted Objects in Windows Server 2008 R2

Truly revolutionary changes in regard to restoring deleted objects are introduced in Windows Server 2008 R2 thanks to the feature known as Active Directory Recycle Bin. This new functionality eliminates the most significant disadvantages associated with traditional recovery procedures described above — namely, the need to restart a domain controller in Directory Services Restore Mode during authoritative restores and dealing with missing attributes following tombstone reanimation. However, to take advantage of its benefits, you must first raise the forest functional level of Windows Server 2008 R2 such that all domain controllers in the forest must be running Windows Server 2008 R2 operating system and then enable it. In addition, while it is possible to roll back the first step of this process because unlike in earlier version of Windows, you are allowed to lower the functional level to Windows Server 2008, the second one invalidates this option. This makes the change irreversible.

Enabling Active Directory Recycle Bin alters the implementation of object deletion process. Rather than following the traditional mechanism that resulted in stripping
non-mandatory attributes, objects moved to CN=Deleted Objects container retain all of them for the duration of the deleted object lifetime. Once that period passes, these objects become recycled (it is also possible to initiate this action manually), which roughly corresponds to the pre-AD Recycle Bin deleted status. However, unlike in pre-Windows Server 2008 R2 implementations, such objects cannot be recovered through tombstone reanimation, and they should not be authoritatively restored. They remain in this state until the recycled object lifetime expires. At that point, the garbage collection process removes them from Active Directory database. Extending the retention period and preserving all attributes while at the deleted stage is bound to contribute to its increased size. The duration of these two consecutive periods is controlled by Active Directory attributes msDS-deletedObjectLifetime and tombstoneLifetime. Both reside in the CN=Directory Service,CN=Windows NT,CN=Services container of the Configuration partition. If the first one is not explicitly configured, it takes on the value assigned to tombstoneLifetime, which defaults to 180 days. The smaller of the two determines the useful shelf life of a System State backup of Active Directory domain controllers.

It is important to realize that enabling Active Directory Recycle Bin changes the state of all of its tombstoned objects to recycled. It also introduces a learning curve, since there are no native GUI-based utilities dedicated to managing deleted objects. However, it is possible to recover deleted objects using ldp.exe. There are also several third-party tools that fill that void, such as PowerGUI-based Active Directory Recycle Bin PowerPack or ADRecycleBin from Overall Solutions.

Instead, Microsoft developed a number of PowerShell cmdlets that provide relevant functionality. For details regarding their syntax, refer to the Technet-based Active Directory Recycle Bin Step-by-Step Guide. The majority of administrative tasks (such as deleting objects, viewing deleted objects, viewing deactivated links, viewing tombstones, recovering deleted objects or recycling deleted objects) can be delegated. In addition, you should not treat the AD Recycle Bin as a substitute for valid backups of your domain controllers.

Recovery of deleted Active Directory containers that host objects and child containers can be performed using authoritative restore (as described in Active Directory Operations Guide) or by taking advantage of Recycle Bin capabilities (assuming, of course, this features has been enabled). In case of the latter, keep in mind that the restore process should be carried out starting from the top of the deleted hierarchy. An example documenting this approach can be found in Restoring multiple, deleted Active Directory objects section of Active Directory Recycle Bin Step-by-Step Guide.

Active Directory domain and forest recovery are considerably more complex topics since they typically extend beyond the scope of Directory Services. While Microsoft offers some assistance in this area (e.g., the Planning for Active Directory Forest Recovery guide published in the TechNet Library), you should consider creating your own detailed disaster recovery documentation that takes into account all relevant infrastructure dependencies specific to your environment. In addition, keep in mind that some components viewed as inherently tied to Active Directory (e.g., Group Policies or Sysvol shares hosted on domain controllers) warrant their own backup and restore strategy since they are not recoverable via the methods described above.

Windows 2008 Server Role Servers Explained

A server on a network – standalone or member – can function in a number of roles. As the needs of your computing environment change, you may want to change the role of a server. By using the Server Manager and the Add Roles Wizard, you can install Active Directory Domain Servers to promote a member server to a domain controller, or you can install individual roles or combinations of various roles, such as DHCP, WINS, and DNS.

It is also relatively straightforward to demote a domain controller to a simple role server or remove any number of roles and features from a server.

Server Manager is the key configuration console you will use for installing server roles and features on your server. It can be configured to open automatically as soon as you log in to the
Windows console or desktop.

Types of roles

Let’s look at the various roles and features you can install on Windows Server 2008.

Active Directory Certificate Services (AD CS)
AD CS role services install on a number of operating systems, including Windows Server 2008, Windows Server 2003, and Windows 2000 Server. Naturally the fullest implementation of AD CS is only possible on Windows Server 2008. You can deploy AD CS as a single standalone certification authority (CA), or you can deploy multiple servers and configure them as root, policy, and certificate issuing authorities. You also have a variety of Online Responder configuration possibilities.

Active Directory Domain Services (AD DS)
This is the role in the Windows Server 2008 operating system that stores information about users, computers, and other resources on a network. AD DS is also used for directory-enabled applications such as Microsoft Exchange Server.

Active Directory Federation Services (AD FS)
AD FS employs technology that allows users over the life of a single online session to securely share digital identity and entitlement rights, or ‘”claims” across security and enterprise boundaries. This role – introduced and supported on all operating systems since Microsoft Windows Server 2003 R2 – provides Web Single Sign-On (SSO) services to allow a user to access
multiple, related Web applications.

Active Directory Lightweight Directory Services (AD LDS)
This service is ideal if you are required to support directory-enabled applications. AD LDS is a Lightweight Directory Access Protocol (LDAP) compliant directory service.

Active Directory Rights Management Services (AD RMS)
This service augments an organization’s security strategy by protecting information through persistent usage policies. The key to the service is that the right management policies are bound to the information no matter where it resides or to where it is moved. AD RMS is used to lock down documents, spreadsheets, e-mail, and so on from being infiltrated or ending up in the wrong hands. AD RMS, for example, prevents e-mails from being accidentally forwarded to the wrong people.

The Application Server role
This role supports the deployment and operation of custom business applications that are built with Microsoft .NET Framework. The Application Server role lets you choose services for applications that require COM+, Message Queuing, Web services, and Distributed Coordinated Transactions.

DHCP and DNS
These two roles install these two critical network service services required for every network. They support Active Directory integration and support IPv6. WINS is not classified as a key role for Windows Server 2008, and you install it as a feature, discussed later.

Fax Server role
The fax server lets you set up a service to send and receive faxes over your network. The role creates a fax server and installs the Fax Service Manager and the Fax service on the server.

File Server role
This role lets you set up all the bits, bells, and whistles that come with a Windows file server. This role also lets you install Share and Storage Management, the Distributed File System (DFS), the File Server Resource Manager application for managing file servers, Services for Network File System (NFS), Windows File Services, which include stuff like the File Replication Service (FRS), and so on.

Network Policy and Access Services
This provides the following network connectivity solutions: Network Access Protection (NAP), the client health policy creation, enforcement, and remediation technology; secure wireless and wired access (802.1X), wireless access points, remote access solutions, virtual private network (VPN) services, Radius, and more.

Print Management role
The print services provide a single interface that you use to manage multiple printers and print servers on your network.

Terminal Services role
This service provides technologies that enable users to access Windows-based programs that are installed on a terminal server. Users can execute applications remotely (they still run on the remote server) or they can access the full Windows desktop on the target server.

Universal Description, Discovery, and Integration (UDDI)
UDDI Services provide capabilities for sharing information about Web services. UDDI is used on the intranet, between entities participating on an extranet, or on the Internet.

Web Server role
This role provides IIS 7.0, the Web server, ASP.NET, and the Windows Communication Foundation (WCF).

Windows Deployment Services
These services are used for deployment of new computers in medium to large organizations.

Features

Server Manager also lets you install dozens of features on Windows Server 2008. These so-called features are actually programs or supporting layers that support or augment the functionality of one or more roles, or simply add to the functionality of the server. A good example of a feature is the clustering service. Now called Failover Clustering, this feature can be used to support mission-critical roles such as File Services, Printer Services, and DHCP Server, on server clusters. This provides for higher availability and performance.

Other features you will likely install include SMTP Server, Telnet Client and Server, Group Policy Management (for use with Active Directory), Remote Assistance, and more.

Windows User State Virtualization – Mixed Environments

Designing a User State Virtualization strategy for a mixed environment poses a number of different challenges. By mixed environment I’m referring to a client computing infrastructure that has:

• Different versions of Microsoft Windows such as Windows 7, Windows Vista and Windows XP on different computers
• Different architecture versions of the same version of Windows such as Windows 7 x86 and Windows 7 x64 on different computers
• Different versions of applications such as Office 2010, Office 2007 and Office 2003 on different computers
• Different architecture versions of the same application such as Office 2010 x86 and Office 2010 x64 on different computers

This article examines the issues that can arise when planning USV solutions for mixed environments and describes some best practices for designing and implementing such solutions.

Planning USV for Mixed Windows Versions

As described in the first article of this series, Windows Vista introduced a new “v.2” user profile that has a flattened folder structure that separates user data and settings better than the Windows XP user profile did. As a result of this change, older Windows XP user profiles are not compatible with the newer v.2 profiles of Windows Vista. This means that you can’t use Roaming User Profiles (RUP) as a solution for roaming between computers running Windows Vista and Windows XP. If you try to implement RUP in a mixed XP/Vista environment, users who roam between the two OS versions will end up with two separate profiles on the RUP server, one profile for XP computers and the other for Vista computers.

No changes were made to user profiles in Windows 7 and the user profile structure in Windows 7 is identical to that in Windows Vista. This means you can use RUP to enable users to roam between computers running Windows 7 and Windows Vista provided there are no other architecture or application-specific issues as described in the sections below. It also means that you can’t use RUP to roam between Windows 7 and Windows XP computers.

If users do need to roam between computers running Windows XP and computers running later versions of Windows, you can use Folder Redirection (FR) with Offline Files (OF) enabled to redirect Documents and other folders where users store work-related data. This allows user data to be accessible from computers running any version of Windows. You cannot roam user settings however, since user settings resides in both the AppDataRoaming folder and in the Ntuser.dat file (the HKCU registry hive) in the root of the user’s profile. Since RUP cannot be used in this scenario, and since AppDataRoaming should never be redirected unless you also use RUP, this means only user data can be roamed in this scenario, not user settings. Table 1 summarizes a USV strategy for mixed environments running different versions of Windows on different computers.

OS versions	RUP	FR with OF
XP and Win7	No	Yes (data folders only)
XP and Vista	No	Yes (data folders only)
Vista and Win7	Yes	Yes

Table 1: USV strategy for mixed environment having different Windows versions on different computers

If you plan on implementing FR in a mixed XP and Win7 (or mixed XP and Vista) environment and you need to redirect the Pictures, Music or Videos folder, you will need to select the Follow The Documents Folder option on the Target tab of the redirection policy for these folders (see Figure 1). Doing this will cause these folders to be redirected as subfolders of the Documents folders (as in XP) instead of as peers of the Documents folder (as in Vista and later) and causes these folders to inherit their redirection settings from the Documents folder instead of having this configured on the folders themselves. Don’t do this however unless you have users who still need to access their redirected data folders from computers running Windows XP since choosing this option alters the structure of the user’s profile. If users only need to access redirected data from computers running Windows Vista or later then don’t select Follow The Documents Folder when redirecting the Pictures, Music or Videos folders. And in any case, you shouldn’t redirect these particular folders at all unless there is a business need for these folders to be redirected (such as centrally backing up internally developed training videos or in-house developed graphics).

Figure 1: Configuring redirection on Pictures to follow Documents

Alternatively, instead of selecting Follow The Documents Folder individually for the Pictures, Music and Videos folders, you can simply select Also Apply Redirection Policy To Windows 2000, Windows 2000 Server, Windows XP and Windows Server 2003 Operating Systems on the Settings tab as shown in Figure 2 as this has the effect of automatically configuring the Pictures, Music and Videos folders to Follow The Documents Folder.

Figure 2: Enabling this setting causes Pictures, Music and Videos to follow Documents.

Planning USV for Mixed Windows Architectures

Beginning with Windows Vista two hardware architectures have been available for Windows platforms: x86 (32-bit) and x64 (64-bit). An x64 version of Windows XP was also released but was never widely deployed, largely due to lack of device driver support, so we won’t be considering Windows XP x64 in this discussion.

While the underlying user profile folder structure of Windows 7 x86 (or Windows Vista x86) and Windows 7 x64 (or Windows Vista x64) are identical, there are differences in how the Windows registry is structured on x86 and x64 versions of Windows. Specifically, the registry on x64 Windows also contains the x86 registry structure, but the reverse isn’t true—the registry on x86 Windows does not contain any x64 registry structure. Another issue is that the location of some programs are stored in the registry using static paths such as C:Program Files or C:Program Files (x86), and this means when you try roaming between 32-bit and 64-bit machines these registry items will typically cause problems. The result of these differences is that you can’t use RUP to roam users between computers running Windows 7 x86 (or Windows Vista x86) and computers running Windows 7 x64 (or Windows Vista x64).

However, if users do need to roam between computers running x86 and x64 versions of Windows, you can use FR with OF to redirect Documents and other data folders to allow work-related data to be accessible to users from computers running both x86 and x64 versions of Windows. You cannot roam user settings however since user settings in HKCU on a computer running an x64 version of Windows are not compatible with user settings in HKCU on a computer running an x86 version of Windows. Table 2 summarizes a USV strategy for mixed environments running x86 versions of Windows one some computers and x64 versions of Windows on others.

OS architectures	RUP	FR with OF
Win7 x86 and Win7 x64	No	Yes (data folders only)
Vista x86 and Vista x64	No	Yes (data folders only)

Table 2: USV strategy for mixed environment having both x86 and x64 versions of Windows on different computers

Planning USV for Mixed Application Versions/Architectures

Issues involving applications in roaming environment are similar to those involving Windows versions. For example, say you have Windows Vista on some computers and Windows 7 on others. You also have version N of an application installed on the Vista machines, but have the newer version N+1 of the same app installed on the Windows 7 machines. If you implement RUP and/or FR/OF in such an environment, can you expect users to experience any problems when they work with this application?

Probably. It’s likely that the new version of the app has more features than the old one, and new features will undoubtedly mean new per-user registry settings and possibly new user settings stored as files under the AppDataRoaming folder. What happens when registry settings or AppDataRoaming files used by the new version of the app are loaded by the old version of the app? Who knows! The only way you can be sure if this scenario will work is to test, test and test before you deploy your USV solution in your production environment. Otherwise, users may find that certain apps they use crash or hang unexpectedly, or behave in strange and unpredictable ways. Such a scenario could even cause users lose data or cause data to be corrupted. It’s best to play it safe and make sure that, regardless of which version of Windows is running on each computer, the same version of each app is installed. Be kind to your helpdesk personnel and don’t let them be inundated with complaints from angry users.

This is even more true with different architecture versions (x86 or x64) of applications. For example, say you have the x64 version of a particular application installed on Windows 7 x64 computers and the x86 version of the same application installed on Windows Vista x64 computers. The OS architectures are both x64 which supports a RUP scenario, but it’s likely that the x86 and x64 versions of the application store their settings in different parts of HKCU and maybe even different folders and files in the AppDataRoaming folder. This means the same kind of frustrating, unpredictable behavior may occur if users try to work on the same data file from one computer running the x86 version of the app and then later on a second computer running the x64 version of the app. Even worse, the data file being worked on might become corrupted. I’m not saying this will happen for sure, and the only way to know for sure is to test, test and test again. But it’s better to play it safe and simply standardize all your computers on either the x86 or x64 version of the app. This may not be a big issue today since 64-bit apps like the 64-bit version of Office 2010 are just now appearing, but in the future it’s likely to be a concern as more and more software vendors start releasing 64-bit versions of apps that had until now only been available in 32-bit form. Table 3 summarizes a USV strategy for mixed environments running different versions/architectures of applications on different computers.

App versions/architectures	RUP	FR with OF
Multiple different versions of the same app	Play it safe—don’t use RUP	Yes (data folders only)
Both x86 and x64 versions of the same app	Play it safe—don’t use RUP	Yes (data folders only)

Table 3: USV strategy for mixed environment having different application versions/architectures on different computers

If there is a clear business need to provide users with multiple versions of applications or even different architecture versions of applications, you should consider implementing one of the following application virtualization solutions from Microsoft (choose the one that meets your need in terms of functionality and manageability):

• Microsoft Application Virtualization which is part of MDOP
• Microsoft Enterprise Desktop Virtualization (MED-V) which is also part of MDOP.
• RemoteApp delivered using Remote Desktop Services
• Windows XP Mode using Windows Virtual PC on Windows 7
• For more information on Microsoft virtualization technologies like these, download my free ebook Understanding Understanding Microsoft Virtualization Solutions: From the Desktop to the Datacenter, Second Edition.

Conclusion

The bottom line in mixed environments (different versions/architectures of Windows/applications) is to keep things simple and play it safe. Your USV strategy should be to virtualize only user data folders like Documents (and possibly also Desktop, Pictures, etc.) and you should use FR together with OF to make user data available to users from any computer they log on to. Do not try to virtualize user settings using RUP or by redirecting the AppDataRoaming folder. If possible, try and standardize on a single version/architecture of each of your applications.

Win Server 2008 Directory Services, SYSVOL DFS Replication

The term Active Directory is most commonly equated with the NTDS.DIT database and its characteristics; however, its functionality is affected in a profound manner by content of the SYSVOL folder, residing by default, directly under the Windows directory (although its placement is customizable) and providing file system storage required to implement a wide range of Group Policies.

Although both NTDS.DIT and SYSVOL get created as a direct result of domain controller promotion and their coherence is necessary to keep directory services fully operational, they are subject to different rules and processes. One of more prominent examples of this dissonance is the use of two distinct replication engines to synchronize their respective contents across distributed set of domain controllers. In particular, since the introduction of Active Directory with the release of Windows 2000 Server product line, SYSVOL relied on File Replication Service (FRS) to accomplish this goal (physically separate and conceptually different from NTDS.DIT replication). Although the same technology still remains available in Windows Server 2008 environment, once you switch to Windows Server 2008 domain functional level, you have an option to take advantage of considerably more robust, efficient, and scalable mechanism based on the Distributed File System Replication (DFS-R).

The purpose of this article is to describe its advantages over FRS and describe migration path between them.

In principle, both File Replication Service and Distributed File System-based replication rely on the NTFS constructs (such as Update Sequence Number journal and internal jet database) to keep track of changes to the file system. The latter (which was introduced in Windows Server 2003 R2) offers a number of significant benefits over its predecessor. More specifically, it minimizes network usage by employing block-level (rather than file-level) replication, which means that partial changes to large files do not trigger their full transfer, as well as the Remote Differential Compression (RDC) algorithm, which can also be adjusted to arbitrary threshold or disabled altogether in environments with sufficient network bandwidth. It also has self-healing capabilities, handling more gracefully journal wrap conditions and database corruption. The efficiency and reliability of DFS-R has been further improved in Windows Server 2008, bringing such features as support for RPC asynchronous pipes (boosting the volume of replication requests that can be serviced simultaneously and mitigating blocking behavior that might surface if one of the replication partners is slower or overloaded) and the ability to take advantage of unbuffered I/O, allowing for higher number of concurrent downloads. In addition, the new version of DFS-R is RODC (Read Only Domain Controller) aware, automatically rolling back any changes applied to local replica of SYSVOL (such functionality is missing from FRS maintained volumes, which increases chances for administrative error). Finally, for larger environments, it eliminates the recommended limit on 1200 domain controllers per domain, stipulated in the Windows Server 2003 Active Directory Branch Office Guide.

Another significant factor to note when contemplating DFS-R deployment concerns the method of transitioning from FRS. The process of migrating SYSVOL replication mechanism to DFS-R has been designed in the manner minimizing the impact on Active Directory availability as well as allowing for gradual, controlled, easy-to-track, and reversible (with the notable exception of the final stage) transition. From the administrative standpoint, the process is managed using a built-in DFS-R specific utility DFSRMig.exe (residing in the %SystemRoot%system32 folder), which triggers each individual migration step (by setting a global migration state, represented internally by a group of designated Active Directory objects and their attributes), automatically carried out across all domain controllers in the same domain. These steps are referred to (using DFS-R nomenclature) as transition states (total of 5), with each starting and ending in a clearly defined set of conditions labeled as stable states (total of 4). Each state gets associated with a unique integer value between 0 to 9, with the stable states occupying lower part of this range.

The 9 DFS-R States

• START (stable state 0) designates the initial point of the migration. At this stage, it is critical to make sure that both Active Directory and FRS-based SYSVOL replication function properly. To test the former, use the RepAdmin command line utility (with /showrepl /all or /replsum switches). To verify status of the latter, take advantage of such utilities as FRSDiag, Sonar, or Ultrasound, which is available from the Microsoft Download Center. Make sure that the DFS Replication service is running and configured with Automatic startup on each domain controller. Confirm that the domain operates on the Windows Server 2008 functional level (which implies that all domain controllers are running Windows Server 2008). Verify that all domain controllers function properly and are accessible, paying particular attention to the PDC Emulator (as a matter of fact, you might want to consider running the migration directly from its console). Avoid adding new domain controllers or introducing changes to SYSVOL for the duration of the migration. If you decide to install a Read Only Domain Controller after the domain reaches the PREPARED state, you will need to manually create its DFS-R specific Active Directory settings by executing DFSRMig /CreateGlobalObjects command.

Finally, make sure that every volume containing SYSVOL folder on each domain controller has a sufficient amount of disk space (at a minimum, it should be capable of holding its copy). Once you have confirmed that all prerequistes are satisfied, enter the PREPARING transitional state by executing DFSRMig /SetGlobalState 1 command while logged on with an account that is a member of the Domain Admin (or Enterprise Admin) group. Note that although it is possible to perform the migration by specifying the final value of 3, representing the ELIMINATED state, such approach is not recommended since it does not provide rollback capabilities).

PREPARING (transitional state 4) starts with creation of the DFS-R Global Settings object CN=DFSR-GlobalSettings (and its child objects) under the System container of the default naming context in Active Directory (the change takes place on the PDC Emulator and propagates afterwards via standard AD replication to other domain controllers). Its msDFSR-Flags attribute is used throughout the migration to serve as an indication of the current global status (its value is derived from the msDFSR-Flags attribute of the CN=dfsr-LocalSettings child object of each domain controller computer account (which also gets created when the PREPARING state starts and is updated throughout the migration to reflect status of individual domain controllers). Other settings (under CN=DFSR-GlobalSettings) are used to designate replication content and topology of SYSVOL_DFSR among all domain controllers. Note that PDC Emulator is also responsible for all necessary objects specific to all Read Only Domain Controllers residing in the same the domain (since such changes can not be applied directly to Active Directory database hosted on each RODC). DFS-R service also creates SYSVOL_DFSR folder on the same volume as the SYSVOL and duplicates the content (leveraging robocopy utility) of its domain subfolder (including permissions and junction points). This is intended to minimize time and bandwidth required to complete initial DFS-R based replication with other domain controllers (which takes place in the REDIRECTING state). The current state of migration gets registered using the Local State entry of REG_DWORD datatype under HKLMSystemCurrentControlSetServicesDFSRParametersSysVolsMigrating SysVols registry key. 

WAITING FOR INITIAL SYNC (transitional state 5) follows automatically the PREPARING state. It is designed to complete configuration of the SYSVOL_DFSR, including its synchronization with another writable domain controller and setup of the corresponding Jet database. Effectively, once this step successfully completes, there are two separate replication mechanisms, with the FRS handling the original SYSVOL and DFS-R synchronizing its SYSVOL_DFSR-based duplicate. During its execution, the value of Local State registry entry on each domain controller changes from 4 to 5. 

PREPARED (stable state 1) is characterized by existence of two independently replicated instances of SYSVOL, with FRS as the primary replication engine, handling the content available via the SYSVOL share and DFS-R managing its non-shared duplicate residing in the SYSVOL_DFSR folder. In order to confirm whether this stage has been reached (which coincides with the event id 8014 registered in the local DFS Replication Event Log), examine output of the DFSRMig /GetMigrationState command, which queries migration state information from all domain controllers and displays the outcome, identifying any that have not reached the migration state set on the PDC Emulator. Remember that such discrepancies should be remediated before you proceed further. Note also that it is possible to manually expedite migration process. This can be done by forcing AD replication (to propagate changes to the global msDFSR-Flags attribute) with repadmin utility (by leveraging its replicate or SyncAll switches). It is also possible to force DFS Replication service to discover the newly applied global migration settings by executing DFSRDiag PollAD with Member attribute pointing to the PDC Emulator. Once you confirm that the PREPARED state is consistent across the domain, you are ready to proceed to the next step by launching the DFSRMig /SetGlobalState 2 command.

REDIRECTING (transitional state 6) starts by synchronizing content of the SYSVOL and its DFS-R equivalent SYSVOL_DFSR on the PDC Emulator (which subsequently replicates to other domain controllers). This is done to account for any changes that might have taken place (typically introduced via Group Policy modifications) since the PREPARED state has been reached. Next, the SysvolReady entry under HKLMSystemCurrentControlSetServicesNetlogonParameters registry key is set to 0 (translating into boolean FALSE), which effectively prevents the SYSVOL from being shared. This action is followed by changing the value of SYSVOL share Path parameter to SYSVOL_DFSRsysvol. Finally, SysvolReady gets set back to 1 (corresponding to the boolean TRUE), which reinstates the SYSVOL share (but associated with the new file system location). In addition, the Active Directory Domain Services service is added to the list of dependencies of the DSF Replication service (along with the File Replication service). 

REDIRECTED (stable state 2) is somewhat similar to PREPARED, since both SYSVOL replication mechanisms are still active, with DFS-R handling replication of the SYSVOL_DFSR folder and FRS being responsible for SYSVOL. However, the SYSVOL share no longer points to the legacy location but instead provides access to the SYSVOL_DFSRsysvol folder. As the implication of this arrangement, any direct changes to the original SYSVOL folder should be avoided, since they will be lost once you perform remaining migration steps (note, however, that this concern does not apply to modifications applied via Group Policy Management Console, which properly points to the new shared location). As before, you can confirm the status of transition by reviewing output generated by the DFSRMig /GetMigrationState command (successful outcome is also be reflected by an event ID 8017 recorded in the DFS Replication event log on each of domain controllers and the value of Local State registry entry referenced by us earlier). For more in-depth troubleshooting, use DFSRMig_xxx.Log.gz files residing in the Debug subfolder under Windows folder (where xxx is sequentially assigned integer value). This verification is critical, since the next step is non-reversible (the only way to return your domain from the ELIMINATED to START state is the full domain restore). Once you are ready, execute the DFSRMig /SetGlobalState 3 command. 

ELIMINATING (transitional state 7) eliminates dependency of the Active Directory Domain Services service on the File Replication Service, stops it temporarily and removes all Active Directory-resident settings pertinent to its SYSVOL replication characteristics. These changes are relayed to other domain controllers via standard AD replication. It also deletes content of the SYSVOL folder. Once these changes are completed, the FRS service is restarted again to accommodate scenarios where other content is replicated using this mechanism. 

ELIMINATED (stable state 3) constitutes the final state of migration. As before, its status can be verified by running the DFSRMig /GetMigrationState command or checking the value of Local State registry entry on individual domain controllers (as well as the presence of the event 8019 in the DFS Replication event log). In addition, the SysVol registry entry (under HKLMSystemCurrentControlSetServicesNetlogonParameters key) should point out the SYSVOL_DFSR folder (and the value of SysvolReady entry in the same location should be set to 1).

 

UNDO REDIRECTING (transitional state 8) facilitates reverting from the REDIRECTED to PREPARED state. To invoke it, execute DFSRMig /SetGlobalState 1. As part of the transition, the SYSVOL_DFSR folder is first synchronized with its SYSVOL counterpart (leveraging robocopy utility) to account for any changes to its content that might have taken place while in REDIRECTED state (typically introduced via Group Policy modifications). This synchronization takes place on the PDC Emulator and is subsequently replicated via FRS-driven replication. 

UNDO PREPARING (transitional state 9) permits you to return to the START state from PREPARED state (with FRS mechanism handling SYSVOL replication and the SYSVOL_DFSR folder removed). To invoke it, use DFSRMig /SetGlobalState 0 command. Note that, similarly to the PREPARING transitional state, PDC Emulator will be responsible for deleting all DFS-R Active Directory objects specific to Read Only Domain Controllers.This concludes our overview of characteristics of DFS-R SYSVOL replication available in Windows Server 2008 functional level domains and an outline of the steps involved in transitioning to it from FRS mechanism employed in earlier implementations of Active Directory. Our next article will focus on new Group Policy features.

UNDO REDIRECTING (transitional state 8) facilitates reverting from the REDIRECTED to PREPARED state. To invoke it, execute DFSRMig /SetGlobalState 1. As part of the transition, the SYSVOL_DFSR folder is first synchronized with its SYSVOL counterpart (leveraging robocopy utility) to account for any changes to its content that might have taken place while in REDIRECTED state (typically introduced via Group Policy modifications). This synchronization takes place on the PDC Emulator and is subsequently replicated via FRS-driven replication. 

UNDO PREPARING (transitional state 9) permits you to return to the START state from PREPARED state (with FRS mechanism handling SYSVOL replication and the SYSVOL_DFSR folder removed). To invoke it, use DFSRMig /SetGlobalState 0 command. Note that, similarly to the PREPARING transitional state, PDC Emulator will be responsible for deleting all DFS-R Active Directory objects specific to Read Only Domain Controllers.This concludes our overview of characteristics of DFS-R SYSVOL replication available in Windows Server 2008 functional level domains and an outline of the steps involved in transitioning to it from FRS mechanism employed in earlier implementations of Active Directory. Our next article will focus on new Group Policy features.

How to migrate your existing Active Directory to Windows Server 2008

This is a brief How To guide (the first of many) on how to migrate your existing Active Directory to Windows Server 2008.

Please note that I cannot be held responsible for any issues that you encounter when following this guide, my upgrade was done in a lab environment on a single Domain Controller running Exchange 2003.

If you do follow this and do it on a live system please, please, please run a full back up of your domain controllers and verify that the backup was successful. Even though this is a straight forward upgrade if anything goes wrong during the upgrade, you could potentially be left with a domain that NO users can logon to.

Before you start upgrading

verify that your domain controllers meet these requirements:

• The hardware meets or exceeds the requirements for Windows Server 2008.
• All hardware and software is compatible with Windows Server 2008, including antivirus software and drivers.
• You have ample disk space to perform the install.
• The current domain functional level is Windows 2000 Native or Windows Server 2003. You cannot upgrade directly from Windows NT 4.0, Windows 2000 Mixed or Windows Server 2003 Interim domain functional levels.
• All Windows 2000 Server domain controllers have Service Pack 4 installed.

Test your domain

Active Directory domains are very resilient and can continue to function even when a there are various problems e. Even if your Active Directory seems to be working properly, you might have logon delays, replication failures or Group Policy settings that aren’t being applied. These conditions can cause problems during an upgrade, so it’s crucial to resolve them now.

These tools will help you identify and diagnose any problems:

• Dcdiag.exe. Run this tool to analyse your Active Directory for common problems; it’s included with Windows Server 2003 and Windows Server 2008.
• Repadmin.exe. Use Repadmin.exe to identify Active Directory replication problems; it’s included with Windows Server 2003 and Windows Server 2008.
• Gpotool.exe. Use this tool to verify that Group Policy is consistent among domain controllers, it’s included with the Windows Server 2003 Resource Kit tools, available at http://go.microsoft.com/fwlink/?linkid=27766.
• Event Viewer. Review the Directory Services log file for errors that might indicate problems.

Prepare Your Schema

If you upgraded from Windows 2000 to Windows Server 2003 you will be familiar with the Adprep.exe tool that was located on the Windows Server 2003 CD to prepare your Forest and Domain Schema. To prepare the Schema for Windows Server 2008 you will need to run the adprep tool from the Server 2008 DVD. This is located in the SoucesADprep Folder on the CD.

Run the following Command to prepare your domain for 2008:

Adprep /forestprep
Adprep /domainpre

Adprep /domainprep /gpprep

Adprep /rodcprep

If you get an error during the Adprep /domainprep about the domain not being in native mode you need to raise the level of your domain and then re-run domainprep. To raise the level of your domain go into Active Directory Domains and Trusts. Right click on the domain and select Raise Domain Function Level… 

Once you have finished running the Adprep on you domain controller, join your new Windows Server 2008 Server to your domain make sure that you have a static IP assigned to the server I am using IPv4 as to be honest know nothing about IPv6 just now, so when running dcpromo click yes to the prompt about the Static IP assignment.

Then once that has done you will have a functioning Windows Server 2008 Active Directory Server.

The ScreenCast video content presented here requires JavaScript to be enabled and the latest version of the Macromedia Flash Player. If you are you using a browser with JavaScript disabled please enable it now. Otherwise, please update your version of the free Flash Player by downloading here.

// < ![CDATA[
//

Directory Services Auditing – Win Server 2008

Computing environments have changed drastically in recent years, not only because of magnified focus on security but also as the result of range of compliance-driven initiatives affecting practically the entire IT landscape. In response to these new requirements, Microsoft has revised some of its earlier designs, improving effectiveness of auditing functionality built into the operating system. With the introduction of Windows Server 2008, these enhancements also influenced methodology that can be employed to track Active Directory related events. In this article, we will review its characteristics and provide details regarding its implementation.

While earlier versions of Active Directory domains (based on either Windows 2000 Server or Windows Server 2003) were able to capture changes affecting its objects (by employing Audit Policy incorporated into a Group Policy Object linked to the Domain Controllers organizational unit), its configuration was rather cumbersome to manage. In particular, GPO-based administration, with its limited range of settings (enable/disable of success/failure audit for 9 main event categories) left you with a dubious choice of one of two extremes — dealing with an overwhelming volume of events overwriting Security logs on a frequent basis or having no oversight at all. This could be somewhat mitigated by restricting the scope of monitoring to more sensitive accounts only, although such an approach hardly qualified as a solution to the problem. In addition, the description of some events was frequently considered to be inadequate. The most common complaint referred to the absence of before and after values in entries corresponding to successful changes of object attributes.

In 

Windows Server 2008-hosted domain controllers, some of these issues have been resolved. In particular, it became possible to narrow down the scope of auditing, at least to some extent, by taking advantage of event subcategories. Recorded information offers more visibility into the actual impact of a change, by including before and after values. Some caveats apply, such as string data type length limits or a provision that prevents inclusion of binary values, which are simply replaced with the <binary> label).

The new level of granularity still leaves room for improvement and management methodology lacks consistency; it is based on a combination of graphical and command line utilities. Note also that although the new features do not require elevated domain functional level, they are specific to Windows Server 2008, so you must upgrade all of your domain controllers if you want to be certain every change to Active Directory accounts gets audited in a consistent manner. Finally, keep in mind that for an audit event to be triggered, a target object must have its system access control list (SACL) properly configured, regardless of the version of the operating system.

With the new functionality in place, content of the Audit Policy subnode of the Default Domain Controller Group Policy Object on a Windows Server 2008 (under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies node within Group Policy Management Editor) might no longer give you an accurate representation of the actual configuration. To obtain it, you must resort to the AUDITPOL command line utility, which provides the equivalent information, but on per-subcategory level. To better understand its structure, execute AUDITPOL /GET /CATEGORY:*, which will display a full listing of categories along with all subcategories for each. Alternatively, if you are interested in a specific one, replace the * parameter with its name (enclose multi-word terms in double quotes), according to the following list:

• System – for the Audit system events GPO setting
• Logon/Logoff – for the Audit logon events GPO setting
• Object Access – for the Audit object access GPO setting
• Privilege Use – for the Audit privilege use GPO setting
• Detailed Tracking – for the Audit process tracking GPO setting
• Policy Change – for the Audit policy change GPO setting
• Account Management – for the Audit account management GPO setting
• Account Logon – for the Audit account logon events GPO setting
• DS Access – for the Audit directory service access GPO setting

The last one of these entries, which is of particular interest to us, is divided into Directory Service Changes, Directory Service Access, Directory Service Replication, and Detailed Directory Service Replication subcategories, with the first two being most relevant from the security perspective. In its default configuration, Windows Server 2008 domain controllers track only successful events of Directory Service Access type, which is consistent with the predefined Default Domain Controllers Policy settings in earlier versions of Active Directory. This arrangement allows you to capture an occurrence of each object change (via a corresponding access event), but without details about its impact or scope. Depending on the type of affected object, you might be able to track down more information by reviewing Security Log entries in the User Account Management category, since successful events in three of its subcategories (UserAccountManagement, ComputerAccountManagement, and SecurityGroupManagement) are, by default, also enabled.

Keep in mind, however, their content is limited to more common attributes and does not include their original value. To address these shortcomings, you must enable Directory Service Changes subcategory of DS Access category, which can be accomplished by executing on a monitored domain controller AUDITPOL /SET /SUBCATEGORY:"Directory Service Changes" /success:enable. This command must be executed from an interactive session on the target server. As the result, you will be able to keep track of the following actions (as long as appropriate SACLs have been applied to target objects):

• Creating a New Object: Resulting in multiple Event ID 5137 entries containing all attributes provided explicitly by the security principal that invoked the operation (but not those automatically generated by the system). Note that similar information also gets recorded if audit of User Account Management or Directory Service Access is enabled.
• Modifying an Existing Object: Resulting in two Event ID 5136 entries including affected values, pre- and post-modification for all modified attributes. A single entry is created if the original value was not set. As mentioned earlier, such information is not available via ether User Account Management or Directory Service Access logging.
• Moving an Existing Object: Resulting in a single Event ID 5139 entry containing its old and new location (in the distinguished name format), unless the target location is in a different domain, in which case, the operation is treated as creation of a new object (Event ID 5137).
• Undeleting an Object: Resulting in a single Event ID 5138 entry containing its old and new locations (since it involves moving it from the cn=deleted Objects hidden container in its domain partition), in addition to any attributes explicitly assigned during this process.
• Deleting an Object: Resulting in a single Event ID 5141 entry providing information about a user that invoked the deletion and identifying the object via its distinguished name. At the same time, a corresponding Directory Service Access event gets generated as well.

As mentioned earlier, in order for Directory Service Change and Directory Service Access events to be audited, you also must ensure that appropriate system access control list (SACL) entries are in place (in addition to enabling both types of audit subcategories). For domain objects, they are typically defined via a graphical interface of standard administrative utilities (DSACLS command line utility is capable only of restoring default SACL for an object based on its Schema definition), such as Active Directory Users and Computers (Auditing tab of Advanced Security Settings dialog box referencing a designated object).

Each of such entries associates an action (or more specifically, its successful or failed outcome), one or more security principals initiating it (designated typically via a domain security group), and its target. Providing that all of these parameters match the respective circumstances of an actual event, its occurrence is recorded in the Security Event log. For example, enabling an audit of a successful creation of all types of descendant objects by Everyone on an arbitrarily chosen OU will yield an audit trail enabling you to keep track of Directory Service Changes events with ID 5137 affecting its content. Similarly, tracking usage of Write all properties for the same subject and object pair will allow you to monitor Directory Service Changes events with ID 5136 (in both cases, these actions will be recorded via corresponding Directory Service Access and User Account Management Security Event log entries).

As you might imagine, without proper planning, just a sheer volume of logged events might become overwhelming and render your auditing difficult to manage. Even though you can eliminate the risk of overwriting logs due to reaching their size limit by taking advantage of Archive the log when full, do not overwrite events configuration setting, which automatically dumps content of the log once it becomes full (this requires a registry modification in earlier versions of Windows). You should instead consider narrowing down a scope of monitoring to absolute minimum. One way to accomplish this goal is to target only specific object types, security principals or actions (via SACLs). Alternatively, you can turn off individual audit subcategories (e.g.,, rely on Directory Service Change rather than Directory Service Access).

If you decide to use that approach, keep in mind that category-level changes configured via Audit Policy node of a Group Policy Object linked to Default Domain Controllers organizational unit are applied in the uniform manner to all of underlying subcategories, which might not be what you want to accomplish. To prevent this from happening, enable Audit: Force audit policy subcategory setting (Windows Vista or later) to override audit policy category settings option (under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options node of the applicable GPO within Group Policy Management Editor). In addition, once you begin to rely on subcategories to establish your audit policies, each domain controller will need to be individually configured (since AUDITPOL does not have remoting capabilities and its settings are not automatically replicated).

Another method that allows you to limit scope of generated events involves a schema modification. While, by default, auditing is enabled for all attributes, you have an option to exclude arbitrarily chosen ones from being a subject to the “Directory Service Change” policy. This requires setting the 9th bit of the SearchFlags property of a designated attribute to 1 (which corresponds to decimal value of 256 or 0x100 in hex notation — labeled as NEVER_AUDIT_VALUE in the ADSI Edit console).

Besides all features described above, you might also want to take advantage of improvements first made available in Vista as part of Windows Eventing 6.0 feature set. They include such functionality as event subscriptions (facilitating forwarding selected events to a designated host serving as an event collector) or integration with task scheduling (the ability to trigger an custom task based on occurrence of an event matching set of filter conditions, configurable from both Task Scheduler and Event Viewer interface), although you should consider their implementation with caution, due to potential performance and network load implications.

This concludes the discussion of auditing improvements in Windows Server 2008 Directory Services. The next article of our series will explore the role Distributed File System Replication plays in improving resiliency and performance of Active Directory domain infrastructure.

How to migrate your Active Directory Domain to Windows Server 2008

Windows Server 2008 includes a handful of important upgrades to your Active Directory domain infrastructure. The most useful are these:

• Read-Only Domain Controllers: RODCs are a new type of domain controller that doesn’t allow updates but does provide authentication and directory services. This reduces the risk of an Active Directory security compromise (especially for branch offices with poor physical security) because an attacker with access to an RODC would have a very difficult time using that access to update the Active Directory.
• Flexible Password Policies: You can assign different password policies to different sets of users within a single domain—finally! If you have created separate domains to work around this restriction in the past, get rid of those redundant domains after the upgrade.
• Auditing: Active Directory auditing is much more granular in Windows Server 2008, allowing you to closely track changes on just the objects you’re interested in (including recording both the old and new values). You can separately audit read accesses and replication.

You can take advantage of these improvements only by upgrading every domain controller in a domain to Windows Server 2008, and then upgrading the domain functional level. That sounds easy, but if you don’t plan it properly, you could be left with a broken Active Directory and thousands of angry users. Follow these tips to upgrade without fear.

1. Back up your domain controllers

While most upgrades go smoothly, there’s the possibility of creating an outage that could affect your entire domain — potentially preventing users from accessing network resources. The more customized your Active Directory schema and permissions, the more likely you are to have problems. Therefore, you should plan your upgrade during nonpeak hours and have a full backup (including System State) of at least two domain controllers in case you need to roll back to an earlier version.

2. Verify upgrade requirements

Before you can upgrade the domain functional level, all domain controllers in the domain must be running Windows Server 2008. This allows you to take advantage of the new features but prevents you from adding any domain controllers running earlier versions of Windows.

Before you start upgrading, verify that your domain controllers meet these requirements:

• The hardware exceeds the Windows Server 2008 requirements.
• All hardware and software is compatible with Windows Server 2008, including antivirus software and drivers.
• Sufficient disk space is free to perform the operating system and Active Directory upgrade. Specifically, verify that your free space is at least twice the size of your Active Directory database.
• The current domain functional level is Windows 2000 Native or Windows Server 2003. You cannot upgrade directly from Windows NT 4.0, Windows 2000 Mixed or Windows Server 2003 Interim domain functional levels.
• All Windows 2000 Server domain controllers have Service Pack 4 installed.

3. Test your domain

Active Directory domains are very resilient and can continue to function even when a variety of problems exist. Even if your Active Directory seems to be working, you might have logon delays, replication failures or Group Policy settings that aren’t being applied. These conditions can cause problems during an upgrade, so it’s important to resolve them now.

These tools will help you identify and diagnose any problems:

• Dcdiag.exe. Run this tool to analyze your Active Directory for common problems; it’s included with Windows Server 2003 and Windows Server 2008.
• Repadmin.exe. Use Repadmin.exe to identify Active Directory replication problems; it’s included with Windows Server 2003 and Windows Server 2008.
• Gpotool.exe. Use this tool to verify that Group Policy is consistent amongdomain controllers, it’s included with the Windows Server 2003 Resource Kit tools, available at http://go.microsoft.com/fwlink/?linkid=27766.
• Event Viewer. Review the Directory Services log file for errors that might indicate problems.

4. Prepare your schema

Just as when upgrading to a Windows Server 2003 functional level, you must use the Adprep.exe tool to prepare your forest and domain schema. Note that you must use the version of Adprep included on the Windows Server 2008 media in the sourcesadprep folder, even though you will need to run it from an existing Windows Server 2003 domain controller. Be sure to use 32-bit media when running Adprep from a 32-bit domain controller, and use 64-bit media for 64-bit domain controllers.

To prepare your Active Directory schema, follow these steps for each domain that you plan to upgrade:

1. Run Adprep/forestprep on your Schema Master with Enterprise Admins, Schema Admins and Domain Admins privileges. Wait for changes to replicate.
2. Run Adprep/domainprep/gpprep on the Infrastructure Master with Domain Admin privileges. On Windows Server 2003 domains, you’ll receive an error message caused by the unnecessary /gpprep parameter that you can ignore.
3. On Windows Server 2003 domains, run Adprep/rodcprep on the Domain Naming Master with Domain Admin privileges.

Note: As long as your domain and forest are at the Windows Server 2003 functional level and you’ve prepared the schema, you don’t need to upgrade your entire domain to install a Windows Server 2008 RODC.

5. Migrate your domains

Before you upgrade a domain, be sure that you don’t plan to add domain controllers running Windows 2000 Server or Windows Server 2003. While you can always upgrade the domain functional level, you can never downgrade it.

The easiest way to migrate your domain to the Windows Server 2008 functional level is to follow these steps:

1. Install a new Windows Server 2008 computer, and then run Dcpromo.exe. You can configure either a Full Server or a Server Core as a domain controller. On Full Servers, you also have the option of adding the Active Directory Domain Services role using Server Manager.
   Tip: You can use command-line parameters to run Dcpromo.exe unattended (with or without an answer file). For detailed information, run Dcpromo/?.
2. Wait for replication to occur.
3. Retire or upgrade all Windows 2000 Server and Windows Server 2003 computers. To upgrade a Windows 2000 Server, upgrade it to Windows Server 2003, and then upgrade it to Windows Server 2008.
4. Upgrade the domain functional level using the Active Directory Domains and Trusts tool. Right-click the domain, and then click Raise domain functional level.

Now, test any applications that depend on Active Directory, including user logons and Exchange Server. If you run into problems, restore your domain controllers from backups, and head back to the lab for more testing. If everything goes well, wait a couple of weeks for the environment to stabilize before you make any other major changes.

6. Upgrade your forest

There are no new features available if you upgrade your forest to the Windows Server 2008 functional level — it just causes any new domains that are added to the forest to be at the Windows Server 2008 domain functional level by default. Still, it’s a worthwhile step to save yourself the trouble of upgrading a new domain that you accidentally added at the wrong functional level.

Summary

Microsoft must have been listening to the complaints about Active Directory limitations because Windows Server 2008 allows multiple password policies within a domain, read-only domain controllers and auditing that’s actually useful. If you follow these steps, you’ll be finished with your upgrade in no time.