SCOM 2012: What’s new: Default behavior of overrides
This post is part of a series What’s new: Check here for the other parts.
SCOM has some huge changes on board… But some are rather small and go unnoticed to the untrained eye although they could save you a major headache.
I’m pretty sure not a lot of hands will be raised when I pop the question: “Are you 100% sure your default management pack is free of overrides, if it’s not you buy me a beer?”. Although this is not that important because (let’s face it) it works doesn’t it? You will at one point or another have a big headache when you want to delete or upgrade a management pack which has an override stored in the default management pack. This makes the default management pack referenced by the management pack and therefore you can’t delete it.
Although a lot of new System Center admins make this error I must admit it’s in fact quite easy to make the error… Just click next and it’s there…
In SCOM2007R2 the default behavior when creating an override is storing it in the default management pack:
NOTE: Notice that My default management pack name has been changes to something which draws a little bit more attention when you want to click OK to minimize the possibility you click ok to fast. Check here how to do this: http://scug.be/blogs/dieter/archive/2011/05/13/scom-2007-renaming-default-management-pack-display-name.aspx
This is one of the first things to do on my checklist when I open the console at a new client. As this is not ruling out the fact that you once in a while just click ok to fast it helps avoiding some issues.
In SCOM2012 this behavior is changed. Now you need to explicitly select a management pack before you can click ok. Making my linked blog post above completely useless but hey you can’t win them all 
This small adaption will keep a lot of default management packs clean and will score me a lot less free rounds of beer but hey… it’s for a good cause
While we are on the subject make sure you use the proper approach for storing your overrides.
Marnix Wolf MVP has written a nice blog post on the subject: Storing overrides, the good, the bad and the ugly.
His conclusion:
“When storing Overrides, store them in a single unsealed MP which is dedicated only to the MP where you’re making the override for. So overrides for the SQL MP go into the unsealed MP ‘Overrides SQL’ and overrides for the Server OS MP go in to the unsealed MP ‘Overrides Server OS’. This is the only viable and workable option. All other options cause issues, sooner or later.”