In my first article about using Windows Management Instrumentation (WMI) to monitor data in Active Directory (AD), I discussed three new WMI providers that let you monitor AD group modifications. I explained how WMI represents AD information (see "Using WMI to Monitor AD," April 2004, InstantDoc ID 41835), and I presented a scripting technique to monitor AD groups. In this article, I leverage that information to create a way to monitor modifications made to the five Flexible Single-Master Operation (FSMO) roles so that administrators can be notified when someone moves one of the five FSMO roles from one server to another.
Accessing FSMO Role Information
The FSMO roles are the five crucial roles that one or more AD domain controllers (DCs) perform. For more information about FSMO roles, see "Determining Operations Masters in a Win2K Forest and Domain," February 2002, InstantDoc ID 23403.
The logic and coding techniques for monitoring the FSMO roles are similar to those I describe in the earlier article about monitoring AD groups, except that accessing the FSMO information isn't as straightforward as accessing the AD group information. To access the FSMO role information, you must concurrently access the three AD naming contexts (NCs), which requires a specific WMI setup at the level of the root\directory\LDAP namespace. By default, AD providers access AD information in the default NC, which is the Windows domain in which the accessed DC resides. However, the attributes containing the FSMO information are spread among all three AD NCs, so to monitor all FSMO roles, you must access the configuration and schema NCs too.
Table 1 lists the FSMO roles, their respective NC locations, and other important information about them. Each of the FSMO roles is stored in a different AD object class, whose WMI form appears in the WMI Class column in Table 1. The FSMO role is always stored in an attribute called fSMORoleOwner, which corresponds to a WMI property called ds_fSMORoleOwner. For those who prefer Active Directory Service Interfaces (ADSI) programming to WMI programming, the TechNet script at http://www.microsoft.com/technet/community/scriptcenter/compmgmt/scrcm24.mspx illustrates how to use ADSI to retrieve the FSMO information by accessing the Lightweight Directory Access Protocol (LDAP) objects listed in the AD Object DN column in Table 1. The TechNet script first retrieves the Schema Master FSMO role, then the Domain Naming Master, the PDC Emulator, the RID Master, and finally the Infrastructure Master. If you look at this code, you'll see that all FSMO roles are contained in an attribute called fSMORoleOwner, which contains the distinguished name (DN) of the DC that hosts these FSMO roles. This DN changes when someone has moved the FSMO to another DC. Thus, to detect an FSMO role modification, you simply have to monitor for DN changes contained in the FSMORoleOwner attribute. You can access the same information that the TechNet script does by using WMI; the challenge resides in accessing the configuration and schema NCs, which contain, respectively, the Domain Naming Master role (i.e., the LDAP crossRefContainer object) and the Schema Master role (i.e., the LDAP dMD object).
To enable WMI to access the crossRefContainer LDAP object in the configuration NC and the dMD LDAP object in the schema NC, you must first create an instance of the DN_Class and DSClass_To_DNInstance WMI classes in the root\directory\LDAP namespace. The DN_Class class encapsulates the DN of the NC that contains the FSMO role. The DSClass_To_DNInstance class associates a WMI class that represents the object that you want to find in an AD NC with an instance of that NC.
You can create these class instances by using a Managed Object Format (MOF—
the native WMI file format for classes and class instances in the WMI repository) file, which the code in Listing 1 shows. As the code at callout A in Listing 1 shows, to locate a WMI ds_crossRefContainer instance in the configuration NC, you first create an instance of DN_Class that defines the NC, then you create an instance of DSClass_To_DNInstance and initialize its properties as follows:
- The DSClass property is assigned the ds_crossRefContainer class instance name.
- The RootDNForSearchAndQuery property is assigned the WMI path of the WMI instance that represents the configuration NC. The instance that represents the configuration NC is created from the DN_Class class described earlier.
As the code at callout B in Listing 1 shows, the MOF file uses the same creation and initialization process for the ds_dMD class, whose instance is in the AD schema NC.
Before you can monitor the FSMO roles, you need to load the MOF file into the Common Information Model (CIM) repository, which you can do by using WMI's MofComp utility. MofComp parses a file that contains MOF statements and adds the classes and class instances defined in the file to the CIM repository. To load the code that Listing 1 shows into the CIM repository, type the following command:
MofComp ForestFSMO.mof
Note that you don't have to specify the WMI namespace root\directory\LDAP in the command line to load the MOF file definition into the right location of the CIM repository. The MOF file explicitly defines the namespace, as the #pragma namespace command in Listing 1 shows, so the namespace is optional on the command line.