Log collection for Active Directory Replication issues
Active directory is multi-master i.e. all DCs in a domain (except for the RODCs in Windows 2008) hold a writable copy of the Active Directory database and can accept creation and modification request for objects in AD.
Active directory database (AD objects like users, computers, containers etc.) are replicated between DCs in domain/forest, so that..
- All DCs have the same view of the database.
- All DCs can authenticate data, respond to ldap queries/searches/modification etc. therefore load balancing the request is some manner.
- The Active directory data is available even if 1 DC is offline because the Additional DC will service most of the request.
Active Directory data takes the form of objects that have properties, or attributes. The values of the attributes define the object, and a change to a value of an attribute must be transferred from the domain controller on which the addition or modification occurs, to every other domain controller that stores a replica of that object.
Smallest unit of replication = Objects attribute value or a single value in a multi-valued attribute (2003 forest level onwards)
The objects in active directory are grouped in separate directory partition for Replication purpose.
- Schema Partition: Only one schema partition exists per forest. The schema partition is stored on all domain controllers in a forest, hence replicated to all. The schema partition contains definitions of all objects and attributes that you can create in the directory, and the rules for creating and manipulating them.
- Configuration Partition: There is only one configuration partition per forest. Second on all domain controllers in a forest, the configuration partition contains information about the forest-wide active directory structure including what domains and sites exist, which domain controllers exist in each forest, and which services are available. Configuration information is replicated to all domain controllers in a forest.
- Domain Partition: Many domain partitions can exist per forest. Domain partitions are stored on each domain controller in a given domain. A domain partition contains information about users, groups, computers and organizational units. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the global catalog with only a subset of their attribute values.
- Application Partition: Application partitions store information about application in Active Directory. Each application determines how it stores, categorizes, and uses application specific information.
Examples of application partition
- ForestDNSZones is part of a forest. All domain controllers and DNS servers in a forest receive a replica of this partition. A forest-wide application partition stores the forest zone data.
- DomainDNSZones is unique for each domain. All domain controllers that are DNS servers in that domain receive a replica of this partition. The application partitions store the domain DNS zone in the DomainDNSZones<domain name>.
Information used by DCs to track AD changes to be replicated and resolve replication conflicts.
- Originating TimeStamp
- Originating DSA (invocation ID)
**The above info is maintained at attribute level.
For details on how AD replication works, refer to the article below:
How the Active Directory Replication Model Works
AD replication usually does not require a lot of maintenance, provided the following stuff is in place:
- DNS name resolution.
- Network connectivity between domains.
- Mutual authentication.
- Proper disaster recovery methods followed.
But with any of the above missing, the AD replication between DCs may fail. Below are a few symptoms that maybe caused due to AD replication issues:
- User unable to logon with newly changed password.
- User getting locked out after password changes.
- Unable to logon to Application server/fileserver because the secure channel of the file server broken with the DCs.
- Creation of objects and modification made to objects not in sync across the domain, affecting application like Exchange.
- Inconsistency in name resolution, if the DNS zones are AD integrated.
- Group policy related changes may not apply to a set of computers/users.
- DFSR/FRS configuration changes may not be effective on all members.
So in scenarios where you suspect or know that the AD replication is broken in your environment, I suggest you collect the following logs. These logs will not only give you more information about the issue but will also help a 'Support Engineer' in case you create a case for the same with Microsoft Support.
- From a PDC or a DC in hub site which has connectivity with most of the DCs in forest, collect the following information:
- Repadmin /showrepl * /csv > Replication_summary.csv
- Dnslint /ad /s localhost /v /r DNSlint-AD
**collect Replication_summary.csv (to be reviewed using Ms Excel) and DNSlint-AD.htm
Sample ‘Repadmin /showrepl * /csv’ output
Sample ‘dnslint /ad /s localhost /v /r’ output.
- In case you know the problem DCs
- Dciag /v > dcname_dcdiag.txt
- ‘Directory Service’ event logs. I prefer if it’s saved in CSV format.
- For issues like Lingering objects, apart from the above logs you can also collect the following events from all DCs in domain, using tools like eventcombmt.exe
- Event IDs to search for 1988, 1388, 2042.
How to use the EventCombMT utility to search event logs for account lockouts
Below are a few articles that may help you understand and troubleshoot AD replication issues.
Troubleshooting Active Directory Replication Problems
Troubleshooting “RPC server is unavailable” error, reported in failing AD replication scenario.
- Abizer Hazrat