AD MP – AD Trust Monitoring BUG


A few days ago a colleague of mine complains that after fixing a problem with a trust relationship between 2 domains, OpsMgr continued to show an alert in console even if the trust has been repaired. I told him to check if the alert was created by a monitor or by a rule, in case of a rule I told him simply to close it, in case of a monitor I told him to wait a couple of hours because I know that many OpsMgr monitors are scheduled, and the state change, isn’t immediate.  After waiting one day, my colleague come back in my office and told me that the alert comes from a monitor and that nothing changed, the alert didn’t disappear form the console. I decided it was time to investigate.

First of all I retrieved the name of the monitor from the alert to check the it’s configuration :

image

The monitor is named “AD Trust Monitoring” and generates an alert named “A problem with the inter-domain trusts has been detected”.

I verified that the monitor is configured to auto resolve the alert when the monitor returns to a healthy state and that no override exists to change this behavior.

image

So I supposed that even the Health State of the monitor should be unhealthy. Confirmed :

image

After those check it was time to look inside the MP to verify how the monitor checks the status of the trust. The monitor uses a scheduled script datasource named “AD_Monitor_Trusts.DataSource” that connects to wmi namesapce “root\MicrosoftActiveDirectory” and queries Instances of class Microsoft_DomainTrustStatus  :

Set oAllTrusts = GetObject("winmgmts:\" & strComputer & "\root\MicrosoftActiveDirectory").InstancesOf("Microsoft_DomainTrustStatus")
If 0 <> Err Then
    bLogSuccess = False
    ScriptError "failed to get all the trusts for this DC." & GetErrorString(Err)
Else
    For Each oTrust in oAllTrusts
        If ((oTrust.TrustType = 1) Or (oTrust.TrustType = 2)) And (oTrust.TrustStatus <> 0) And ((oTrust.TrustStatus <> 1786) Or Not bIsRODC) Then
            strTrustErrors = strTrustErrors & FormatTrust(oTrust) & ", the error is:" & vbCrLf & _
                oTrust.TrustStatusString & " (0x" & Hex(oTrust.TrustStatus) & ")" & vbCrLf
        End If
    Next
End If

The script checks the TrustStatus returned by the query. If a trust of type 1 or 2 has a TrustStatus not equal to 0, the variable strTrustErrors is populated with the string representation of the error (the expression ((oTrust.TrustStatus <> 1786) Or Not bIsRODC) is always true in the AD 2003 MP because bIsRODC is always false).

If the length of the variable strTrustErrors is greater than 0 a BAD state is returned by the datasource :

If Len(strTrustErrors) > 0 Then
          Set oBag = oAPI.CreateTypedPropertyBag(StateDataType)
          oBag.AddValue "State", "BAD"

This is confirmed by the documentation published by microsoft Trust Monitoring.

I used the utility wbemtest.exe to connect to the same namespace and to execute the same query, every trusts returned had a TrustStatus equal to 0, so it should not return a BAD state. Since the script could not return a  “BAD” state I checked the UnitMonitorType AD_Monitor_Trusts.Monitortype to see when the monitor health is evaluated as Healthy. I found a condition detection that filter the output of the script, if the state returned by the script contains a substring “GOOD” the monitor returns an healthy state.

<ConditionDetection ID="FilterOK" TypeID="System!System.ExpressionFilter">
  <Expression>
    <RegExExpression>
      <ValueExpression>
        <XPathQuery>Property[@Name='State']</XPathQuery>
      </ValueExpression>
      <Operator>ContainsSubstring</Operator>
      <Pattern>GOOD</Pattern>
    </RegExExpression>
  </Expression>
</ConditionDetection>

<RegularDetection MonitorTypeStateID="TrustsOK">
  <Node ID="FilterOK">
    <Node ID="ScriptDS" />
  </Node>
</RegularDetection>

The last thing to check was when the script returns a GOOD state :

If bLogSuccess Then
  Set oBag = oAPI.CreateTypedPropertyBag(StateDataType)
  oBag.AddValue "State", "GOOD"

Here I found the problem, the “GOOD” state is returned only if the variable bLogSuccess is true. This variable is passed to the script as the 3rd argument :

bLogSuccess = CBool(oParams(2))

and is taken form the monitor configuration :

<CommandLine>//nologo $file/AD_Monitor_Trusts.vbs$ $Config/TargetComputerName$ false $Config/LogSuccessEvent$</CommandLine>

image

As you can see in the previous image, the default value of LogSuccessEvent in this monitor is False. With the default configuration the script never return a “GOOD” state and the state of the monitor never returns healthy unless you reset it manually.

After the creation of the override the alert disappeared form the console and the state returned healthy. To fix the problem you can override the value as I did to have the monitor behave as expected.

– Fabrizio

This posting is provided "AS IS" with no warranties, and confers no rights.

About these ads

,

  1. #1 by Ahmed on March 29, 2010 - 9:08 am

    i have this problem and i did over ride the LogSuccessEvent Monitor but still the state is falpping between OK and BAD, please help

    • #2 by Daniele Grandini on March 31, 2010 - 9:12 am

      Hi Ahmed,
      the flip flop behavior has nothing to do with the fix described in our post. To understand why your monitor is flip flopping you should check with wbemtest or cim studio as explained in the article. It can be the case your trusts are ahaing real issues, maybe caused by unreliable links between the forests/domains.
      – Daniele

  2. #3 by Daniele Muscetta on February 13, 2010 - 1:01 pm

    I believe there is a bug filed for this… the workaround was also already blogged by Jimmy http://blogs.technet.com/jimmyharper/archive/2009/05/20/ad-trust-monitor-doesn-t-reset-to-healthy-state.aspx

  3. #4 by John Bradsahw on January 4, 2010 - 4:09 am

    Thx mate. Nice work on this one!!
    John Bradshaw

  4. #5 by marcus oh on October 6, 2009 - 7:57 pm

    ran into this as well. we decided to change the state manually since the cost of having to log success events constantly wasn’t something we wanted to endure.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 328 other followers

%d bloggers like this: