Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

Cleaning up the Default MP

Cleaning up the Default MP

  • Comments 5
  • Likes

The Default management pack that ships with OpsMgr 2007 is used to store very specific information for the management group.  It is a widely known best practice to NOT write any custom rules, monitors, groups, views, or overrides to this MP.  Even customers who know this - and try to enforce this across their organizations.... will still inadvertently get junk in their default MP.... they will save things here by accident, or by granting access to advanced operators who aren't educated on this topic.

 

The main problem with doing so.... is that we will build a dependency for this MP on any MP it references.... and therefore we wont ever be able to delete those management packs, until we clean this Default MP up, and start enforcing best practices.

In this post, I will give some examples of what should be in your default MP, what should not, and how to clean it up.

Before I get started - you can also refer to this post from the momteam.... which is basically what we will do - I will just go into much greater detail:

http://blogs.technet.com/momteam/archive/2007/05/03/removing-dependencies-on-the-default-management-pack.aspx

 

Ok... lets get started.

First - know that when you install OpsMgr - you will copy a totally clean, generic Default MP at the path where you installed OpsMgr.  I usually just pick this up from the RMS or an MS if I need it:

D:\Program Files\System Center Operations Manager 2007\Microsoft.SystemCenter.OperationsManager.DefaultUser.xml

Whatever you do - don't edit or mess with this one..... it is great to have when you need to just start over - you can always import this one again to get a clean default MP.... but you will lose any customizations that you have saved to it.

 

So.... if you are at a point, where you just want your default MP cleaned up.... and you don't care about ANYTHING that was in it - good or bad, since you installed SCOM - then simply BACK UP your current default MP..... then import this MP, and overwrite your existing one.  This will nuke any overrides, views, rules, monitors, and references that were previously present.  You will then be able to delete any other management packs that you previously could not.  You will need to go back and re-configure any AEM or AD assignment configurations you have made....

 

Now.... if you are still reading this - you want to learn more - and understand what all goes in the Default MP and clean it up manually?  Let's roll. 

So - make a copy of the "unspoiled" MP and open it up to see what's in a generic one:

There are many sections in the XML, and 3 core sections:

Mainfest
Presentation
LaunguagePacks

<Mainfest> contains:

<Identity>
<Name>
<References>

The <Identity> section contains the name <ID> and <Version> of the MP.

The <Name> section contains the MP common name.

The <References> section contains any references to other MP.... this will cause the default MP to "depend" on these MP's in order to import it....  the default references are the Microsoft.SystemCenter.Library, Microsoft.SystemCenter.Notifications.Library, Microsoft.Windows.Library, and the System.Library.

<Presentation> contains:

<Views>
<Folders>
<FolderItems>

These items above all define the default views that you see at the top of the Monitoring pane folder list, in the console.  This is why these views will disappear if someone deletes the default MP.

image

If you ever scope these views.... like to a group.... or make any changes.... or... add a new view up in this area.... it will ALWAYS write that to the default MP.  For this reason - it is a best practice to leave these views alone, and do any scoped views in your custom MP's or in your "My Workspace" section.

<LaunguagePacks> contains:

<DisplayStrings>
<KnowledgeArticles>

<DisplayStrings> contains the simple common names for objects and references in the MP.  This section will often contains human readable information.... where the actual rules, monitors, overrides, etc... will just contain GUID's.

<KnowledgeArticles> contains the description and knowledge for the MP.

 

Ok - that was easy.  Now - lets break our default MP.... and show what all we created in the XML when we do this.

For this example - I am going to create a new custom view, a custom rule, a custom monitor, an override for a monitor from the Exchange MP, and an override for a Base OS rule.  The will serve as examples for the most common types of junk that gets dumped in the default MP.

First - I will create a new Alert view at the top level in OpsMgr - and call it "Demo - Closed Alerts"

image

Second - I will create a custom Alert Generating Event Rule - that looks for Event 100 in the application log, and save that to the default MP.

Third - I will create a custom Unit Monitor, Windows Performance Counters, Static Threshold, Single Threshold, Simple Threshold, for %processor time CPU.

Fourth - I will create a rule override.... Open the authoring pane, select Rules, and scope to "Windows Server 2003 Operating System".  Find the "NTFS - File System Corrupt" rule, and override it - for all objects of type - and set the severity from Warning to critical, and save it to the default MP.

image

 

Lastly - I will create an override for a monitor.  Under authoring - monitors, scope to "Exchange 2003 Role", and override the "SSL should be enabled" monitor to "Disabled" (or Enabled = False)

 

Now - lets export our Default MP... and open it up.  I just use notepad..... but there are other good XML editors out there.

We can see what has changed.

First off - in references - we now have new sections.... for:

System.Performance.Library
Microsoft.Windows.Server.2003
System.Health.Library
Microsoft.Exchange.Server.2003.Discovery
Microsoft.Exchange.Server.2003.Monitoring

These are all present because they are required for the new rules, monitors, views, and overrides we just created.  At this point - if we tried to delete the Exchange management pack - we will now get the following error:

image

 

We also now have some new sections in the XML.

<Monitoring>

Which contains:

<Rules>
<Monitors>
<Overrides>

Those should be pretty self explanatory.

We have also created a new view... and added quite a bit to the <DisplayStrings> section.

 

To clean this mess up..... we have a couple options.  We can do all the heavy lifting in XML.... or we can use the XML as a guide - and find the Rules, Monitors, Overrides, and Views - and nuke them from the console.  Then - the only manual cleanup we HAVE to do in XML - is simply remove references.  You should be able to look at the new sections of XML... and clean up any junk pretty easily at this point.

 

Moving forward - I am going to clean this up directly in XML.

 

First - I will clean up the <Rules> section.  It looks like so:

 

<Monitoring>
    <Rules>
      <Rule ID="MomUIGeneratedRule11823be0093a4510b8e6b3a9089cecaf" Enabled="true" Target="Windows!Microsoft.Windows.Server.Computer" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Alert</Category>
        <DataSources>
          <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.EventProvider">
            <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
            <LogName>Application</LogName>
            <Expression>
              <And>
                <Expression>
                  <SimpleExpression>
                    <ValueExpression>
                      <XPathQuery Type="UnsignedInteger">EventDisplayNumber</XPathQuery>
                    </ValueExpression>
                    <Operator>Equal</Operator>
                    <ValueExpression>
                      <Value Type="UnsignedInteger">100</Value>
                    </ValueExpression>
                  </SimpleExpression>
                </Expression>
                <Expression>
                  <SimpleExpression>
                    <ValueExpression>
                      <XPathQuery Type="String">PublisherName</XPathQuery>
                    </ValueExpression>
                    <Operator>Equal</Operator>
                    <ValueExpression>
                      <Value Type="String">TEST</Value>
                    </ValueExpression>
                  </SimpleExpression>
                </Expression>
              </And>
            </Expression>
          </DataSource>
        </DataSources>
        <WriteActions>
          <WriteAction ID="Alert" TypeID="Health!System.Health.GenerateAlert">
            <Priority>1</Priority>
            <Severity>2</Severity>
            <AlertName />
            <AlertDescription />
            <AlertOwner />
            <AlertMessageId>$MPElement[Name="MomUIGeneratedRule11823be0093a4510b8e6b3a9089cecaf.AlertMessage"]$</AlertMessageId>
            <AlertParameters>
              <AlertParameter1>$Data/EventDescription$</AlertParameter1>
            </AlertParameters>
            <Suppression />
            <Custom1 />
            <Custom2 />
            <Custom3 />
            <Custom4 />
            <Custom5 />
            <Custom6 />
            <Custom7 />
            <Custom8 />
            <Custom9 />
            <Custom10 />
          </WriteAction>
        </WriteActions>
      </Rule>
    </Rules>

 

Technically - at this point - I could just delete the WHOLE SECTION.... from <Rules> to </Rules>.  However - what if there are other rules present I want to keep - and I just want to delete specific rules?  Easy....   I will just delete one rule at a time - in this case - from the part that starts with <Rule ID="MomUIGeneratedRule........... > to the immediate next </Rule>

 

 

Next - on to the <Monitors> section.

Again this is just like rules - I could delete the <Monitors> to </Monitors> entire section.... or I could just delete specific monitors... like from <UnitMonitor ID="UIGeneratedMonitor........> to the immediate next </UnitMonitor>

 

On to overrides.

This section is REALLY easy.... if have reviewed all of them... and don't want ANY overrides.... just nuke the <Overrides> to </Overrides> section.  Here is mine, for the two overrides I created:

<Overrides>
  <RuleConfigurationOverride ID="OverrideForRuleMicrosoftWindowsServer2003OperatingSystemNTFSFileSystemCorruptAlertForContextMicrosoftWindowsServer2003OperatingSystem5163b1e8fcfa4dc2977f3464131ad250" Context="Windows1!Microsoft.Windows.Server.2003.OperatingSystem" Enforced="false" Rule="Windows1!Microsoft.Windows.Server.2003.OperatingSystem.NTFSFileSystemCorrupt.Alert" Parameter="Severity" Module="GenerateAlert">
    <Value>2</Value>
  </RuleConfigurationOverride>
  <MonitorPropertyOverride ID="OverrideForMonitorVerifyifSSLshouldberequiredMonitorForContextMicrosoftExchangeServerRole2003b25ef51deef94136b67b674bd6ba0510" Context="Exchange!Microsoft.Exchange.ServerRole.2003" Enforced="false" Monitor="Exchange1!Verify_if_SSL_should_be_required.Monitor" Property="Enabled">
    <Value>false</Value>
  </MonitorPropertyOverride>
</Overrides>

 

That is very simple.... I can delete the section, or just each override individually.... from <RuleConfigurationOverride> to </RuleConfigurationOverride>.

 

 

On to views.

To delete my view - the simplest way is in the console.  However.... it can be done in XML as well.... just search for the view name.... in my case I will search on "Demo"  What I see - is that this "common name" is present in the <DisplayStrings> section.... and references a view GUID:

<DisplayString ElementID="View_d2f9d2ef789e4e0bb67bae73b116e2cd">
  <Name>Demo - Closed Alerts</Name>
</DisplayString>

I can delete this section - but then I also need to delete the actual view.... so I search on "View_d2f9d2ef789e4e0bb67bae73b116e2cd"

This helps me find the section under <Views> with the name <View ID="View_d2f9d2ef789e4e0bb67bae73b116e2cd".....>.   I can delete from there - to the next </View>

