Updated Windows Server and Terminal Services Ops Mgr MPs
New Management Packs for Windows Servers (2000, 2003 and 2008) and Terminal Services (2000, 2003 and 2008) were also released in late July.
Update your Windows Server MP first, get it here, which is version 6.0.6278.22.
What’s New
The following features are new in this release of the Windows Server Operating System Management Pack:
- Introduced support for Windows Server 2008.
- Added version specific notations to the names of the performance collection rules to reduce ambiguity, specifically when search for rules by name.
- Added a new task to leverage the new “Admin” switch of the remote desktop connection tool. More detail is provided in the “Troubleshooting” section.
Changes in This Update
The update to the June 2008 version of the Windows Server Operating System Management Pack includes the following changes:
- Updated the logical drive discoveries to omit mapped network drives.
- Addressed an issue with the Logical Disk Free Space to prevent it from looking like the thresholds were set incorrectly.
- The state of the configuration of a server now reflects the state of its operating system as well.
- Fixed an issue with the Server Service Configuration Health monitor which prevented it from ever generating an alert.
You can get the Terminal Services updated MP here, which is also version 6.0.6278.22. No “fixes” listed in this MP, but it does add support for 2008 based Terminal Servers.
What’s New
The following features are new in this release of the Terminal Services Management Pack specific to Terminal Services in Windows Server 2008:
- TS Gateway
- TS Session Broker
- TS Web Access
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?
Tuning Ops Mgr Self-Tuning Threshold Monitors
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: 2Last 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 isAlert 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).











































