Blog TalesCleaning up the Default MP
Kevin Holman
In which we search far and wide to bring you the best of the Microsoft blogs. Here's one from the Kevin Holman's OpsMgr Blog.
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 won't 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:
Ok... let's 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
LanguagePacks
<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.
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.
<LanguagePacks> 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—let's 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"
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.
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—let's 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:
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 of 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="OverrideForRuleMicrosoftWindowsServer2003OperatingSystemNTFSFileSystemCorruptAlertForContext
MicrosoftWindowsServer2003OperatingSystem5163b1e8fcfa4dc2977f3464131ad250"
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>
<MonitorPropertyOverrideID="OverrideForMonitorVerifyifSSLshouldberequiredMonitorForContext
MicrosoftExchangeServerRole2003b25ef51deef94136b67b674bd6ba0510"
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—let's 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">
<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>
</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>
We have now removed the rules, monitors, overrides, and views.... and then lastly—the most important... the references.
Let's 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:
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 are 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'
Look for next month's Blog Tales column, in which Jonathan Almquist describes a sample script and MP that alerts you whenever someone saves an override to the default MP.
Kevin Holman is a Senior Premier Field Engineer with Microsoft supporting System Center Operations Manager for large enterprises. He has been with Microsoft for 3 years and has been involved with large-scale deployments of MOM 2005 and OpsMgr 2007, out of the Las Colinas Texas office. Kevin has been in the technology industry for 14 years. He is active in the OpsMgr community, and maintains an OpsMgr blog, at https://blogs.technet.com/kevinholman/. He currently lives in Plano, TX.