Monitoring Exchange 2007 SCR with Ops Mgr 2007
I was a bit surprised to see that the most recent Management Pack for Exchange Server 2007 for Operations Manager 2007 didn’t understand the differences between CCR and SCR…and how those differences would impact the log queue depths for replication. So, if you’re going to implement SCR (or you already did), be sure to override the thresholds for the following monitors for your SCR targets:
- MSExchange Replication: ReplayQueueLength - sustained for 5 minutes - Red(>15)
- MSExchange Replication: ReplayQueueLength - sustained for 5 minutes - Yellow(>7).
Since the replay queue length is always going to be rather large due to the nature of how SCR operates (this value will never be less than 50 logs and will almost always be more than that), you’ll need to determine what the normal values of the replay queue depth are for your SCR targets. As an example, I have two SCR targets (from CCR sources) that routinely have replay queue depths of 300 - 400 logs with just a 1 hour ReplayLagTime value configured! See this TechNet article for more information configuring SCR.
I’d suggest making your “yellow” value at least 100 above your normal average replay queue depth and your “red” value at least 250 - 350 above your normal average. Make your overrides on the specific mailbox servers that are your SCR targets…not at the global level.
Ops Mgr DNS Management Pack updated
The DNS Management Pack for Operations Manager 2007 has been updated again to version 6.0.6480.0, but it still doesn’t seem to fix the the major complaint with the previous version (6.0.6278.27).
The DNS Library WINS TTL Monitor, despite getting some updated verbiage in the MP Guide, still appears to be broken. The guidance now specifically mentions that you need to create an A record in DNS, and provides some override information. No matter though, even with creating the A record “placeholder” in the forward lookup zone that corresponds to the domain name of the Ops Mgr management server (i.e. placeholder.mydomain.local), the alert still comes in. Refer back to my previous post about that item. So…this monitor gets overridden again.
Terminal Services Self-Tuning Monitors, Part 2
As a follow-up to my earlier entry about tuning STT monitors, specifically for Terminal Services…
Either our Terminal Services environment is really, really, really out of the normal (a little bit due to our applications in use, but not excessively so…) or the STT monitor for TS sessions (active and inactive) just plain doesn’t work.
Bottom line, I’ve disabled both monitors after attempting to find an override point for three weeks in a row that would give valid data. No matter what set of thresholds are chosen, like clockwork, at the end of 7 days all of the terminal servers start to issue alerts. I’m marking this one as a bug and hoping for an updated MP in the near future for Terminal Services.
Anyone else have similar experiences?
AD_Client_Update_DCs.vbs script too few parameters
So I’ve been trying to figure out for a while now why the AD_Client_Update_DCs.vbs script keeps failing on the forest root domain controllers in our forest. This is a different domain, as design would dictate, from where our “resources” are, including the Operations Manager RMS. The error being reported is not entirely the most helpful, exit code -1.
Source: server.local
Path: server.local
Alert: Script or Executable Failed to run Resolution state: New
Priority: 1
Severity: 1Last modified by: System
Last modified time: 6/18/2008 1:30:24 PM Alert description: The Event Policy for the process started at 1:29:57 PM has detected errors in the output. The ‘ExitCode’ policy expression:
[^0]+
matched the following output:
-1Command executed: “C:\WINDOWS\system32\cscript.exe” /nologo “AD_Client_Update_DCs.vbs” server.local DOMAIN false 3 {F4D1BF44-45E9-6888-326D-DDBF6546C9C5}
Working Directory: C:\Program Files\System Center Operations Manager 2007\Health Service State\Monitoring Host Temporary Files 1\227\One or more workflows were affected by this.
Workflow name: AD_Client_Update_DCs
Instance name: AD Client Monitoring
Instance ID: {9A988BEB-A276-449E-710F-35821C015070}
Management group: SysCtrOpsMgr
Alert view link: “xxx”
Notification subscription ID generating this message: {xxx}
When I debugged the script, I found out why it’s failing to run immediately…there are only five parameters being passed to the script and six are required for the script to run successfully.
“C:\WINDOWS\system32\cscript.exe” /nologo “AD_Client_Update_DCs.vbs” server.local DOMAIN false 3 {F4D1BF44-45E9-6888-326D-DDBF6546C9C5}
Dim oParams, TargetFQDNComputer, TargetNetbiosDomain, bLogSuccessEvent, IsTargetAgentless, oAPI
Set oParams = WScript.Arguments
if oParams.Count < 6 then
Wscript.Quit -1
End if
The first five parameters are correct, and are target fully qualified server name, target NetBIOS domain name, logging on/off for successful completions (off here), DC discovery scope (DCs in same site) and the GUID of the Registry key that contains all of the AD Management Pack scripting information. The missing parameter is either an array of domain controllers or AD sites based on the script.
‘ Read the list of domain controllers and store them in the array
astrDCs = LoadDCsFromConfiguration()
If Err <> 0 Then
ScriptError “loading the Domain Controllers from the configuration file.”
End If
‘ Only use the domain controllers from the script parameters if there weren’t any
‘ loaded from the configuration file
If IsEmpty(astrDCs) Then
strDomainControllers = oParams(5) ‘DomainControllers
astrDCs = LoadDCsFromString(strDomainControllers)
If Err <> 0 Then
ScriptError “loading the Domain Controllers from the script parameter ” & _
“‘DomainControllers’.”
End If
End If‘ Read the list of sites from the configuration file and put them in
‘ a string (comma delimited)
strSites = LoadSitesFromConfiguration()
If 0 = Len(strSites) Then
If 2 = iMode Then
‘ Only use the list of sites from the script parameters if there
‘ were no sites specified by the configuration file.
strSites = oParams(6)’Sites
The problem is that neither paramter six or seven are being passed to the script and further the Registry location referecned DOES NOT contain any of the information that script would need. Of course, that seems irrelevant since the script is terminating with error code -1 before it even gets to the functions to read configuration data out of the registry. So the question I was trying to answer is WHY if the script requires six parameters passed to it at invocation are only five parameters being passed to it? Machines never make mistakes, right?
The issue has been compounded by the fact that this is only happening on the DCs in the forest root domain, and not in the child domain where the RMS lives. I thought perhaps this was a permissions issue then? Not that I can tell, as the Action Account for the AD MP has all the permissions it needs on the Registry keys.
Using Boris’ MP Viewer to examine the AD Client Update DCs rule in the AD MP v6.0.6278.6 let me in what exactly Ops Mgr is passing to the script (we already knew that from the error, but independant verification is cool). The default configuration settings can be found in the Knowledge section of the rule, the raw XML is easier to read in the MP Viewer IMO.
Configuration settings:
- Interval (sec) default 86400 (1 day)
- SiteDiscoveryMode: default 3: Settings: 1 - All DCs in Domains (comma delimited); 2 - All DCs in specified sites; 3 - Only DCs in Local Site; 4 - Only Specified DCs.
- Sites (default blank): The sites (comma delimited) to be monitored (only relevant when SiteDiscoveryMode is 2).
- DomainControllers (default blank) - The domain controllers to be monitored explicitly (Used in all modes).
- <Rule ID=”AD_Client_Update_DCs” Enabled=”onStandardMonitoring” Target=”AD!Microsoft.Windows.Server.AD.ClientPerspective” ConfirmDelivery=”false” Remotable=”false” Priority=”Normal” DiscardLevel=”100″>
<Category>EventCollection</Category>
- <DataSources>
- <DataSource ID=”DS” TypeID=”AD_Client_Update_DCs.DataSource”>
<IntervalSeconds>86400</IntervalSeconds>
</DataSource>
</DataSources>
- <WriteActions>
- <WriteAction ID=”WA” TypeID=”AD_Client_Update_DCs.WriteAction”>
<TargetComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</TargetComputerName>
<TargetNetbiosDomain>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosDomainName$</TargetNetbiosDomain>
<LogSuccessEvent>false</LogSuccessEvent>
<SiteDiscoveryMode>3</SiteDiscoveryMode>
<DomainControllers />
<Sites />
<ManagementGroupName>$Target/ManagementGroup/Id$</ManagementGroupName>
<TimeoutSeconds>120</TimeoutSeconds>
</WriteAction>
</WriteActions>
</Rule>
Since the Domain Controller list is passed as oParams(5), the sixth parameter, that’s where the override needed to be made. I entered in the FQDN of one of my DCs in the forest root domain (although any DC in the site would have done). I also opted to override logging so that success events would be logged as well…positive confirmation the script was in fact running.
The script is now working fine on all DCs…
Does anyone else have any other suggestions or insights into this one? Is there a better way that I should have used to correct this issue?
-
Translator
