Monitoring FSMO Roles
The script I created for the FSMO role-monitoring task, FSMOMonitor.wsf, is available at the Windows Scripting Solutions Web site. (Go to http://www.winnetmag.com/windowsscripting, enter InstantDoc ID 42101 in the InstantDoc ID text box, then click the 42101.zip hotlink.) Listing 2 shows an FSMOMonitor.wsf excerpt that implements the logic of the FSMO-role—monitoring technique. The logic and structure is similar to the group-monitoring code from the earlier article, so I won't repeat all the details here but will instead comment on some of the differences.
One major difference is the number of WMI Query Language (WQL) event queries the code submits. Instead of executing one such query, FSMOMonitor.wsf executes five WQL event queries (one per FSMO role). The WQL queries all have the same structure. To detect whether the examined AD object has had a change related to an FSMO role modification, the WQL event query compares the object property DS_fSMORoleOwner before the change (PreviousInstance.DS_fSMORoleOwner) with the object property DS_fSMORoleOwner after the change (TargetInstance.DS_fSMORoleOwner). Figure 1 shows the WQL event queries the script uses for the different FSMO roles.
After establishing a WMI connection, the script submits the five WQL event queries to WMI, as the code at callout B in Listing 2 shows. Note that each WQL query uses a WMI context object because the same event subroutine is used to capture all WMI events. The context is stored in a SWbemNamedValueSet object created at the beginning of the script. One SWbemNamedValueSet object is created per FSMO role, as the code at callout A in Listing 2 shows. You can get more information about the SWbemNamedValueSet object from http://msdn.microsoft.com/library/en-us/wmisdk/wmi/swbemnamedvalueset.asp. Before submitting each WQL event query, the code initializes each SWbemNamedValueSet object with a value specific to the monitored FSMO role. The subroutine that handles the WMI events has the same logic and structure as the code I used in the AD group-monitoring article except that the code first extracts the WMI context to determine which FSMO role the received event relates to, as the code at callout C in Listing 2 shows. The script then displays a message about the FSMO role that has been modified.
In the Real World
In this article and "Using WMI to Monitor AD," I've shown that by leveraging the support of the three WMI AD providers, you can monitor AD for FSMO-role and group modifications. Although Microsoft might provide a different way to perform AD monitoring in future releases, the WMI AD providers are the only interfaces available for that purpose today. You can also track user creations and deletions in the same way. Thus, you could set up a two-forest Microsoft Exchange Server environment in which the mailbox forest is provisioned (i.e., a mailbox is created) when you create a user account in the account forest. Similarly, you could configure the mailbox forest to be deprovisioned (i.e., the mailbox deleted) when you delete a user account from the account forest. This setup requires more WMI and ADSI coding, but the two code samples I discussed in these two articles could serve as the foundation of this two-forest provisioning and deprovisioning script. Now the sky and your imagination are the limits! To your keyboards