Granting permissions on Event Logs

I was asked a few days ago by our application developers to grant them read-only access to the Application logs on a couple of Web servers. Some of their Web applications write custom entries to the Application log, and they wanted to be able to connect to the Web servers via Computer Management and see those log entries.

Easy enough request…but I’ll never understand why Microsoft doesn’t allow you to configure Event Log security from the Properties dialog box like you can for literally everything else (file, folders, registry hives and keys, directory services objects, the list goes on…). No, we get stuck using SDDL (Security Descriptor Definition Language)…not exactly the funnest thing in the world.

Fortunately, you can grant permissions on the Event Logs easily enough to either well-known SIDs or even to individual groups or users. First things first…you’ll manage the security settings for the Event Logs via the CustomSD string value in the Registry. Look at the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog key. Under this key, you’ll see entries for the Application Log, Security Log, etc.

Looking at the CustomSD String key, you see the lovely SDDL entries. Joy!

So, basically, there are three parts:

Allowing (A) or Denying (D)?
What level of access?
Who to?

Allowing or Denying access is pretty straight-forward.

The levels of access are as follows (and are cumulative to reach combinations):

1 = Read
2 = Write
4 = Clear

The last part is the SID that the permissions are being set for. This can either be a well-known SID (in that case a SID string can be used such as IU in the third to last enty in the key above or an actual SID like that seen in the last entry in the key above…or even a REAL user’s or group’s SID. Cool!

So, since I wanted to grant read access to the Application Log only for the developers, I added the following entry to the end of the CustomSD String key for the Application log. Of course, your SID values will be different!

(A;;0×1;;;S-1-5-21-1605523419-404293322-1556899496-26114)

Be sure to get all of the parts of the entry correct. That would be the opening parenthesis, the A or D, the two semi-colons, the Hexadecimal value representation of the cumulative permissions desired, three more semi-colons, the SID and lastly a closing parenthesis.

Need a quick way to get the SID for a security principal in your domain? Try the attached script file. Save it as a .VBS file and place the sAMAccountName of the security principal you’re interested in where the **SAM** placeholder is.

You can get some more information about making these changes in KB323076, and on MSDN.

getSIDv2.zip (419 bytes, 1,169 hits)

Tags: Event Logs, Registry, Scripting, SDDL

Setting custom RecipentLimits values in Exchange

June 29, 2008 · Filed Under Exchange Server 2007, Powershell · Comment

A while back we had an issue where an employee had composed a new message in Outlook and selected every recipient listed in the Global Address List…every user, every contact, every distribution group and even a few lingering mail-enabled Public Folders. We have a fairly high global recipient limit in place to allow the sending out of all-hands newsletters, etc. from HR and other groups. This user, while not intending to do anything malicious, caused the receiving Hub Transport server to thrash pretty hard for quite some time due to the extremely large number of recipients she addressed the message to, including nearly a thousand distribution groups. Needless to say, there were an extremely high number of LDAP look ups being performed to expand the recipients of that messages. Additionally, there were thousands of copies of the message discarded since most mailboxes are members of more than a single distribution group. Overall, not a good situation in any way. It was certainly a scenario that we hadn’t planned for or thought about in our design, past or present.

As a result of this scenario, I recommended that we reduce our organizational default recipient limits and configure explicit exceptions for those users who should actually be able to send a message to everyone (and who we trust to not do it “accidentally”). The recommendation was approved and thus became policy. Isn’t that how most laws and policies come about anyhow? As a result of something that sounded so far fetched no one thought to plan for it…

While it’s certainly possible to set the custom, higher, recipient limits manually on each of the “allowed” mailboxes, it’s not administratively economical when the list of people allowed to send is large. Thus a conversation ensued between some members of the Exchange PSS team and myself…and the solution was realized: simply use the membership of a distribution group as a collection, on which the custom recipient limits could be applied. Kudos to Stuart P in PSS for the great suggestion!

So the process goes like this: run the Powershell script against the chosen distribution group (which contains all of the “allowed” senders, those who can send to large numbers of recipients) and then change the default global limit to a much lower number that is unlikely to cause any harm to the Exchange organization but doesn’t limit anyone’s ability to conduct normal business.

The script I wrote is attached. You’ll need to save it as a .PS1 file instead of .TXT and insert your values for the distribution group (**DistGroup**) and RecipientLimits value (**Limit**). You can easily set this script to run as a scheduled task if you wanted or just run it each time you change the membership of the distribution group that contains the mailboxes to have the custom recipient limits set.

Set-RecipientLimits.zip (432 bytes, 864 hits)

Tags: Powershell, Recipients, Scripting

Don’t forget to update your Ops Mgr agents!

June 27, 2008 · Filed Under Operations Manager · Comment

Just a note to those who are updating their Ops Mgr servers for the Exchange Server 2007 MP (or otherwise becuase you need to), when you install the two hotfixes that update your agent…you’ll of course need to push the update out to your agent managed servers. :) Just look in your Pending Management folder…

Tags: Agents

Exchange Server 2007 MP for Ops Mgr Updated

June 26, 2008 · Filed Under Operations Manager · 2 Comments

The Exchange Server 2007 Management Pack for Operations Manager 2007 SP1 was finally updated in the past week. This release is very welcome, I’m sure, by many Operations Manager and Exchange Server admins alike. You can download the updated MP from the MP Catalog here.

Also, there is a discrepancy in the requirements for the first hotfix. The information in the documentation included with the MP indicates you are to installt he hotfix on all of the Exchange servers being monitored by Ops Mgr: “Install the agent update specified in Knowledge Base article 950853 on all Exchange-based servers managed by Operations Manager before importing the Exchange Server 2007 Management Pack. This update addresses an agent memory leak issue.“ The hotfix KB article indicates the hotifx is to be installed on the Ops Mgr servers: “You must apply this hotfix on all Operations Manager Management Server computers.“ From the notes inside the hotfix (emphasis added):

Note: This patch applies to SCOM 2007 SP1 Only

Summary

A problem has been identified with SCOM 2007 SP1 agent, which leaks memory when processing rules/monitors specific to exchange 2007 MP. This hot-fix resolves this issue.

Symptoms

When affected by this issue, SCOM 2007 RTM agents will leak memory aggressively only if you have imported Exchange 2007 into your Management group.

After applying this fix the issue should go away.

Installation
This hotfix must be applied to each computer that meets the following criteria:

Hosts a Microsoft Operations Manager Management Server

The updates and prerequisites are below (emphasis added), copied from the included documentation (a nice change to have included documentation!). Pay special attention to the three items below in red. Note that the 950853 hotfix is not publicly available yet…so you’ll either need to call in and get it or, if you have a Premier Support contract, you can download it from the Premier Support portal. The other two hotfixes do have a download available.

The May 2008 update to the October 2007 version of the Exchange Server 2007 Management Pack, version 6.0.6278.12, includes the following changes:

All updates included in the 08.01.0240.001 version of the Exchange Server 2007 SP1 Management Pack for Microsoft Operations Manager 2005, except updates relating to reports.

Overrides were documented in the Management Pack Guide for the LDAP Search Time and Failure DSNs Total rules and monitors.

The management pack was updated to support the renamed performance counters in Exchange Server 2007 Service Pack 1. Performance counters for the Database object were renamed to MSExchange Database.

The management pack was updated to support non-default names of the Reporting data warehouse.

The OWA Connectivity performance view was updated to show performance data.

Fixed an issue where cluster virtual servers where discovered as type Microsoft Exchange 2007 Mailbox Servers Installation.

The Management Pack was updated so that alerts are correctly generated for events logged by physical cluster nodes in an Exchange Server 2007 cluster.

Fixed an issue where the Exchange cluster virtual servers were discovered as type Microsoft Exchange 2007 Mailbox Servers – Physical Computers Installation.

The Microsoft_Exchange_Server_Exchange_2007_Mailbox_Replication_Health_Test_ReplicationHealth_Events view was updated to target the Microsoft.Exchange.2007.Microsoft_Exchange_2007_Mailbox_Servers___Physical_Computers_ComputerGroup.

The reports were updated to support non-US locales on the Reporting Server.

The date/time picker was added to the reports, allowing for more flexibility in report scheduling.

The Failure and Delay DSNs Total monitors were updated to look for deltas. Previously, the monitors measured the averages for the sampling interval.

Fixed an issue where the cluster virtual servers were discovered as type Microsoft Exchange 2007 All Servers Installation.

Before You Import the Management Pack

Before you import the Exchange Server 2007 Management Pack for Operations Manager 2007 Management Pack, note the following limitations of the management pack:

There is no support for agentless monitoring.

Before you import the Exchange Server 2007 Management Pack for Operations Manager 2007 Management Pack, take the following actions:

Ensure that all systems running Exchange Server 2007 that are managed by Operations Manager use Local System as the Agent Action Account.

If you are monitoring Exchange Server 2007 clusters, ensure that all physical nodes of the cluster are monitored by Operations Manager 2007 and that Agent Proxy is turned on for each physical node in the cluster.

Install the agent update specified in Knowledge Base article 950853 on all Exchange-based servers managed by Operations Manager before importing the Exchange Server 2007 Management Pack. This update addresses an agent memory leak issue.

Install the update specified in Knowledge Base article 951979. This update contains an updated agent restart script and fixes issues with cluster discovery.

If you are monitoring Exchange Server 2007 clusters, ensure that you have installed the agent update specified in Knowledge Base article 951380 on all Exchange Server 2007 cluster nodes managed by Operations Manager. This update addresses an issue with cluster discovery.

Note: The agent updates require System Center Operations Manager Service Pack 1. If you do not install the above updates before you install the Exchange Server 2007 Management Pack for Operations Manager 2007 Management Pack, your installation will not work optimally.

The relevant KB articles for the referenced hotfixes:

Tags: Exchange, Management Pack

The Case of the Suddenly Dead Server

June 26, 2008 · Filed Under Windows Server 2003 · 1 Comment

I had recently built and turned over a Windows Server 2003 SP2 server to the applications team to be used a platform and hardware upgrade for the employee time clocking and reporting system. The build went smooth as did the subsequent application installation and configuration. Then, of course, you know what happened next: disaster.

The defining moment, as improbable as it seems, was the stopping of the core service that the application used. The service is stopped and started periodically for various reasons, so stopping it should not have had any negative impact on the system…but it appears to in some way. Soon after the service was stopped, almost every other running service on the server stopped. The server never crashed though, which was odd. Rebooting in Last Known Good didn’t offer any relief either.

When I finally got a chance to examine the Suddenly Dead Server, the first thing I wanted to do was to try and get the RPC service running as it’s a critical core service that many things depend on. Not to be, as it tossed the dreaded Error 5 message back at me.

Could not start the Remote Procedure Call (RPC) service on Local Computer. Error 5: Access is denied.

Not too many things are worse than a generic Error 5 message. So, permissions are the issue…but how do we go from stopping a service (a simple and innocent enough act) to rewriting permissions (in bulk) throughout the Registry and possibly elsewhere. That question still remains to be answered, but there was a way to fix the problem even if I didn’t know what the root cause was. Enter the secedit command. Since it hadn’t even been two days since I finished the build on the server, I felt confident that setting the security configuration back to the installation values would get things moving again.

Using the command secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose from the command line (see KB 313222 for some more background on the secedit command) was the fix I needed to at least get things moving again on the server. After importing the setup security template back into the server, things were looking up. Rather than trying to start all of the stopped services by hand (or using a script to do it), I opted for a reboot. Upon the subsequent log in, nearly everything was normal.

Even though things appeared to be running smoothly again, we still had no idea of what the root cause of the issue was. After gathering all of the relevant logs to be had, the server was rebuilt again. I’ll be going over the logs to try and find a needle in that haystack that leads to a root cause, but I doubt I’ll find it. Since the server never crashed out, there’s no dump to analyze and I didn’t find anything that screamed out to me “I’m the reason the server became Suddenly Dead” when I looked through all the logs.

At any rate, should you find yourself in the bad situation of dealing with the dreaded Error 5, and not being able to get your services running, consider the secedit command. It might just get your Suddenly Dead Server up and running again enough to at least try to collect logs as to what happened and why.

Tags: Error 5, secedit

MP Viewer 1.6 released!

June 24, 2008 · Filed Under Operations Manager · Comment

Another great update from Boris on the outstanding MP Viewer tool, now supports export to HTML or Excel.

Get it here from Boris’ blog.

Tags: Tools

Ops Mgr Event ID 2115

June 24, 2008 · Filed Under Operations Manager · Comment

I finally got around to implementing reporting yesterday for my Operations Manager 2007 implementation. I had previously asked the DBA to create the OperationsManagerDW DB for me on the SQL 2005 cluster using the DBCreateWizard tool per the deployment documentation (page 65 in the OpsMgr2007_Deployment.doc file or online here)…of course, following the directions and expecting that things would be just fine. Uh huh.

I finished the reporting installation late the afternoon and left for the day, knowing that the reports would take some time to display in the console…30 minutes is what the documentation states. A few hours later, however, I started getting Alert generated by Send Queue % Used Threshold alerts from a large number of hosts.

Summary
This monitor measures the Health Service Management Groups\Send Queue % Used and generates the following states:

Monitor State
Send Queue % Used Threshold

Warning
50 %

Critical
60 %

Causes
This can be caused by a low bandwidth or high latency connection from this Health Service to its parent Management Server. This can also be caused by rules that are collecting more data than the parent Management Server can process; especially when the parent Management Server has many agents reporting to it sending large amounts of data.

In looking at the Operations Manager event log on the RMS, I noticed Event ID 2115 errors every minute.

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Date:  6/24/2008
Time:  6:44:00 AM
User:  N/A
Computer: SERVER
Description:
A Bind Data Source in Management Group SysCtrOpsMgr has posted items to the workflow, but has not received a response in 52139 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData
Instance    : server.local
Instance Id : {CCA6D079-B810-CFE6-9784-9A8B2E483432}

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Date:  6/24/2008
Time:  6:43:27 AM
User:  N/A
Computer: SERVER
Description:
A Bind Data Source in Management Group SysCtrOpsMgr has posted items to the workflow, but has not received a response in 52077 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.DataWarehouse.CollectEventData
Instance    : server.local
Instance Id : {CCA6D079-B810-CFE6-9784-9A8B2E483432}

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Date:  6/24/2008
Time:  6:43:27 AM
User:  N/A
Computer: SERVER
Description:
A Bind Data Source in Management Group SysCtrOpsMgr has posted items to the workflow, but has not received a response in 52077 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.DataWarehouse.CollectEntityHealthStateChange
Instance    : server.local
Instance Id : {CCA6D079-B810-CFE6-9784-9A8B2E483432}

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

There were also Event ID 11411 entries every 10 minutes.

Event Type: Warning
Event Source: Health Service Modules
Event Category: None
Event ID: 11411
Date:  6/24/2008
Time:  6:45:04 AM
User:  N/A
Computer: SERVER
Description:
Alert subscription data source module encountered alert subscriptions that were waiting for a long time to receive an acknowledgement.
Alert subscription ruleid, Alert subscription query low watermark, Alert subscription query high watermark:
5fcdbf15-4f5b-29db-ffdc-f2088a0f33b7,06/23/2008 21:18:58, 06/23/2008 21:21:58

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

And of course, no reports visible in the Reporting node of the Ops Mgr GUI. Not good. I found several references to Event ID 2115 and this exact error while searching, but they didn’t seem to correct the issue. We don’t have Exchange Server 2003, so Clive’s post was out the window. I did make the overrides that Kevin mentioned in his post, but that didn’t fix the errors either. So I was right back to where I started in thinking that something was wrong with the database.

The solution was found in KB 942865, although the symptoms in the article didn’t match up completely…at least the title didn’t. At any rate, the OperationsManagerDW DB was created with the DBCreateWizard tool, and the query Select * from MemberDatabasethat was run against the OperationsManagerDW DB didn’t return any rows.

Running the query EXEC MemberDatabaseAttach ‘dbserver\instanceName’, ‘datawarehouseDBname‘, 1, 1, 1 query in the KB article was the fix. (Be sure to change the SQL server and instance and DW DB names accordingly, as the article points out.) After that, running the query Select * from MemberDatabase returned the expected results, a single row that contained the SQL server name and DB name. Even better yet, event ID 31554 entries (not 31544 as indicated in the KB article) entries started to appear.

Event Type: Information
Event Source: Health Service Modules
Event Category: Data Warehouse
Event ID: 31554
Date:  6/24/2008
Time:  7:40:09 AM
User:  N/A
Computer: SERVER
Description:
Workflow succeeded storing data in the Data Warehouse

One or more workflows were affected by this.

Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData
Instance name: server.local
Instance ID: {CCA6D079-B810-CFE6-9784-9A8B2E483432}
Management group: SysCtrOpsMgr

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

If have previously seen the Event ID 11411 entries, you should also see an Event ID 11412 show up on your management server a short time later.

Event Type: Warning
Event Source: Health Service Modules
Event Category: None
Event ID: 11412
Date:  6/24/2008
Time:  7:54:04 AM
User:  N/A
Computer: SERVER
Description:
Alert subscription data source module has recovered from the long wait to receive acknowledgements for alert subscriptions.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So that’s the fix…but what was the REAL problem? Nothing in the KB article discussed it, and I didn’t find it through searching after the fact. Anyone have any ideas?

Tags: Data Warehouse, DBCreateWizard, Health Service, Operations Manager

Helpful reference for Ops Mgr Priorities and Severities

June 22, 2008 · Filed Under Operations Manager · Comment

Found this the other day while I was looking for something to confirm what I thought where the relationships between the numerical values in alerts and the text labels you have to choose from configuring subscriptions (and overrides).

Alert Severity

Critical = 2

Warning = 1

Information = 0

Alert Priority

High = 2

Medium = 1

Low = 0

As an example of how I’m using this knowledge for a specific problem…I only want alerts from the AD Client Connectivity Monitor to come to me as I’m troubleshooting some time-out issues, etc. I have a subscription that send all Critical alerts out to our whole group of admins, and another subscription that sends me the Warning alerts separately. The net effect is that I get both Warning and Critical, but no one else in my group has to deal with the noisy AD Client Connectivity Monitor while I’m working on the issue at hand. Once that issue has been resolved, I’ll remove the override from the monitor, setting its Alert Severity back to its default value of Critical.

What the alert looked like before the override:

Source: AD Client Monitoring
Path: myserver.local
Alert: AD Client Monitoring: AD Connectivity is unavailable, or the response is too slow Resolution state: Closed
Priority: 1
Severity: 2

What the alert looked like after the override:

Source: AD Client Monitoring
Path: myserver.local
Alert: AD Client Monitoring: AD Connectivity is unavailable, or the response is too slow Resolution state: Closed
Priority: 1
Severity: 1

Of course, the value of knowing the numerical relationship of each severity and priority goes beyond just making overrides easier to configure if you have a noisy or otherwise troublesome monitor or rule. Many organizations use the various severity levels as filters when configuring different subscriptions. If you’re developing your own monitors, you’ll need to have a clear understanding of these values of well.

Tags: Alerts

AD_Client_Update_DCs.vbs script too few parameters

June 19, 2008 · Filed Under Operations Manager · 1 Comment

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: 1

Last 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:
        -1

Command 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?

Tags: Active Directory, Operations Manager, Overrides

Tuning Ops Mgr Self-Tuning Threshold Monitors

June 18, 2008 · Filed Under Operations Manager · Comment

After I had installed the Ops Mgr agents onto our Citrix PS 4.0 terminal servers, I started getting floods of alerts from two monitors: Terminal Services Inactive Sessions metric above baseline and Terminal Services Active Sessions metric above baseline. The strange thing was that no values were ever being reported in the output, like Ops Mgr was constantly trying to get the baseline value down, but couldn’t. The monitor is configured (as all are STT monitors by default) for a week long learning period, but the alerts continued on after a week had gone by.

Source: Terminal Services
Path: server
Alert: Terminal Services Inactive Sessions metric above baseline Resolution state: New
Priority: 1
Severity: 2

Last modified by: System
Last modified time: 6/18/2008 3:05:57 AM Alert description: Inactive Sessions metric is above the calculated baseline. Current value is

Alert view link: “xxx”
Notification subscription ID generating this message: {xxx}

So, into override mode we go. Our Terminal Services environment is probably somewhat different than a lot of others just due to the nature of the published applications being used. If you’ve ever looked at the override values for a STT monitor, you know it’s fairly cryptic…the numbers you see and can change really don’t mean anything to a human as their part of the algorithm being used internally by Ops Mgr, but they do correlate to what you can see in the GUI on the Baselining tab of the STT monitor’s properties dialog box.

But of course, all you see are numbers when you go to configure the override, those cryptic meaningless (at least to most of us) numbers.

After some experimenting, by creating a new STT monitor with Sensitivity and Time Sensitivity values at each of the five possible points, I was able to figure out what each point corresponded to numerically. It’s worth noting that it was about this time I thought to look around on Google for information about tuning STT monitors and happened to find out the battle had been fought previously. See Kevin Holman’s post about dealing with STT in Exchange Server 2003. He also followed the trial and error method to get the values of Sensitivity and Time Sensitivity. I never did find out where changes in the Learning Rate were being set (rule wise) nor did I make any changes to the Learning Rate for the two STT monitors I was working with. If anyone has some insight into that specific area, I’d love to hear it!

The values that correspond to the Sensitivity slider settings are (notice that they are ALWAYS 0.5 units appart from each other):

Low: Inner Sensitvity: 4.01, Outer Sensitivity: 4.51
Low-Mid: Inner Sensitivity: 3.77, Outer Sensitivity: 4.27
Mid: Inner Sensitvity: 3.29, Outer: 3.79
Mid-High: Inner: 2.81, Outer Sensitivity: 3.31 (DEFUALT VALUES)
High: Inner Sensitvity: 2.57, Outer Sensitvity: 3.07

The values that correspond to the Time Sensitivity slider settings are (found on the corresponding signature rule:

Low: Sensitivity: 4.01
Low-Mid: Sensitivity: 3.77
Mid: Sensitivity: 3.29
Mid-High: Sensitivity: 2.81 (DEFAULT VALUE)
High: Sensitivity: 2.57

When configuring the override for a pesky STT, be sure to change all three items (Inner Sentivity and Outer Sentivity on the STT monitor and the (time) Sentivity on the associated baseline collection rule). You should end up with something similar to this (although this was for a pair of STT monitors, so your quantity will be slightly different).