MOM Scripts – AD Client GC Availability

This script, available in the Exchange Management Pack for MOM 2005, attempts to contact all the configured GCs and generates alerts if either there are not enough GCs configured, or if not enough GCs are contactable.  You can easily discover how this script functions by opening it's properties from the following path in the MOM 2005 Administrator Console.

//Microsoft Operations Manager/Management Packs/Scripts/AD Client GC Availability

I have discovered that in federated environments, this script can bring with it some problems, particularly if you have the multi-domain forest, where each domain is owned by a different department, and each department has firewalls between themselves and the larger community.  Specifically, you may see the following error in the event log.

Event Type: Warning
Event Source: Microsoft Operations Manager
Event Category: MOM Server
Event ID: 21421
Date:  8/9/2006
Time:  2:46:25 PM
Computer: [Computer Name]
The response 'agent management' has been running more than 300 seconds and exceeded the time allowed to run. This might indicate the response is engaged in an infinite loop or is hanging.
Management Group: [Name of Management Group]

By default, this script runs every five minutes, which is way the error says running more than 300 seconds.  If you were to call support on this problem, they would likely ask that you first change the frequency to run every 30 minutes at :06 minutes after the interval (12:06 and 12:36 for example).  If you follow this advice, and wait a few hours, you may discover that the event description now says that the job's been running for 1800 seconds (30 minutes).  This actually indicates that you have a problem with the script itself.

MOM Scripts can be edited, so long as you take the time to understand exactly what they do.  I generally recommend dissecting the script down to its lowest common denominator, running it live, and then making the appropriate adjustments.  For this particular scenario, we needed to adjust the GC Client Availability script so that it would only attempt to communicate with global catalog servers in a particular domain (because other domains were blocked for non-GC replication access).  The first step was to determine whether this script was trying to access remote GCs, even though that seemed obvious from its 30 minute timeout.  The following lines were pulled from the production script and loaded into a test environment.  My comments are added to the code to aid in understanding.

'Connect to the RootDSE from a local GC (notice it doesn't use LDAP)
Dim oRootDSE
Set oRootDSE = GetObject("GC://RootDSE")

' Now query the root DSE to get the site of the DC
Dim strSite, strServerName, strDNSHostName, strConfigNamingContext
strServerName = oRootDSE.Get("ServerName")
strDNSHostName = oRootDSE.Get("DNSHostName")
strConfigNamingContext = oRootDSE.Get("ConfigurationNamingContext")

'Set up and ADO connection to AD
Dim oADOConn
Set oADOConn = CreateObject("ADODB.Connection")
oADOConn.Provider = "ADSDsOObject"
oADOConn.Open "ADs Provider"

Dim rsGCs, strQuery
strQuery = "<LDAP://" & strDNSHostName & "/CN=Sites," & strConfigNamingContext & ">;(&(objectCategory=nTDSDSA)(options:1.2.840.113556.1.4.803:=1));adspath,cn;subtree"

'Execute the query and loop through the results
Set rsGCs = oADOConn.Execute(strQuery)
Do While NOT rsGCs.EOF
 Wscript.Echo rsGCs(0)

From this, we could determine that the script was looking not at what Exchange had configured for DS Access in its server properties, but rather from a list of all GCs across all sites in the forest.  To allow this script to work in our environment, we needed to limit the script to only process (test) those GCs belonging to the agency domain.  Fortunately, all GCs started with the same prefix (we'll use DOA for demonstration purposes).  To edit the script, we made the following changes in the code:


If IsObject(oNTDSASettings) Then
 Dim oServer
 Set oServer = GetObject(oNTDSASettings.Parent)
 If 0 <> Err Then
  ScriptError "getting the object: '" & oNTDSASettings.Parent & "'."
  Dim strGCDNSHostName
  strGCDNSHostName = oServer.Get("DNSHostName")
  strGCs = strGCs & strGCDNSHostName & vbCrLf

  '[Added Line]
  If UCASE(LEFT(strGCDNSHostName, 3)) = "DOA"
   Dim oGC
   Set oGC = GetObject("GC://" & strGCDNSHostName & "/RootDSE")
   If 0 <> Err Then
    strUnavailableGCs = strUnavailableGCs & strGCDNSHostName & vbCrLf
    ' Attempt to retrieve a property from the object (to force ADSI
    ' to actually connect).

   End If
  End If 'Added Line to Close Out our IF statement
 End If
End If

After making the change, we saved the script in the MOM console, and propogated the changes.  The result: our errors stopped, though I would imagine it might be some time before I can full assess the success (need time to collect data).

Please heed the following warnings before you try this on your own:

  1. Changes made to management pack scripts may be overwritten if you reapply the original management pack, or upgrade it.  Always save copies of both the original and the change in txt files for future comparitive purposes.

  2. Never make changes to MP scripts without thoroughly testing them.

  3. Never take the advice of a blogger on specific changes to code.  While the code I wrote for this one customer may have been successful, your results may vary.

  4. If possible, work with Microsoft Premier Support to determine whether a script must be edited and have someone within support validate your changes.  While this won't protect you from #1, it will at least ensure that you have a supportable solution.


Comments (1)

  1. marcus says:

    curious… how does the ‘agent management’ response relate to the gc availability?  i’m trying to track down why i see this occur at 2am every day…

Skip to main content