Base OS MP 6.0.7294.0 issues


Several top bloggers have reported a bug in the 6.0.7294.0 Management Pack.

Until this gets updated – the previous version 6.0.7292.0 has been made available:


There are some issues with mount points that were being resolved in this MP – but the big issue with the MP was in the Logical Disk performance collection rules.  For server 2003, 2008, and 2012, there 16 rules that collect performance data from logical disks.  Of these, 5 are enabled out of the box.

The problem is this – when we collect perf data from a multi-instance object (like logical disks) we must specify which instance we want to collect data for.  Otherwise, this breaks performance reporting in the data warehouse due to how we aggregate the data. 

In this case, a change was made from this:

<DataSource ID="PerformanceDS" TypeID="SystemPerf!System.Performance.OptimizedDataProvider">
  <CounterName>% Free Space</CounterName>


To this:

<DataSource ID="PerformanceDS" TypeID="SystemPerf!System.Performance.OptimizedDataProvider">
  <CounterName>% Free Space</CounterName>
  <InstanceName />


This is bad, because we will collect data for all instances of logical disk on a server, for each and every discovered disk.  This will skew the data shown in the consoles, and reports.  It could potentially flood the SCOM database with data, as some servers have a large number of logical disks.

This MP was only available on the web for a short time, so it is unlikely it was imported in many production environments, since it did not have time to go through any real testing and change management.  However, if you find that you did import this MP – you have a few options:

1.  Remove (delete) the MP’s and go back to a previous version.  This is likely impossible as to many other MP’s often take dependencies on these core Base OS MP’s especially the libraries.  So you might find this to not be possible.

2.  Disable the performance collection rules in this MP temporarily, until a fixed MP ships.

3.  Do nothing, and wait for the next version of the Base OS MP’s to ship.  This is probably not advised, unless it is in a very small lab environment.

Here is a sample of the rules being discussed:


Comments (17)

  1. I also think, that for every management pack that Microsoft pull back, the previous version of the same Management pack with bumped up version number should be availabe to minimize administrative effort. sometime it is a big pain to remove dependencies,
    or täkes a lõng time before the fixed version of Managemt Pack is available.

  2. HectorMarcia says:

    The provided link takes me to MS Download site that shows v. 6.0.7292.0 under Details yet the .msi contains 6.0.7294.0 mp files.

    Can someone please share v. 6.0.7292.0?


  3. why not to release the same "the previous version 6.0.7292.0" with bumped up versioon number, so we can easyly upgrade without removing first newer version?

  4. +1 for the increased version number idea. Please sort this soon, MS.

  5. Kevin Holman says:

    Guys, just a heads up there should be an updated MP coming out very soon with this issue resolved, along with fixes for mount point discoveries that were part of this root cause issue.

  6. Andrew VO says:

    Excellent point, and how about it MSFT? Updates to long standing MPs containing minor bugfixes to a particular area should never break something in an unrelated area. We all make mistakes. Efforts to make things right make the difference. We’re not blind
    to what’s going on with the slide in quality over the past year.

  7. Andrew VO says:

    Great comments, Sergei. In our businesses, with applications we provide, if we rollout an update with a problem, we either fix it within X number of hours or it’s rolled back. It’s mandated we communicate progress along the way with customers. Not unreasonable
    to expect the same here

  8. RHC says:

    I agree, please bump the version 1 up. That will be really appreciated!

  9. Sysops says:

    They don’t do that, because it would require a little work on their end, something it seems, when it comes to MP’s, they fail to do. Remember the Exchange MP issue? At least this time they released a lower level version. For Exchange you were out of luck
    for months. The QA checking on MP’s is horrible and needs to be re-examined. Early adopters often get the short end of the stick, and they maybe forced to early adopt, because the MP now supports Server 2012, or a new "feature". Why SCOM enthusiast continue
    to find these bugs, after the fact, is beyond me, but it tells me that MSFT isn’t really that concerned with the quality of the MP’s they develop and drop to the public. How long do they bake in these MP’s before releasing them to the public? Wouldn’t they
    pay particular attention to monitors/rules that were changed since the last version? Aren’t they using these MP’s, even before they are released, in the cloud to monitor hosted client environments? Office 365, XBOX Live, Etc? This product has been around for
    years now, you would think the crux of the application, the management packs, would have a decent development, testing, and release process by now. SMH. +1 for the version increase as well, that’s a damn no brainer.

  10. Mor Adiv says:

    If anyone, like me, already applied the new MP that contains a bug,
    you can disable all the affected rules by creating MP named "Windows.Temporal.Disabled.Rules" and run the following ps script:

    #connec to scom
    import-module operationsmanager
    New-SCOMManagementGroupConnection -ComputerName (ms server name)
    $MP = Get-SCOMManagementPack -displayname "Windows.Temporal.Disabled.Rules" | where {$_.Sealed -eq $False}

    #get and disable 2003 rules on targeted on 2003 logical disk
    $rules2003 = Get-SCOMRule | where {$_.ManagementPackName -like ‘Microsoft.Windows.Server.2003*’ -and $_.Enabled -eq ‘true’ -and $_.Target -like ‘*0b95ad7d-e73b-80cf*’}
    $class2003 = Get-SCOMClass -DisplayName "Windows Server 2003 Logical Disk"
    Disable-SCOMRule -Class $class2003 -Rule $rules2003 -ManagementPack $MP -Enforce

    #get and disable 2008 rules on targeted on 2008 logical disk
    $rules2008 = Get-SCOMRule | where {$_.ManagementPackName -like ‘Microsoft.Windows.Server.2008*’ -and $_.Enabled -eq ‘true’ -and $_.Target -like ‘*5de7b548-657d-7794*’}
    $class2008 = Get-SCOMClass -DisplayName "Windows Server 2008 Logical Disk"
    Disable-SCOMRule -Class $class2008 -Rule $rules2008 -ManagementPack $MP -Enforce

    #get and disable 2012 rules on targeted on 2012 logical disk
    $rules2012 = Get-SCOMRule | where {$_.ManagementPackName -like ‘Microsoft.Windows.Server.2012*’ -and $_.Enabled -eq ‘true’ -and $_.Target -like ‘*3d549847-ed40-6252*’ -and $_.DisplayName -notlike ‘*Corrupt Rule’}
    $class2012 = Get-SCOMClass -DisplayName "Windows Server 2012 Logical Disk"
    Disable-SCOMRule -Class $class2012 -Rule $rules2012 -ManagementPack $MP -Enforce

    When the new MP will be published and the bug will be fixed, you can simply remove the MP named Windows.Temporal.Disabled.Rules and the rules will get working again (after importing the new MP of course).

  11. Cdufour says:

    Thx for the information!

  12. Andrew VO says:

    Thank you for confirming what I had heard Kevin

  13. Andrew VO says:

    6.0.7296.0 just released to

    Starting lab testing…

  14. Andrew VO says:

    Disk space counters appear fixed, haven’t looked at anything else yet.

    The cleanup queries in are a must here

  15. Is it me, or is the ‘Logical Disk: Average Percent Idle Time’ in the ‘Microsoft Windows Server Reports Performance by Utilization’ report sorted incorrectly? It shows all the disks that are doing nothing (100% idle), when we’re actually interested in all
    the disks that have very low idle time?

Skip to main content