ACTIVE DIRECTORY ADMINISTRATION TIPS



ACTIVE DIRECTORY ADMINISTRATION TIPS

Preventing Active Directory disaster: The replication lag site

By Gary Olsen, Contributor

09 May 2005

Rating: -5.00- (out of 5)

[pic]

[pic]

Since January, my articles have dealt with various aspects of AD disaster recovery (DR). It is a good idea, of course, to have a DR plan for major catastrophes, but there are a number of actions you can take to prevent disaster -- or at least minimize the chances of an AD disaster such as, say, the accidental bulk deletion of objects.

One of those actions is to create a replication lag site. Very simply, the lag site is an Active Directory site that is intentionally a few days to a week behind the rest of the domain. Of course, there are some gotchas when doing this, which we'll discuss shortly, but the lag site basically preserves a live backup of the AD.

You create a lag site by putting a domain controller from the hub site into its own site (we'll call it the DR site) with a site link to the hub site. Configure the hub-DR site link for a replication frequency of 96 hours. That means that the DR site domain controller's copy of the AD will be 96 hours behind the rest of the forest.

Now, remember that administrator who -- mistakenly, of course -- recently deleted an organizational unit (OU) with 10,000 users? Your only alternative is to do an authoritative restore (and hope your backup media is valid). That means you have to perform the following authoritative restore process:

1. Unplug the domain controller that has the authoritative copy of the AD from the network.

2. Get the appropriate system state backup tape that you made before the deletion.

3. Make sure the tape is valid and that it is no older than the TombstoneLifetime (60 days by default).

4. Boot the restore DC into Directory Service Restore Mode (DSRM).

5. Do a system state restore to this DC. Note that you have to do this twice to get the groups and users restored properly -- see Microsoft KB 280079. This is not trivial.

6. Plug the DC into the network.

7. Replication will force the AD objects from the restored DC to the other DCs in the network.

Note: Refer to Microsoft's KB 241594 and 280079 for more details on authoritative restore.

With the lag site, however, you now have a DC that has a copy of the AD before the deletion took place (assuming you noticed it within four days of the occurrence). Let's say you discovered that an administrator mistakenly deleted 10,000 accounts yesterday. You can go to the DC in the lag site, which still has a copy of the AD before the deletion and perform an authoritative restore using that DC's copy of the AD, and push it out. Again, this depends on when the lag site replicates and when the deletion took place. If replication takes place on Monday and Friday, and the deletion happens Thursday night, then you have a small window of opportunity.

Get control of the gotchas

It is important that you take steps to prevent authentication from the lag site DCs since it has security data (accounts, passwords, locked accounts, group membership, etc.) that is a week old. You can accomplish this by defining a site policy for the lag site and defining the "DCLocator DNS Records Not Registered by the DCs" setting. The Mnemonics field is described in the Explain tab. You need to include all of the Mnemonics except CNAME record (needed for replication). The Explain tab is a bit confusing, but it's a space-delimited list as shown in Figure 1. The Mnemonics themselves are listed in the left column on the Explain tab.

[pic]

Figure 1.

Recommendations that can save your sanity

The minimum configuration to implement a lag site is to have a single site with at least one DC from each domain in the site. The preferred configuration is to have two DCs from each domain in the site. Set their replication frequency for 168 hours (seven days) and stagger the schedule so they replicate every 3.5 days. Thus, you have two old copies to choose from, mitigating the problem just noted.

You can also use a Virtual Server as the lag site DCs to save hardware costs.

If you have a multiple (parent/child) domain structure, then you have a lot of unseen problems. When you attempt a restore on one domain, it will fail to restore cross-domain group memberships. Hewlett-Packard Co. was the first to discover this problem, and the company developed a tool called Active Directory Link Replication Manager (ADLRM) that stores these links in a SQL database and restores them quite nicely. The tool also can store and restore individual attributes. For instance, if you have an HR application that modifies certain user attributes, and you need to restore the attribute to the pre-modified value, ADLRM can do that without requiring a full-scale authoritative restore. You can ask for more details about ADLRM by sending e-mail to ADLRM-info@.

In Chapter 11 of my book Windows Server 2003 on HP ProLiant Servers (), you'll find more information about the use of the lag site and other Active Directory disaster recovery procedures.

[pic]

Gary Olsen is an HP/Compaq consultant on Active Directory design. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download