Maintaining Active Directory

This chapter is from the book 

Foundation Topics

Configuring Active Directory Snapshots

One of the most basic ways to create a backup of your Active Directory Domain Services directory is to use snapshots. If you’re familiar with other database technologies, the term snapshot is probably familiar to you as well. A snapshot is a read-only copy of the directory as it was at the point in time when the snapshot was created. Snapshots are useful to get a glimpse into the previous state of your directory without the more involved hassle of restoring from a backup.

Two different command-line tools are required for working with snapshots ntdsutil and dsamain. In the ntdsutil command you use the snapshots menu to create, manage, and mount a snapshot. Mounting a snapshot means attaching the binary data to the file system in the OS so that it can be viewed. With dsamain you run a small LDAP server connected to that mount point. Once it'sloaded in dsamain, you can view the information inside the directory snapshot with utilities like Active Directory Users and Computers.

NTDSUTIL Snapshot Menu

You can review all the options of the ntdsutil snapshot menu by starting ntdsutil, typing snapshot to navigate into the snapshot menu, and typing ? to bring up the options for that menu.

Some important ntdsutil snapshot options to be aware of include

• Create: Creates a new snapshot of the active directory at the current moment.

• Mount %s: Mounts a snapshot into the file system. The %s parameter is the index number of a snapshot, such as 2, which can be reviewed with the list command.

• List all: Lists all the snapshots in the system. Each snapshot typically takes up two lines and has its index number for mount, unmount, and delete commands listed on the last row.

Creating and Mounting a Snapshot

To create and mount the snapshot (see Figure 6-1):

• Step 1. Log on to a writeable domain controller.

• Step 2. Launch a command prompt.

• Step 3. Type ntdsutil and press Enter.

• Step 4. At the ntdsutil prompt type activate instance ntds and press Enter.

• Step 5. At the ntdsutil prompt type snapshot and press Enter.

• Step 6. At the snapshot menu prompt type create and press Enter.

• Step 7. A snapshot is created representing the current state of the directory. Type list all and press Enter to see a list of all snapshots that have been created.

• Step 8. At the snapshot prompt type mount 1 and press Enter.

• Step 9. At the snapshot prompt type quit and press Enter.

• Step 10. At the ntdsutil prompt type quit and press Enter.

The snapshot has been created and mounted onto the file system at the location indicated after Step 8. If you want to browse that snapshot you can do so with Windows Explorer. Take note that there is an ntds.dit file located in the snapshot in the /Windows/NTDS folder (see Figure 6-2).

At this point, the snapshot has been mounted, but its directory is not being hosted yet for viewing.

Hosting a Snapshot

Even though the snapshot is loaded in the file system, it cannot be accessed via typical directory browsing tools until it is being hosted. When you host a snapshot, a server (dsamain in this case) listens on a specified port for LDAP queries and responds to those queries similar to a regular directory.

The dsamain utility provides hosting for snapshots. Table 6-2 outlines the common parameters for dsamain.

Table 6-2 Common Parameters for dsamain

Parameter	Description
-dbpath <filepath>	Specifies the file path to the .dit database file to host
-ldapport <number>	Specifies an ldap port number to listen on
-logpath <path>	Specifies the path to write log output files to

To host the snapshot:

• Step 1. Log on to the same domain controller where the snapshot was created. (Or just continue to use the same command prompt window used to create and mount the snapshot.)

• Step 2. Launch a command prompt.

• Step 3. Type the following command. You need to replace the name of the volume with the name of your mounted volume (see Figure 6-3).

  dsamain -dbpath "C:\$SNAP_201611101730_VOLUMEC$\WindowsNTDS\ntds.dit" -ldapport 10000

  

  Figure 6-3 The dsamain Utility Actively Hosting on Port 10000

• Step 4. The directory is now hosted at the port indicated with the -ldapport switch. Leave this window open in the background to keep the dsamain server running.

• Step 5. Launch Active Directory Users and Computers (ADUC).

• Step 6. Right-click Active Directory Users and Computers on the left-hand navigation pane and select Change Domain Controller.

• Step 7. Select the This domain Controller or AD LDS instance option and then click in the list box below where it reads <Type a Directory Server name[:port] here>.

• Step 8. Type localhost:10000 and press Enter.

• Step 9. When the Status reads “Online,” the server is connected and recognized. Click OK.

ADUC is now connected to and browsing the read-only snapshot you created earlier. You can see the entire directory structure, although you will not be able to make any changes.

To stop the server and shut down everything:

• Step 1. Close ADUC.

• Step 2. Return to the command prompt where dsamain is running and press Ctrl+C on your keyboard. You are notified that the service was shut down successfully.

• Step 3. Type ntdsutil and press Enter.

• Step 4. Type snapshot and press Enter.

• Step 5. Type unmount 2 and press Enter.

Backing Up and Restoring Active Directory and SYSVOL

Snapshots are a great way to get a capture of the current state of the directory. They are useful when you know you’ll be performing some maintenance or otherwise effecting changes in the system and you want to have a previous known good version readily available for comparison. Snapshots are not a valid backup process or disaster recovery plan. There is no way to schedule or automate snapshots, and they can only be used to manually view and recover AD DS information.

Backing Up Active Directory

For a true backup process, you need to use the built-in Windows Server Backup utility supplied by Microsoft. This is the same utility used to back up any Windows Server, and you should already be familiar with it.

Using the Server Backup utility, AD DS will be automatically included in any full backups that are run with the service. Generally, you want to be running regularly scheduled full backups for your server. If you want to create a custom backup that is sure to include the AD DS directory, follow these steps:

• Step 1. Log on to a writeable domain controller.

• Step 2. From the Start Menu launch Server Manager.

• Step 3. Click Tools > Windows Server Backup.

• Step 4. Right-click Local Backup in the navigation pane on the left-hand side and select Backup Once.

• Step 5. Choose Different Options and click Next.

• Step 6. Choose Custom and click Next.

• Step 7. On the Select Items for Backup step, click Add Items.

• Step 8. Select System state, which includes all the components and services on which Active Directory is dependent. Notably this includes the SYSVOL (see Figure 6-4).

  

  Figure 6-4 The Windows Server Backup Utility Selecting the System State and C: Drive for Backup

• Step 9. Click OK.

  Step 10. Select Local drives if you have a separate drive from the one NTDS is installed on. If no drive is available select Remote shared folder. Click Next.

  Step 11. Specify the location to store the backup image and click Next.

  Step 12. Review the choices made and click Backup.

AD DS has now been successfully backed up.

Restoring Active Directory

Once you have AD DS backed up you can plan to restore the directory in case the need arises. There are two approaches to restoring a domain controller. The first, and simpler of the two, is restoration through reinstallation and replication. With this method you are replacing or reinstalling Windows Server completely. Promoting that clean install to a domain controller causes it to replicate the current directory from another domain controller in the domain.

You can also restore Active Directory by restoring the System State data from backup media created with the Windows Server Backup tool. There are two methods for this restoration process:

• Nonauthoritative: A nonauthoritative restore means that after the domain controller is restored from backup media, it relies upon normal replication to bring its directory current with the rest of the domain. A nonauthoritative restore is typically used when a server fails in some capacity and must be restored from backup.

• Authoritative: With an authoritative restore the domain controller being restored immediately becomes authoritative and replicates its current state to the other domain controllers on the domain. Even if the restored data is older than the current replicas, the restored data takes precedence. An authoritative restore is used when you want to bring the directory back to a previously known state, such as before objects were erroneously deleted.

Nonauthoritative Restore

The default method for restoring a directory with the Windows Server Backup tool is nonauthoritative. If you restore the data using this tool, and no other, the domain controller will detect it hasn’t been updated since the backup and start automatically receiving replication updates from its replication partners. Any directory changes that occurred after the backup took place will be applied to the restored domain controller.

You cannot restore an Active Directory that is online; you must place the domain controller into Directory Services Restore Mode (DSRM). To reboot in DSRM:

• Step 1. Launch Windows Administrative Tools from the Start Menu.

• Step 2. Launch the System Configuration tool.

• Step 3. Select the Boot tab.

• Step 4. In the Boot options section, select the Safe boot box and the Active Directory repair option. Click OK (see Figure 6-5).

  

  Figure 6-5 The System Configuration Menu for Booting in DSRM Mode

• Step 5. You may be told the computer needs to restart. Click OK or manually restart the server.

• Step 6. After the server reboots, on the logon screen select Other user.

• Step 7. For the user name type .\Administrator and for the password enter the DSRM password chosen when the server was promoted to a domain controller.

  NOTE

  If it has been a while since you promoted the server and you don’t recall the DSRM password, you’re not alone. This is a common occurrence, and AD DS has a method to reset the password using ntdsutil, covered later in this chapter.

• Step 8. From the Start Menu launch Server Manager.

• Step 9. Click Tools > Windows Server Backup.

• Step 10. Select Local Backup from the left-hand navigation pane.

• Step 11. Right-click Local Backup and select Recover.

• Step 12. Select A backup stored on another location and click Next.

• Step 13. Choose either Local drives or Remote shared folder depending on where you stored your custom backup in the previous section. Click Next.

• Step 14. Choose the location of the backups and click Next.

• Step 15. If you chose a remote shared folder, type the fully qualified username and password of a domain user with access to the location and click OK.

• Step 16. The recovery wizard lists all the backups found in that location. Select the backup you want to recover based on date and click Next.

• Step 17. Select System state to restore Active Directory Domain Services and click Next (see Figure 6-6).

  

  Figure 6-6 The Recovery Wizard Being Used to Restore the System State for AD DS

• Step 18. Select Original Location and click Next.

• Step 19. Review the warning and click OK.

• Step 20. If you chose a remote shared folder, you receive another warning. Review this warning and click OK.

• Step 21. Review the details of the recovery and click Recover.

• Step 22. Review the warning and click Yes.

Once the recovery is complete, you need to turn off DSRM mode. Repeat the steps to turn it on but uncheck the Safe boot option and restart the server. After the server finishes rebooting, any directory updates will replicate from another domain controller to this one.

Authoritative Restore

An authoritative restore begins similarly to the nonauthoritative restore process but diverges significantly at the end. When you perform an authoritative restore you first perform a recovery from backup media and then designate either the entire directory, a subtree, or individual objects in the restored directory to take precedence over other instances of those objects elsewhere in the forest. In other words, the recovered directory becomes authoritative for all its replication partners and replicates its version of the data to those partners even if it contains older data.

One common use case for an authoritative restore is to recover objects accidentally deleted from the directory. After the restore completes but prior to restarting the controller and bringing it online, you designate the deleted objects as authoritative. Those objects are then replicated from the recovered controller to its replication partners.

To perform an authoritative restore:

• Step 1. Follow the steps from the previous section to perform a nonauthoritative restore.

• Step 2. Reboot the domain controller while remaining in DSRM. This ensures the domain controller remains offline.

• Step 3. Launch a command prompt.

• Step 4. Type ntdsutil and press Enter.

• Step 5. At the ntdsutil command prompt, there are two different types of restore:

  • To authoritatively restore the entire directory type restore database and press Enter.

  • To authoritatively restore only a portion type restore subtree <subtree distinguished name> (e.g., restore subtree ou=Finance,dc=certguide,dc=com).

• Step 6. Once the restore completes, at the ntdsutil command prompt type quit and press Enter.

• Step 7. Reboot the domain controller in normal mode by following the directions covered previously.

The domain controller then replicates any changes in the specified restore scope to its partner controllers in the domain.

Configuring and Restoring Objects by Using the Active Directory Recycle Bin

One way in which Microsoft attempts to simplify the process of recovering accidentally deleted objects is the creation of a Recycle Bin or Deleted Objects container. Just like the Recycle Bin on Windows file system, the Active Directory Recycle Bin is a staging area where deleted objects are placed. If the delete was inadvertent or needs to be reversed for any reason a domain admin can simply view the deleted objects container and restore the object.

To use the AD Recycle Bin, the domain must be at the forest functional level of 2008 R2 or higher. You must also first enable the Recycle Bin:

• Step 1. Log on to a writeable domain controller.

• Step 2. From the Start Menu launch Server Manager.

• Step 3. Select Tools > Active Directory Administrative Center.

• Step 4. On the left-hand navigation pane select the domain you want to enable Recycle Bin for.

• Step 5. On the right-hand Tasks pane, click Enable Recycle Bin (see Figure 6-7).

• Step 6. You receive a warning that this process is irreversible. Click OK.

• Step 7. You receive a notification to refresh AD Administrative Center. Click OK and close and reopen ADAC.

  There now is a Deleted Objects container at the top level of the domain.

  

  Figure 6-7 The ADAC Tasks Pane with the Enable Recycle Bin Option Highlighted

• Step 8. Browse to an object, right-click it, and select Delete.

• Step 9. Click Yes to confirm.

• Step 10. Browse to the Deleted Objects container to see the deleted object.

• Step 11. Right-click the object in the container and select Restore.

The object you deleted in Step 8 is restored to its original location. Notice the context menu for the deleted object also contained an option Restore To. This option allows you to restore the object completely intact but in a different location in the directory.

Managing Active Directory Offline

Many tasks can only be performed while the AD DS service is in an offline state. Prior to Windows Server 2008 R2, an administrator could only place AD DS into an offline state by restarting in Directory Services Restore Mode (DSRM) as described earlier in this chapter. This process is time consuming and cumbersome and not always ideal if the domain controller in question needs to be running to perform other tasks on the network.

Instead, the AD DS service can now be brought offline using the same method for any other service in Windows. To stop the AD DS service with the GUI, perform the following steps:

• Step 1. Log on to a writeable domain controller.

• Step 2. From the Start Menu launch Server Manager.

• Step 3. Select Tools > Services.

• Step 4. Right-click the service Active Directory Domain Services and select Stop.

• Step 5. A dialog appears warning you of dependent services that must also be stopped. Click Yes (see Figure 6-8).

  

  Figure 6-8 The Dependent Services Confirmation Dialog Presented When Stopping Active Directory Domain Services

The service is now in a stopped state. You can also use the command prompt to stop a service with the net stop command:

• Step 1. Log on to a writeable domain controller.

• Step 2. Launch a command prompt.

• Step 3. Type net stop ntds and press Enter.

• Step 4. Review the list of dependent services that will also be stopped. Type Y and press Enter (see Figure 6-9).

  
  

  Figure 6-9 Using net stop to Shut Down the Active Directory Domain Services Service

Performing Offline Defragmentation of an Active Directory Database

Active Directory Domain Services performs an online defragmentation of its database every 12 hours automatically. This process cleans up and releases free space left behind during standard directory operations. This online defragmentation only recaptures free space within the directory file, though; it does not shrink the overall size of the file. If a major object move or other operation has occurred, you may want to perform an offline defragmentation to recapture space on the file system.

Before performing the defragmentation, ensure you have an up-to-date backup of the AD DS directory by performing the following steps:

• Step 1. Log on to a writeable domain controller.

• Step 2. Bring the AD DS service offline according to the previous steps.

• Step 3. Launch a command prompt.

• Step 4. Type ntdsutil and press Enter.

• Step 5. At the ntdsutil prompt type activate instance ntds and press Enter.

• Step 6. At the ntdsutil prompt type files and press Enter.

• Step 7. At the files prompt type compact to C:\defrag and press Enter.

  NOTE

  The location you choose to compact to in Step 7 must have enough space for the defragmentation operation. If it does not, the compact will fail.

• Step 8. Once the operation completes, review the instructions for copying the ntds.dit file and deleting log files (see Figure 6-10).

  
  

  Figure 6-10 The ntds Offline Defragmentation Utility

• Step 9. At the file maintenance prompt type quit and press Enter.

• Step 10. At the ntdsutil prompt type quit and press Enter.

A compacted version of the ntds.dit file (the directory database file) now exists in the location specified in Step 7. Copy this file and overwrite the current ntds.dit file, by default installed at C:\Windows\NTDS. Delete the log files as instructed by ntdsutil and reboot the computer.

Cleaning Up Metadata

If a domain controller in the forest fails or is otherwise corrupted for some reason, the easiest thing to do is usually to simply rebuild it from scratch. The replacement controller receives an up-to-date directory via replication from the other controllers in the domain. When you do this, or if a DC is removed from the network for any reason without first being demoted, metadata about that controller needs to be manually removed from the directory.

In earlier versions of Windows Server, cleaning this metadata out of the directory was a multistep process facilitated through ntdsutil. You can still clean metadata in this fashion, but since Windows Server 2012, the clean-up process can be completed with the GUI using Active Directory Users and Computers. All that is required is to delete the domain controller object from the directory the same as you would any other object as described in the following list. Additional confirmations are requested by ADUC.

• Step 1. Log on to a writeable domain controller.

• Step 2. From the Start Menu launch Server Manager.

• Step 3. Select Tools > Active Directory Users and Computers.

• Step 4. Navigate to the domain where you want to clean up metadata.

• Step 5. Select the Domain Controllers container on the left-hand navigation pane.

• Step 6. Right-click the controller being removed from the directory and select Delete.

• Step 7. Click Yes at the confirmation prompt.

• Step 8. You receive a warning dialog box. Check the Delete this Domain Controller anyway box and click Delete (see Figure 6-11).

• Step 9. If the controller was a global catalog, you receive another confirmation prompt. Click Yes.

• Step 10. If the controller held any FSMO roles, you receive another confirmation prompt. Click OK to move the role(s) to the controller indicated.

  

  Figure 6-11 The Confirmation Dialog for Deleting a Domain Controller from ADUC Instead of Gracefully Demoting It

The DC is now removed from the directory. If you attempt to start up that controller after cleaning the metadata for it, you receive an error trying to log on.

Configuring Replication to Read-Only Domain Controllers (RODCs)

Read-Only Domain Controllers (RODCs) were introduced in Chapter 2, “Installing and Configuring Domain Controllers.” An RODC is a useful variant for both security purposes as well as replication load. The name “read-only” can be misleading. An RODC is read-only specifically for the purposes of replication from other controllers in the domain. Replication to RODCs is a one-way operation. Updates are only replicated to an RODC, and the RODC never sends out updates. Because inbound replication is a single-threaded operation, other writeable domain controllers do not need to poll RODCs for updates, which simplifies and reduces the replication load on the network.

This structure means that any accidental deletion of data or corruption of files on an RODC can be easily remedied by receiving replication updates or simply repromoting the server to an RODC. There is no fear of lost updates or changes that haven’t replicated to other partners yet.

Because RODCs are typically used to service users and applications at remote sites, they can still receive attempted writes from those users. When a user or application attempts to perform a write operation on an RODC, one of the three following things can occur:

• The RODC forwards the write request to a writeable domain controller and then receives the update via standard replication from its partners. RODCs only forward a limited set of writes, including

  • Password changes

  • LastLogonTimeStamp

  • Service Principal Name (SPN) updates

• The RODC sends a referral for a writeable domain controller to the originating application. The application can then target a writeable domain controller with the desired update.

• The write operation fails and an error is returned to the client.

Configuring Password Replication Policy (PRP) for RODC

One of the ways in which RODCs improve security is by not storing passwords in their local directory. RODCs are often installed at remote locations or in perimeter networks (DMZs) where there is a greater risk of data being compromised. Locations like that also have a greater risk of losing their network connectivity to writeable replication partners. If that happens, users cannot authenticate against the RODC until the connectivity has been restored. A domain controller that cannot be used for authentication has lost most of its value to the organization.

To mitigate the impact of losing network connectivity to a writeable domain controller, you can choose to cache account passwords on the RODC. Caching a password allows the RODC to save, for specified users, the last password used during an authentication event. If the RODC is unable to communicate with a writeable domain controller, it can use those cached passwords to authenticate users and computers. RODCs can be configured to either allow or deny accounts to cache passwords through the Password Replication Policies (PRPs).

Two default security groups are created in the domain when an RODC is first installed (see Figure 6-12):

• Allowed RODC Password Replication Group: This group contains users, computers, and other security groups that can be cached on the RODC. By default it is empty and must be populated by an administrator.

• Denied RODC Password Replication Group: This group contains users, computers, and other security groups that can never have their passwords cached on the RODC. By default it includes a number of high-security members such as Domain Admins, Schema Admins, and Cert Publishers.

In the event an account ends up in both groups, the Denied group takes precedence.

The recommended way to allow or deny user or computer accounts caching on an RODC is to simply use the default groups provided by AD DS. To explicitly allow or deny accounts:

• Step 1. Log on to a writeable domain controller.

• Step 2. From the Start Menu launch Server Manager.

• Step 3. Click Tools > Active Directory Users and Computers.

• Step 4. On the left-hand navigation pane expand the domain and select Domain Controllers.

• Step 5. In the right-hand pane right-click the RODC you want to configure and select Properties.

• Step 6. Select the Password Replication Policy tab (see Figure 6-12).

• Step 7. Click Add.

• Step 8. Choose either Allow passwords or Deny passwords depending on whether you are allowing or denying caching.

• Step 9. Use the standard directory search box to find the account(s) you want to add to the list. Click Check Names, and valid accounts are underlined. Click OK.

• Step 10. The account(s) are now listed in the Password Replication Policy tab with the appropriate setting.

  

  Figure 6-12 The Password Replication Policy Tab of a Read-Only Domain Controller in ADUC

You can also choose to prepopulate an account password on the RODC, effectively caching it before the account has first logged on. This is useful in scenarios when you are aware the connectivity to a writeable domain controller will be interrupted but an account still needs to authenticate to the RODC. To prepopulate a password:

• Step 1. Add the user to the default Allow security group or follow the steps from the previous list to allow the RODC to cache the user account. You cannot prepopulate an account that isn’t already allowed.

• Step 2. From the Password Replication Policy tab click Advanced.

• Step 3. Click Prepopulate Passwords.

• Step 4. Use the standard directory search box to find the account you want to prepopulate. Click Check Names, and valid accounts are underlined.

• Step 5. Review the confirmation dialog box (see Figure 6-13). Click Yes.

  

  Figure 6-13 List of Accounts Whose Passwords Will Be Prepopulated on an RODC

The repadmin tool can be used with the /prp switch to effect many of these same changes. The documentation for the /prp switch can be found here: https://technet.microsoft.com/en-us/library/cc835090(v=ws.11).aspx#BKMK_View. The next section covers usage of repadmin.

Monitoring and Managing Replication

Replication between domain controllers generally happens without problems; however, due to the potentially complex nature of multimaster replication and the rules governing how AD DS handles replication and conflict resolution between many masters, there is occasionally a problem. Troubleshooting issues with replication is always a headache for AD DS admins.

The command-line tool for troubleshooting replication is repadmin, and it is installed by default with the AD DS server role. The basic syntax for repadmin is

repadmin <cmd> <args>

The <args> that repadmin can take depend on which option is chosen for the <cmd> parameter. Table 6-3 lists some of the key <cmd> parameter options.

Table 6-3 Common <cmd> Parameters for repadmin

Command	Description
/prp	Lists and modifies the Password Replication Policy for RODCs
/ReplSummary	Identifies domain controllers that are failing inbound or outbound replication and summarizes the results
/ShowRepl	Displays the replication status of the current domain controller
/Queue	Displays the inbound replication requests currently waiting to be processed

The repadmin /prp switch has the following arguments:

• Add: Adds a specified entry to the Allowed List for password caching

• Delete: Removes a specified entry from the Allowed List for password caching

• View: Displays the security principals in a specified list or displays the current PRP setting for a specified account

To use repadmin to display the list of accounts whose passwords are already cached on an RODC, run the following command from a command prompt of any domain controller (see Figure 6-14):

repadmin /prp view <RODC-server-name> reveal

where <RODC-Server-name> is the name of the RODC you want to query.

The repadmin /replsummary switch has the following arguments:

• /bysrc: Summarizes the replication status for all domain controllers that a given source replicates to

• /bydest: Summarizes the replication status for all domain controllers that a given destination replicates from

• /errorsonly: Shows on the domain controllers where there is an error

To get a summarized list of the current replication status, run the following command from a command prompt of any domain controller (see Figure 6-15):

repadmin /replsummary

The repadmin /showrepl switch has the following arguments:

• /repsto: Lists the partner domain controllers with which the targeted domain controllers perform outbound replication to

• /verbose: Displays additional information

• /csv: Displays the results in comma separated value format

To see a replication status report, run the following command from a command prompt of any domain controller:

repadmin /showrepl /verbose

The repadmin /queue switch does not take parameters. It is generally run as is:

repadmin /queue

There are a handful of useful PowerShell cmdlets for replication management as well, listed in Table 6-4.

Table 6-4 PowerShell Replication Cmdlets

Cmdlet	Description
Get-ADReplicationFailure	Returns all failures associated with a given domain controller
Get-ADReplicationPartnerMetadata	Returns the replication metadata for a set of one or more replication partners
Get-ADReplicationUpToDatenessVector Table	Displays the highest Update Sequence Number (USN) for the specified domain controller

All three of these cmdlets are typically run with only a single parameter, -Target, like so:

Get-ADReplicationFailure -Target localhost

Using localhost for the target specifies the current machine the cmdlet is being run from. You can also pass any fully qualified domain name into the -Target parameter.

Upgrading SYSVOL Replication to Distributed File System Replication (DFSR)

With the release of Windows 2000 and Server 2003, Microsoft relied on a technology known as NT File Replication Service (FRS) to replicate updates to the SYSVOL between domain controllers. With the release of Server 2008, the replication technology was upgraded to Distributed File System Replication (DFSR).

DFSR includes a number of efficiency and security improvements over FRS. Unfortunately, if your domain was originally a 2000 or 2003 domain and you have not gone through this migration process, you are still relying on FRS. Even if you’ve upgraded the forest and domain functional levels to 2008 or higher the migration process must be performed for older installations. Microsoft highly recommends migrating from FRS to DFSR for SYSVOL replication.

The migration for SYSVOL is done with the dfsrmig command-line utility. The syntax for dfsrmig is straightforward:

dfsrmig [/SetGlobalState <state> 
| /GetGlobalState 
| /GetMigrationState]]

To migrate you need to run this command iteratively. First with the /SetGlobalState parameter, then with the /GetMigrationState parameter, and then repeating:

• Step 1. Log on to a writeable domain controller.

• Step 2. Launch a command prompt.

• Step 3. Type dfsrmig /SetGlobalState 1 and press Enter.

• Step 4. All DCs in the domain are now migrating to state 1. Type dfsrmig /GetMigrationState 3 and press Enter.

• Step 5. If the migration to state 1 is complete you receive a message indicating that. If not, wait one minute and rerun Step 4 until you receive a message indicating All domain controllers have migrated successfully to the Global state (‘Prepared’).

• Step 6. Type dfsrmig /SetGlobalState 2 and press Enter.

• Step 7. Repeat Step 5 until you receive the success message.

• Step 8. Type dfsrmig /SetGlobalState 3 and press Enter.

• Step 9. Repeat Step 5 until you receive the success message (see Figure 6-16).

  

  Figure 6-16 The Final Migration State of SYSVOL to DFSR. All Domain Controllers Have Migrated Successfully.

The SYSVOL has now been successfully migrated.