Then - find the <FolderItem> for your custom view (search by the same guid - and delete that line.

Then - delete the <DisplayString ElementID="View_d2f9d2ef789e4e0bb67bae73b116e2cd"> section. 

At this point - there should be no more references to your custom view GUID....  "View_d2f9d2ef789e4e0bb67bae73b116e2cd"

 

 

Next - <DisplayStrings>

We need to remove any DisplayStrings sections that refer to our views, monitors, rules, or overrides.  They should be easy to find - because they <Name> will be readily recognizable.  Here are the ones I will be removing:

<DisplayString ElementID="MomUIGeneratedRule11823be0093a4510b8e6b3a9089cecaf">
  <Name>Demo - Event 100 - default MP cleanup</Name>
</DisplayString>
<DisplayString ElementID="MomUIGeneratedRule11823be0093a4510b8e6b3a9089cecaf.AlertMessage">
  <Name>Demo - Event 100 - default MP cleanup</Name>
  <Description>{0}</Description>
</DisplayString>
<DisplayString ElementID="UIGeneratedMonitor955e7c14a8584682a122ce337fa578be">
  <Name>Demo - CPU - Default MP cleanup monitor</Name>
</DisplayString>
<DisplayString ElementID="UIGeneratedMonitor955e7c14a8584682a122ce337fa578be" SubElementID="UIGeneratedOpStateIdfe47902e4da54cd380b45b436304b335">
  <Name>Under Threshold</Name>
</DisplayString>
<DisplayString ElementID="UIGeneratedMonitor955e7c14a8584682a122ce337fa578be" SubElementID="UIGeneratedOpStateId2bef4b2d2d6e47ec8ed794d6472f64d4">
  <Name>Over Threshold</Name>
</DisplayString>
<DisplayString ElementID="UIGeneratedMonitor955e7c14a8584682a122ce337fa578be_AlertMessageResourceID">
  <Name>Demo - CPU - Default MP cleanup monitor</Name>
</DisplayString>

 

 

Last but not least - lets remove those pesky references.

Now.... technically, if our MP was totally clean, we could remove all references except the default 4 references.  However, I don't recommend that.  We might have left something in the default MP that needs some of the references.  The best bet here - is to clean it up - and remove the references that are *keeping you from deleting* a MP.... if that is why you started this little escapade in the first place.

So - Here is my current (BAD) reference list:

 

<References>
  <Reference Alias="Notification">
    <ID>Microsoft.SystemCenter.Notifications.Library</ID>
    <Version>6.0.9010.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Windows">
    <ID>Microsoft.Windows.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Performance">
    <ID>System.Performance.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="System">
    <ID>System.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="SC">
    <ID>Microsoft.SystemCenter.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Windows1">
    <ID>Microsoft.Windows.Server.2003</ID>
    <Version>6.0.6321.5</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Health">
    <ID>System.Health.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Exchange">
    <ID>Microsoft.Exchange.Server.2003.Discovery</ID>
    <Version>6.0.6387.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Exchange1">
    <ID>Microsoft.Exchange.Server.2003.Monitoring</ID>
    <Version>6.0.6387.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
</References>

 

In this case - I am only going to delete the Base OS section (Microsoft.Windows.Server.2003) and the Exchange sections.

Here it is all fixed up:

 

<References>
  <Reference Alias="Notification">
    <ID>Microsoft.SystemCenter.Notifications.Library</ID>
    <Version>6.0.9010.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Windows">
    <ID>Microsoft.Windows.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Performance">
    <ID>System.Performance.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="System">
    <ID>System.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="SC">
    <ID>Microsoft.SystemCenter.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
  <Reference Alias="Health">
    <ID>System.Health.Library</ID>
    <Version>6.0.6278.0</Version>
    <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
  </Reference>
</References>

 

Alright!

We have now removed the rules, monitors, overrides, and views.... and then lastly - the most important... the references. 

Lets try and import!

If it works - you did a great job.  If it doesn't - look at the failure - and try to figure out what you missed.  Most likely there is a displaystring left behind... or a folderitem.... or you deleted a reference for some rule/monitor/override that is still present and referring to it's alias.

 

Now when I try and delete the Exchange MP.... I no longer get the dependency error on the default MP.  All is well with OpsMgr and the world.

 

 

Additional tips on monitoring the default MP:

 

There is a generic report called "Override Report" which can be scheduled weekly to tip you off - if someone saved something new to the Default MP:

 

image

 

 

Here is a SQL query - against the Operations Database - that will also show you all the current Overrides in the default MP:

select aov.name, parenttype, overrideableparametername, value, overridetype, aov.lastmodified from AllOverrideView aov
inner join ManagementPackView mpv on aov.managementpackID = mpv.Id
where mpv.name = 'Microsoft.SystemCenter.OperationsManager.DefaultUser'
order by aov.lastmodified DESC

If you were handy at scripting - you could write a Monitor - that runs the following query on a timed schedule (like once per day) and alerts when the number of overrides in the default MP is over what you have established is normal.... like when the number of overrides should be 2, but is detected to be >2, then generate an alert.

select count(*) as NumberOfOverrides from AllOverrideView aov
inner join ManagementPackView mpv on aov.managementpackID = mpv.Id
where mpv.name = 'Microsoft.SystemCenter.OperationsManager.DefaultUser'

UPDATE 11-12-08

Jonathan Almquist updated his sample script and MP - which does this very thing:  It will alert you whenever someone saves an override to the default MP.  VERY COOL!

Check it out:  http://blogs.technet.com/jonathanalmquist/archive/2008/11/12/monitor-default-management-pack.aspx

Comments
  • A colleague wrote about best practices concerning the Default Management Pack, and how to clean it...if

  • Dva postupy podrobně popisující Default Management Pack uvádějí kolegové z Microsoftu: Způsob údržby

  • Dva postupy podrobně popisující Default Management Pack uvádějí kolegové z Microsoftu: Způsob údržby

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs