Active Directory Synchronisatie probleem

Troubles en solutions for a, time Jump and lingering-objects in a Windows 2008 AD with W2k8R2 and higher member servers, including W2k12. In the domain is a atom clock connected to the DC1 and recently the W2k3 Exchange server was replaced by W2K10 on W2K8R2. ==>

Lingering objects Tutorial

Hieronder is wat we hebben gedaan. / This is what we did:

Register in DNS

If you have been working with Windows for a while, then I am sure that you know that the Active Directory is completely dependent on the DNS services, and that every host on your network requires a Host (A) record on the organization’s DNS server. What a lot of people do not realize though, is that when you create the first domain in a forest, there are some domain specific DNS records that are created within a folder named DomainDnsZones. This folder is located within the Forward Lookup Zones in your domain folder.

The DomainDnsZones folder mains records for each domain controller. Without these records, other servers on the network will not be able to locate the domain controller’s directory resources. It is therefore essential that each domain controller be able to register itself within the DNS. This is where the Register in DNS test comes into play. This test verifies that the domain controller is able to register a directory server locator record

You can perform the Register in DNS test by entering the following command:

DCDIAG /Test:RegisterInDns /DnsDomain:

For example, if your domain were named Contoso.com, the command would look like this:

DCDIAG /Test:RegisterInDns /DnsDomain:Contoso.com

Replications

As I am sure you know, Windows 2000 Server and every subsequent version of Windows Server use a multimaster domain model. This means that each domain controller has its own copy of the Active Directory database, and updates can be made directly to any of these copies. When an update is made to the Active Directory database, the update is then replicated to the other domain controllers.

The Replications test checks to make sure that these updates are occurring in a timely manner. If there is excessive latency in the update process, then domain controllers will remain out of sync for an extended period of time, and there is a greater potential for conflicts to occur.

You can perform the Replications test by entering the following command:

DCDIAG /TEST:Replications

RID Manager

Any time that you create a new Active Directory object, such as a user or a group, Windows assigns it a unique Security Identifier (SID). That SID is made up of a domain SID that is common for all objects within a domain, and a relative identifier (RID) that is unique within the domain. The RID master provides each domain controller within a domain a pool of RIDs that it can use when new objects are created. When the pool nears depletion, the domain controller issues a request to the RID master for additional RIDs. If the domain controller is unable to contact the RID Master, then no additional objects will be able to be created on that domain controller once the pool of RIDs has been exhausted.

The RID Manager test allows you to verify that a domain controller can identify and contact the RID Master, and that the RID Master contains the appropriate information. You can run this test by entering the following command:

DCDIAG /Test:RidManager

Services

In Windows Server 2008, the Active Directory is now listed as a service within the Service Control Manager. As you might have guessed, the Active Directory is a bit more complex than it initially appears. The Active Directory Domain Service has a number of dependency services, some of which include the DNS Server (if it is present on the server), Kerberos Key Distribution Center, Intersite Messaging, and the File Replication Service.

You can use the Services test to make sure that the Active Directory Domain Service and all of its supporting services are running. To do so, issue this command:

DCDIAG /Test:Services

System Log

According to Microsoft’s documentation, the System Log test examines the system to make sure that no errors are being generated. This makes it sound as though this test parses the System event log looking for errors. Perhaps on some level it does, but that isn’t what appears to happen when you actually perform the test.

When you run the system log test, the Domain Controller Diagnostic Utility begins by identifying the home server and the Active Directory forest. It then performs a connectivity test, a system log test (which I can only assume looks for critical events in the system log), and a series of partition tests on various Active Directory Partitions (ForestDnsZones, DomainDnsZones, Schema, Configuration, etc.)

You can run the System Log test by entering the following command:

DCDIAG /Test:SystemLog

Topology

Windows Server uses something called the Directory System Agent (DSA) to provide access to the data store. The Directory Service Agent is made up of various services and processes that facilitate that access. The DSA is a part of the Local System Authority subsystem, and is typically accessed through the LDAP protocol.

When multiple domain controllers are in use, each domain controller must have topology information that links it to other DSAs. The Topology test validates that the topology that Windows has generated is fully connected for all DSAs.

One important thing to know about the Topology test is that it is one of the few tests that is not run by default. It must be manually executed. You can perform this test by entering the following command:

DCDIAG /Test:Topology

Verify References

The Verify References test makes sure that the system references required by the File Replication Service and that the general replication infrastructure are intact. You can perform this test by entering the following command:

DCDIAG /Test:VerifyReferences

Verify Enterprise References

The Verify Enterprise References test is very similar to the Verify References test that I just discussed. Like the Verify References test, the Verify Enterprise References test checks to make sure that references required by the File Replication Service and that the general replication infrastructure are intact. What makes this command different from the Verify References command is that it checks file replication service references and the general replication infrastructure across all of the domain controllers in the entire enterprise.

This is another one of those tests that are not run by default. You can perform this test by entering the following command:

DCDIAG /Test:VerifyEnterpriseReferences

Verify Replicas

The Verify Replicas test is another test that is not run by default, and must be manually executed. The basic idea behind this test is that Windows allows you to create application directory partitions, and those partitions can be replicated to other servers. The test allows you to make sure that all of the replica servers contain the appropriate replicas. You can perform this test by entering the following command:

DCDIAG /Test:VerifyReplicas

Conclusion

As you can see, the Domain Controller Diagnostic Utility is capable of performing numerous tests. In my opinion, DCDIAG is one of the most underrated diagnostic tools that Microsoft has ever created.

Uitgevoerd op de ServerDC2;

Set “Allow replication with divergent and corrupt partner = 1”

After any lingering objects are removed, disable the time-based replication quarantine:

Registry method

Registry path: hklmsystemccsservicesntdsparameters
Registry setting: Allow replication with divergent and corrupt partner Registry value: 0 = disallow, 1 = allow

ServerDC1 becdf6e7-yyyy-xxxx-9f6a-c1187127add6

ServerDC2 06do8b1c-xxxx-yyyy-9cb5-93c7f45aa633

Het onderstaande werkt;

Repadmin /removelingeringobjects ServerDC1 becdf6e7-yyyy-xxxx-9f6a-c1187127add6 “dc=intranet,dc=lan” /Advisory_Mode

Vervolgens zonder “/Advisory_Mode”

Repadmin /removelingeringobjects ServerDC1 becdf6e7-yyyy-xxxx-9f6a-c1187127add6 “dc=intranet,dc=lan”

Nog onderzocht wordt waarom onderstaande “time jump” heeft plaatsgevonden: