Monitoring Active Directory (AD) replication is a crucial management activity, especially in large enterprise environments that have many servers and a complex replication topology. AD administrators often need to use different tools or UIs (e.g., Replmon, Repadmin, the Microsoft Management Console—MMC—Active Directory Sites and Services snap-in) to manage replication between various AD servers. A bridgehead server or other important AD server disappearing from the network because of network connection problems or a domain controller (DC) crash can seriously affect the replication topology. In this case, you might need to force a Knowledge Consistency Checker (KCC) execution to recalculate the replication topology. In some situations or environments, you might need to automate some typical AD management operations such as the KCC execution or force the replication of a specific naming context (NC) in response to some event. In Windows 2000 Server, these types of tasks are almost impossible to automate in a custom application without calling some specific AD Win32 APIs. However, Windows Server 2003 includes an AD replication Windows Management Instrumentation (WMI) provider that abstracts some KCC execution and replication APIs, simplifying some management operations. Let's take a look at the new AD replication WMI provider and its classes.
The AD Replication WMI Classes
The AD replication provider and its classes, which reside in the root\MicrosoftActiveDirectory namespace of the Common Information Model (CIM) repository, let you trigger KCC actions and retrieve AD replication information. Web Table 1 (http://www.winnetmag.com/windowsscripting, InstantDoc ID 40881) lists the classes and their properties. You can explore the root\MicrosoftActiveDirectory namespace and its set of classes by using CIM Studio, which is available at http://download.microsoft.com/download/.netstandardserver/install/v1.1/nt5xp/en-us/wmitools.exe. You can write a script that uses a WMI Query Language (WQL) query to gather AD replication information from these classes or to watch for AD replication events to occur.
For example, you can use the GenericEventAsyncConsumer.wsf script to submit the WQL query
Select * From
__InstanceModificationEvent
Within 10 Where
TargetInstance ISA
'MSAD_DomainController'
to poll a DC every 10 seconds for any modifications to that DC. MSAD_DomainController is an AD replication class that exposes DC properties. GenericEventAsyncConsumer.wsf is a script that I wrote to watch for any type of event monitoring specified by a WQL event query. For more information about how GenericEventAsyncConsumer.wsf submits an event query, see "Exchange 2000 SP2 WMI Updates," January 2003, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 27211.
Figure 1 shows partial output from running GenericEventAsyncConsumer.wsf with the WQL query above. At callout A, you can see that the DC isn't registered in DNS; at callout B, it's registered.
If you want to try using the script with the WQL event query to catch DC events in your environment, run the code on a local DC under any security context. (If you want to access the DC remotely, you must use an administrator security context because, by default, WMI grants remote access only to administrators.) While the script is running, force a change in the DNS registration state by deleting the DC's A record in your DNS. WMI will detect that the DC isn't registered in the DNS and send a notification to the script. The script will then display output that shows the DNS registration change.