Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II

EMC logo


Virtualized Active Directory is ready for Primetime, Part II!

In the first of this two-part blog series, I discussed how virtualization-first is the new normal and fully supported; and elaborated on best practices for Active Directory availability, achieving integrity in virtual environments, and making AD confidential and tamper-proof.

In this second installment, I’ll discuss the elements of time in Active Directory, touch on replication, latency and convergence; the preventing and mediating lingering objects, cloning and of much relevance, preparedness for Disaster Recovery.

Proper Time with Virtualized Active Directory Domain Controllers (AD DC)

Time in virtual machines can easily drift if they are not receiving constant and consistent time cycles. Windows operating systems keep time based on interrupt timers set by CPU clock cycles. In a VMware ESXi host with multiple virtual machines, CPU cycles are not allocated to idle virtual machines.

To plan for an Active Directory implementation, you must carefully consider the most effective way of providing accurate time to domain controllers and understand the relationship between the time source used by clients, member servers, and domain controllers.

The Domain Controller with the PDC Emulator role for the forest root domain ultimately becomes the “master” timeserver for the forest – the root time server for synchronizing the clocks of all Windows computers in the forest. You can configure the PDC to use an external source to set its time. By modifying the defaults of this domain controller’s role to synchronize with an alternative external stratum 1 time source, you can ensure that all other DCs and workstations within the domain are accurate.

Why Time Synchronization Is Important in Active Directory

Every domain-joined device is affected by time!

Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer. Many factors can affect time synchronization on a network. The following factors often affect the accuracy of synchronization in AD DS:

  • Network conditions
  • The accuracy of the computer’s hardware clock
  • The amount of CPU and network resources available to the Windows Time service

Prior to Windows Server 2016, the W32Time service was not designed to meet time-sensitive application needs. Updates to Windows Server 2016 allow you to implement a solution for 1ms accuracy in your domain.

Figure 1: How Time Synchronization Works in Virtualized Environments

See Microsoft’s How the Windows Time Service Works for more information.

How Synchronization Works in Virtualized Environments

An AD DS forest has a predetermined time synchronization hierarchy. The Windows Time service synchronizes time between computers within the hierarchy, with the most accurate reference clocks at the top. If more than one time source is configured on a computer, Windows Time uses NTP algorithms to select the best time source from the configured sources based on the computer’s ability to synchronize with that time source. The Windows Time service does not support network synchronization from broadcast or multicast peers.

Replication, Latency and Convergence

Eventually, changes must converge in a multi-master replication model…

The Active Directory database is replicated between domain controllers. The data replicated between controllers called ‘data’ are also called ‘naming context.’ Only the changes are replicated, once a domain controller has been established. Active Directory uses a multi-master model; changes can be made on any controller and the changes are sent to all other controllers. The replication path in Active Directory forms a ring which adds reliability to the replication.

Latency is the required time for all updates to be completed throughout all domain controllers on the network domain or forest.

Convergence is the state at which all domain controllers have the same replica contents of the Active Directory database.

Figure 2: How Active Directory Replication Works

For more information on Replication, Latency and Convergence, see Microsoft’s Detecting and Avoiding Replication Latency.”

Preventing and Remediating Lingering Objects

Don’t revert to snapshot or restore backups beyond the TSL.

Lingering objects are objects in Active Directory that have been created, replicated, deleted, and then garbage collected on at least the Domain Controller that originated the deletion but still exist as live objects on one or more DCs in the same forest. Lingering object removal has traditionally required lengthy cleanup sessions using various tools, such as the Lingering Objects Liquidator (LoL).

Dominant Causes of Lingering Objects

  1. Long-term replication failures

While knowledge of creates and modifies are persisted in Active Directory forever, replication partners must inbound replicate knowledge of deleted objects within a rolling Tombstone Lifetime (TSL) # of days (default 60 or 180 days depending on what OS version created your AD forest). For this reason, it’s important to keep your DCs online and replicating all partitions between all partners within a rolling TSL # of days. Tools like REPADMIN /SHOWREPL * /CSV, REPADMIN /REPLSUM and AD Replication Status should be used to continually identify and resolve replication errors in your AD forest.

  1. Time jumps

System time jump more than TSL # of days in the past or future can cause deleted objects to be prematurely garbage collected before all DCs have inbound replicated knowledge of all deletes. The protection against this is to ensure that:

  • The forest root PDC is continually configured with a reference time source (including following FSMO transfers).
  • All other DCs in the forest are configured to use NT5DS hierarchy.
  • Time rollback and roll-forward protection has been enabled via the maxnegphasecorrection and maxposphasecorrection registry settings or their policy-based equivalents.
  • The importance of configuring safeguards can’t be stressed enough.
  1. USN rollbacks

USN rollbacks are caused when the contents of an Active Directory database move back in time via an unsupported restore. Root causes for USN Rollbacks include:

  • Manually copying previous version of the database into place when the DC is offline.
  • P2V conversions in multi-domain forests.
  • Snapshot restores of physical and especially virtual DCs. For virtual environments, both the virtual host environment AND the underlying guest DCs should be compatible with VM Generation ID. Windows Server 2012 or later, and vSphere 5.0 Update 2 or later, support this feature.
  • Events, errors and symptoms that indicate you have lingering objects.

Figure 3: USN Rollbacks – How Snapshots Can Wreak Havoc on Active Directory

Cloning

You should always use a test environment before deploying the clones to your organization’s network.

DC Cloning enables fast, safer Domain Controller provisioning through clone operation.

When you create the first domain controller in your organization, you are also creating the first domain, the first forest, and the first site. It is the domain controller, through group policy, that manages the collection of resources, computers, and user accounts in your organization.

Active Directory Disaster Recovery Plan: It’s a Must

Build, test, and maintain an Active Directory Disaster Recovery Plan!

AD is indisputably one of an organization’s most critical pieces of software plumbing and in the event of a catastrophe – the loss of a domain or forest – its recovery is a monumental task. You can use Site Recovery to create a disaster recovery plan for Active Directory.

Microsoft Active Directory Disaster Recovery Plan is an extensive document; a set of high-level procedures and guidelines that must be extensively customized for your environment and serves as a vital point of reference when determining root cause and how to proceed with recovery with Microsoft Support.

Summary

There are several excellent reasons for virtualizing Windows Active Directory. The release of Windows Server 2012 and its virtualization-safe features and support for rapid domain controller deployment alleviates many of the legitimate concerns that administrators have about virtualizing AD DS. VMware® vSphere® and our recommended best practices also help achieve 100 percent virtualization of AD DS.

Please reach out to your Dell EMC representative or checkout Dell EMC Consulting Services to learn how we can help you with virtualizing AD DS or leave me a comment below and I’ll be happy to respond back to you.

Sources

Virtualizing a Windows Active Directory Domain Infrastructure

Related Blog

Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part I

The post Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II appeared first on InFocus Blog | Dell EMC Services.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

  • No Related Posts

7023293: How to repair ADLDS repplication issues within the LDS instance used by DRA

This document (7023293) is provided subject to the disclaimer at the end of this document.

Environment

NetIQ Directory and Resource Administrator 8.x

NetIQ Directory and Resource Administrator 9.x

Situation

Each NetIQ Directory and Resource Manager (DRA) Sever hosts a local ADLDS instance. This allows for secure replication of various DRA configuration settings, as well certain AD object properties; only visible within DRA. Replication between each local instance on DRA servers is controlled via the built-in ADLDS replication settings. Each DRA server will register its hostname and ADLDS service name within the sites and services container of the ADLDS Configuration partition. Successful ADLDS replication is also required in order for the ADLDS instance hosted on the Primary Server to validate its invalid Flexible Single Master Operation (FSMO) roles.


The ADLDS instance on the Primary DRA Server will host the schema master and naming master ADLDS roles. This roles are required in order to modify the ADLDS schema and create new objects within the ADLDS instance. These actions are required in order to maintain the health of the DRA MMS as well as apply DRA product patches and version upgraded.

The status of the ADLDS Replication can be validated within the DRA 9.2 (and newer) built-in and standalone Health Check Utility. In addition the Windows Event Viewer ADAM Event logs will report on the health and status of the local ADLDS instance.

Resolution

The status of the ADLDS Replication can be validated within the DRA 9.2 (and newer) built-in and standalone Health Check Utility. Should the HCU report a failure with the ADLDS replication, it will often provide the administrator with a Fix-It option.

Should the HCU utility not be able to fix the error, or you are running an older version of DRA; it is possible to use the Microsoft Replication Admin (RepAdmin) CMD utility to fix the issue.

Before launching the utility it is helpful to validate the current replication partners contained within configuration partition; located on each DRA servers local LDS instance. This can be done using Microsoft Active Directory Service Interface Editor (ADSIEdit). By default only the AD account running the DRA Services will have Admin rights into the local ADLDS instance. Once in ADSI Edit, you will need to connect to the Configuration naming context on the local server, using port 50000. Once in the configuration the replication partners are stored within the following path: CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={<Unique Guid shared among all ADLDS instances in the current replication set>}. Each replication partner will be represented a Server Object with the naming format: <DRAServerName>$<ADLDS Windows Service Name on the DRA Server>. If any server objects listed are invalid, ADLDS replication will fail.

Once every DRA Server’s ADLDS instance has the correct replication partners, you will need to re-start the replication, using the steps below. These steps must be done from an Administrator CMD Prompt, in the context of the DRA Service Account.

1. Disable outbound replication on all DRA Servers:Repadmin /options <DRAServername>:50000 +DISABLE_OUTBOUND_REPL

2. Disable inbound replication on all DRA ServersRepadmin /options <DRAServerName>:50000 +DISABLE_INBOUND_REPL

3. Re-enable outbound replication ONLY on the Primary DRA ServerRepadmin /options <PrimaryDRAServername>:50000 -DISABLE_OUTBOUND_REPL

4. Re-enable inbound replication on all secondary DRA ServersRepadmin /options <DRAServerName>:50000 -DISABLE_INBOUND_REPL

5. Force the ADLDS instance on the Primary DRA Server to replicate its contents to all secondary DRA ServersRepadmin /syncall <PrimaryDRAServerName>:50000

6. Re-enable Inbound Replication on the Primary DRA ServerRepadmin /options <PrimaryDRAServerName>:50000 -DISABLE_INBOUND_REPL

7. Re-enable outbound replication on all secondary DRA ServersRepadmin /options <DRAServername>:50000 -DISABLE_OUTBOUND_REPL

8. Run another ADLDS ReplicationRepadmin /syncall <PrimaryDRAServerName>:50000

The replication status can be validated using: repadmin /showrepl <DRAservername>:50000. The DRA implementation of ADLDS features three naming contexts to be replicated:

    • Configuration
    • Schema
    • DRA.COM

Cause

The ADLDS replication can fail for a number of reasons. One more common reason is invalid replication partners. Anyone common reason is multiple ADLDS instances running on a single DRA Server. When the ADLDS replication fails, successful validation of the FSMO roles will also fail. The replication must be fixed, before the ADLDS FSMO roles can be validated.

Additional Information

The DRA Standalone Health Check Utility , can be installed from the <path to NetIQAdmininstallationKit>Evaluation Utilities folder. This HCU can be installed on any DRA 9.x server.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related:

Symantec Data Loss Prevention – Secondary Domain Conrollers

I need a solution

Hello,
I have a question about domain controllers.
 
You can add domain controllers in two locations:
-krb3.ini
-Directory Connections
 
In krb3.ini, is it possible to add multiple domain controllers for each domain?
[libdefaults]
        default_realm = Domain1
[realms]
        Domain1 = {
                 kdc = DomainController1
        }
 
For Directory Connections, I can added multiple domain controllers for each domain with the same base DN. Will this break anything?
 
I guess ulitmately the question is, how do you added multiple domain controllers for each domain for failover?
 
Cheers
Cameron Mottus
0

Related:

Event ID 4510 — DNS Server Active Directory Integration

Event ID 4510 — DNS Server Active Directory Integration

Updated: November 13, 2007

Applies To: Windows Server 2008

You can configure the DNS Server service to use Active Directory Domain Services (AD DS) to store zone data. This makes it possible for the DNS server to rely on directory replication, which enhances security, reliability, and ease of administration.

Event Details

Product: Windows Operating System
ID: 4510
Source: Microsoft-Windows-DNS-Server-Service
Version: 6.0
Symbolic Name: DNS_EVENT_DP_FSMO_UNAVAILABLE
Message: The DNS server was unable to connect to the domain naming FSMO %1. No modifications to Directory Partitions are possible until the FSMO server is available for LDAP connections. The event data contains the error code.

Resolve
Correct the problem with the domain naming master

Determine and correct the problem that is preventing access to the server that has the domain naming operations master role (also known as flexible single master operations or FSMO):

  1. Ensure that the domain naming master is running properly.
  2. Ensure that the local DNS server can reach the the domain naming master.
  3. Ensure that directory replication is functioning properly.

For information about troubleshooting AD DS, see Active Directory Troubleshooting Topics (http://go.microsoft.com/fwlink/?LinkId=95789).

Verify

Ensure that Event IDs 4523 and 4524 are being logged and that no events in the range 4000 to 4019 appear in the Domain Name System (DNS) event log.

Related Management Information

DNS Server Active Directory Integration

DNS Infrastructure

Related:

Event ID 4401 — NPS and Domain Controller Communication

Event ID 4401 — NPS and Domain Controller Communication

Updated: December 16, 2008

Applies To: Windows Server 2008 R2

Network Policy Server (NPS) contacts domain controllers to perform authentication and authorization for connection requests received from configured RADIUS clients. If NPS cannot contact domain controllers, it cannot perform authentication and authorization, and network access authentication will fail.

Event Details

Product: Windows Operating System
ID: 4401
Source: NPS
Version: 6.1
Symbolic Name: IAS_DC_NOT_RESPONSIVE
Message: Domain controller %1 for domain %2 is not responsive. NPS switches to other DCs.

Resolve
Fix domain controller issues

To perform this procedure, you must be a member of Domain Admins.

To fix domain controller issues:

  • Wait for a domain controller to respond to NPS. One or more domain controllers might be offline due to reboots or other issues, such as hardware failure or temporary network congestion. Domain controllers might respond shortly, and NPS will switch to other domain controllers automatically.
  • If the problem is not temporary and NPS frequently has trouble contacting domain controllers to perform authentication and authorization for connection requests, add more backup domain controllers to the network. In addition, configure your network so that there are multiple paths between servers running NPS and domain controllers. If there is a network outage on one path between NPS and a domain controller, additional paths will allow the two entities to communicate.

Verify

To verify that domain controllers are available:

Review the NPS accounting data to verify that connection requests are being processed normally.

To locate the NPS accounting data:

  1. Click Start, Administrative Tools, Network Policy Server. The NPS Microsoft Management Console (MMC) opens.
  2. In the console tree, click Accounting.
  3. In the details pane, click either Configure Local File Logging or Configure SQL Server Logging to identify the folder location or data source for the log file.
  4. In Windows Explorer, browse to the log file location. Without opening the log file, make a copy of the log file, and then open the log file copy in your text editor. If domain controllers are available and NPS has received and processed connection requests, recent log file entries will appear in the file.

Related Management Information

NPS and Domain Controller Communication

Network Policy Server Infrastructure

Related:

Event ID 4402 — NPS and Domain Controller Communication

Event ID 4402 — NPS and Domain Controller Communication

Updated: December 16, 2008

Applies To: Windows Server 2008 R2

Network Policy Server (NPS) contacts domain controllers to perform authentication and authorization for connection requests received from configured RADIUS clients. If NPS cannot contact domain controllers, it cannot perform authentication and authorization, and network access authentication will fail.

Event Details

Product: Windows Operating System
ID: 4402
Source: NPS
Version: 6.1
Symbolic Name: IAS_NO_DC_AVAILABLE
Message: There is no domain controller available for domain %1.

Resolve
Fix domain controller issues

To perform this procedure, you must be a member of Domain Admins.

To fix domain controller issues:

  • Wait for a domain controller to respond to NPS. One or more domain controllers might be offline due to reboots or other issues, such as hardware failure or temporary network congestion. Domain controllers might respond shortly, and NPS will switch to other domain controllers automatically.
  • If the problem is not temporary and NPS frequently has trouble contacting domain controllers to perform authentication and authorization for connection requests, add more backup domain controllers to the network. In addition, configure your network so that there are multiple paths between servers running NPS and domain controllers. If there is a network outage on one path between NPS and a domain controller, additional paths will allow the two entities to communicate.

Verify

To verify that domain controllers are available:

Review the NPS accounting data to verify that connection requests are being processed normally.

To locate the NPS accounting data:

  1. Click Start, Administrative Tools, Network Policy Server. The NPS Microsoft Management Console (MMC) opens.
  2. In the console tree, click Accounting.
  3. In the details pane, click either Configure Local File Logging or Configure SQL Server Logging to identify the folder location or data source for the log file.
  4. In Windows Explorer, browse to the log file location. Without opening the log file, make a copy of the log file, and then open the log file copy in your text editor. If domain controllers are available and NPS has received and processed connection requests, recent log file entries will appear in the file.

Related Management Information

NPS and Domain Controller Communication

Network Policy Server Infrastructure

Related:

Event ID 2139 — Message Queuing Windows 2000 Client Support Operation

Event ID 2139 — Message Queuing Windows 2000 Client Support Operation

Updated: December 3, 2008

Applies To: Windows Server 2008 R2

You can use the Message Queuing Windows 2000 Client Support service to run Message Queuing in domain mode on Windows 2000 computers that are joined to a Windows Server 2003 domain or a Windows Server 2008 domain. This service must generate audit logs and have a global catalog to operate properly.

Event Details

Product: Windows Operating System
ID: 2139
Source: MSMQ
Version: 6.1
Symbolic Name: NOT_SURE_I_AM_A_GC
Message: Message Queuing detected a problem with the local domain controller. Until the problem is resolved, Message Queuing will function unpredictably. Using Event Viewer, inspect the directory service, File Replication service, and system logs to help identify the problem.

Resolve
Add the Message Queuing Service to a domain controller that is also running as a global catalog server

The Message Queuing Service must be installed and started on a Windows Server 2008 domain controller that is also a global catalog server.

To perform these procedures, you must have membership in Administrators, or you must have been delegated the appropriate authority.

Manually determine if the domain controller has a global catalog

To manually determine if the domain controller is a global catalog server (Windows Server 2008):

  1. Open the Active Directory Users and Computers snap-in. To open Active Directory Users and Computers, click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  2. On the View menu, enable both Users, Contacts, Groups and Computers as containers and Advanced Features.
  3. In the console tree, under Domain Controllers menu, locate your computer. Right-click your computer, and then click Properties.
  4. Click the General tab.
  5. Determine whether DC Type is Global Catalog.

    If Global Catalog appears and you continue to receive this error, note any details in the event message, and then contact Microsoft Customer Service and Support (CSS). For information about how to contact CSS, see Enterprise Support (http://go.microsoft.com/fwlink/?LinkId=52267).

Add the global catalog

If your local domain controller is not a global catalog server, contact your domain administrator to enable your domain controller to be set up as a global catalog server.

If you are the domain administrator, use the following procedure.

To add the global catalog:

  1. On the domain controller where you want the new global catalog, open the Active Directory Sites and Services snap-in. To open Active Directory Sites and Services, click Start, point to Administrative Tools, and then click Active Directory Sites and Services.
  2. In the console tree, double-click Sites, and then double-click sitename.
  3. Double-click Servers, click your domain controller, right-click NTDS Settings, and then click Properties.
  4. On the General tab, select the Global catalog check box to assign the global catalog to this server.
  5. Restart the domain controller.

Verify

Verify that the Message Queuing Windows 2000 Client Support service is installed and running.

To perform this procedure, you must have membership in Administrators, or you must have been delegated the appropriate authority.

To verify that the Message Queuing Windows 2000 Client Support service is installed and running:

  1. Open the Services snap-in. To open Services, click Start. In the search box, type services.msc, and then press ENTER.
  2. Scroll down the list of services to confirm the existence of the Message Queuing Windows 2000 Client Support service.
  3. Verify that the Message Queuing Windows 2000 Client Support service is started.
  4. For further confirmation, run a test application that uses the Active Directory features that you require.

Related Management Information

Message Queuing Windows 2000 Client Support Operation

Message Queuing

Related:

Event ID 1977 — Replication Changes

Event ID 1977 — Replication Changes

Updated: November 25, 2009

Applies To: Windows Server 2008

The replication process in Active Directory Domain Services (AD DS) ensures that domain controllers are able to maintain a consistent and updated Active Directory database. Because the Active Directory database holds essential information about user, group, and computer accounts, as well as other resources and services and the network configuration, keeping this information consistent on all the domain controllers is important. Failure of the Active Directory replication process can result in the following problems:

  • Failure of applications that rely on consistent Active Directory information to function properly
  • Logon rejections
  • Password change failures
  • Network service failures
  • Incorrect or outdated information retrieval

For more information, see How Active Directory Replication Topology Works (http://go.microsoft.com/fwlink/?LinkID=93526).

Event Details

Product: Windows Operating System
ID: 1977
Source: Microsoft-Windows-ActiveDirectory_DomainService
Version: 6.0
Symbolic Name: DIRLOG_DRA_REPLICATION_ALL_ACCESS_DENIED_DC
Message: The following directory service made a replication request for a writable directory partition that has been denied by the local directory service. The requesting directory service does not have access to a writable copy of this directory partition.
Requesting directory service: %2
Directory partition: %1
User Action
If the requesting directory service must have a writable copy of this partition, verify that the security descriptor on this directory partition has the correct configuration for the Replication Get Changes All access right. You may also get this message during the transition period after a child partition has been removed. This message will cease when knowledge of the child partition removal has replicated throughout the forest.
.

Resolve
Ensure that the security descriptors are set correctly on the directory partition

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To ensure that the security descriptor is set correctly on the directory partition:

  1. On any domain controller in the domain, open ADSI Edit. To open ADSI Edit, click Start. In Start Search, type ADSIEdit.msc, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. If the directory partition from the error message does not appear, in the console tree, right-click ADSI Edit, and then click Connect to. In Connection Point, type the Lightweight Directory Access Protocol (LDAP) path of the partition from the error message into Select or type a Distinguished Name or Naming Context (for example, DC=cpandl,DC=com), and then click OK.
  3. In the console tree, expand the object that represents the naming context of the partition from the error message. You should see another object with the LDAP path (for example, DC=cpandl,DC=com) that was identified in the event message text.
  4. Right-click the object that has the name of the LDAP path from the event message text, and then click Properties.
  5. On the Security tab, in the Group or user names box, click Enterprise Read-only Domain Controllers. If the Enterprise Read-only Domain Controllers group, or any other group that is mentioned in the following steps, does not appear in the Group or user names box, click Add. Type the name of the group, and then click OK.
  6. In Permissions for Enterprise Read-only Domain Controllers, ensure that the Allow check box is selected for the permission Replicating directory changes. If you are configuring permissions on the Schema partition, also ensure that the Allow check box is selected for the permissions Replicating Directory Changes In and Replicating directory changes all.
  7. In Group or user names, click ENTERPRISE DOMAIN CONTROLLERS.
  8. In Permissions for ENTERPRISE DOMAIN CONTROLLERS, ensure that the Allow check box is selected for the following permissions: Replicating directory changes, Replicating Directory Changes In, Replicating directory changes all, and Replication synchronization.

    If you are configuring a domain partition, proceed with the next step. If you are not configuring a domain partition, you may skip the next two steps.

  9. In the Group or user names box, click Domain Controllers.
  10. In Permissions for Domain Controllers, ensure that the Allow check box is selected for the permission Replicating directory changes all.
  11. Click OK.
  12. Close ADSI Edit.

Note: In ADSI Edit, the permission “Replicating Directory Changes All” may be missing the final letter in the word “All.” The permission Replicating Directory Changes In, should be Replicating Directory Changes In Filtered Set, as it appears correctly in other interfaces.

Verify

Perform the following tasks using the domain controller from which you want to verify that Active Directory replication is functioning properly.

To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.

To verify that Active Directory replication is functioning properly:

  1. Open a command prompt as an administrator. To open a command prompt as an administrator, click Start. In Start Search, type Command Prompt. At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  2. Run the command repadmin /showrepl. This command displays the status reports on all replication links for the domain controller. Active Directory replication is functioning properly on this domain controller if all status messages report that the last replication attempt was successful.

If there are any indications of failure or error in the status report following the last replication attempt, Active Directory replication on the domain controller is not functioning properly. If the repadmin command reports that replication was delayed for a normal reason, wait and try repadmin again in a few minutes.

Related Management Information

Replication Changes

Active Directory

Related: