Appendix B: Do Not Use a Lag Site as a Disaster Recovery Strategy
Applies To: Windows Essential Business Server, Windows SBS 2003, Windows SBS 2008, Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2
A "lag site" is an Active Directory site that is configured with a replication latency. For example, the site may replicate only one day of the week. Microsoft supports a replication latency up to the equivalent of the tombstone lifetime of the Active Directory forest, which is 180 days by default. In this case, a lag site is simply an out-of-date site compared to the data that is held by the majority replicas.
Some users perceive that a lag site, with a “quasi-offline domain controller,” can be used to recover accidentally deleted objects faster by avoiding a restore of the affected domain controllers from backups. Some organizations have incorporated lag sites as part of their disaster recovery strategies.
However, Microsoft does not support the use of a lag site as a disaster recovery strategy. Organizations are not encouraged to deploy a lag site as their sole disaster recovery solution. If they do deploy a lag site for this purpose, they do this at their own risk.
In particular, hotfixes and service packs, as well as monitoring products, such as Microsoft Operations Manager (MOM) and Microsoft System Center Operations Manager, do not recognize a quasi-offline domain controller state that is differentiated by functioning replication but client computers not using the server services. Microsoft makes no guarantees that our servicing and monitoring products will not re-enable Netlogon and Key Distribution Center (KDC) services in a lag site. In addition, other Microsoft products, such as Exchange Server, are not designed to operate in a lag site and they may not function properly with lag site domain controllers.
The following are some additional points to consider if your organization decides to deploy a lag site—even after acknowledgement that Microsoft does not support the use of a lag site as a disaster recovery strategy:
A lag site is not guaranteed to be intact in a disaster, such as accidental bulk deletion of objects.
If the disaster is not discovered in time before replication occurs, the problem is replicated to the lag site, and the lag site cannot be used to undo the disaster.
Therefore, administrators must act immediately when a disaster occurs: inbound and outbound replication must be disabled, and the repadmin /force command must not be used.
Replication from a lag site might have unrecoverable consequences.
Because a lag site contains out-of-date data, using it as a replication source might result in data loss, depending on the amount of latency (for example, if latency exceeds the tombstone lifetime) between the disaster event and the last replication to the lag site.
If something goes wrong during recovery from a lag site, a forest recovery might be necessary to roll back the changes.
A lag site poses security threats to the corporate environment.
For example, when an employee is terminated from an organization, the employee’s user account is deleted immediately from Active Directory Domain Services (AD DS) in the main site, but the account might remain active in the lag site. If the lag site domain controllers allow logons (that is, Netlogon is not disabled), this might lead to unauthorized users having access to corporate resources.
Configuring and deploying a lag site requires careful consideration:
An administrator must decide the number of lag sites to deploy in a forest. The more domains that have lag sites, the more likely that a domain can recover from a replicated disaster. However, this can also mean increased hardware and maintenance costs.
An administrator must decide the amount of latency. The shorter the latency, the more up to date and useful the data will be in the lag site. However, this also means that administrators must act quickly to stop replication to the lag site when a disaster occurs.
This list of considerations is not exhaustive, and there might be other problems with deploying lag sites as a disaster recovery strategy. Some organizations that deploy lag sites as part of a disaster recovery strategy might implement various ways of mitigating these problems. For example, an organization might implement staggered lag sites to help address the problem with replication latency or use virtualization to minimize hardware and maintenance costs. But as Microsoft has always strongly recommended, the best way to prepare for an Active Directory malfunction is to back up domain controllers frequently and verify these backups regularly through test restorations. A lag site is not a replacement for backups.
Even though Microsoft does not support the use of a lag site as a disaster recovery strategy, the following will continue to be supported:
Delayed replication sites are supported. For example, you might configure a site to replicate on a custom schedule to reduce wide area network (WAN) utilization costs or to reserve WAN link utilization for other applications. This delayed replication site should not be used to restore Active Directory data or to roll back from recent changes.
Authoritatively restoring objects on any arbitrary domain controller in a domain is supported.
Disabling registration of domain service (SRV) resource-record-specific Domain Name System (DNS) entries that point to a given site is supported.
Disabling replication entirely (or shutting domain controllers down) for periods not exceeding the forest tombstone lifetime on a given domain controller or on every domain controller in a site is supported.
To view past Active Directory data, consider using snapshots in Windows Server 2008. For more information, see Active Directory Database Mounting Tool Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkID=132577).
To recover accidentally deleted objects, use Active Directory Recycle Bin, which is a new feature in Windows Server 2008 R2. For more information, see the Active Directory Recycle Bin Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkID=139659).