Storing Overrides: The Good, The Bad and The Ugly.

It might seem like flogging a dead horse, but sometimes I bump into situations which really puzzle me. Hence this posting in order to shed some light on this topic which seems to confuse many SCOM users.

What am I talking about?
I am talking about storing overrides. As we all know, every sealed MP requires some or more modifications. These modifications are also named Overrides. These Overrides need to be saved in a MP. Since the MP where the override is meant for, is sealed the Override can’t be saved in that MP. So an unsealed MP is required.

So far so good
Up to this point people agree with each other. But now the difference in views starts to kick in. Because now this question has to be answered: WHAT unsealed MP does one use for it? And actually there is only one GOOD answer possible here. But let’s take a look at the answers people can give and what the effects are on the SCOM R2 environment, or better the ‘modus operandi’.

The Bad
Seriously, this is BAD. Let’s assume we have three sealed MPs in place: Server OS, SQL and IIS. All related guides have been read (and understood!). Based on those guides and the requirements of the organization, the MPs have been modified. The resulting Overrides are saved into a single unsealed MP.

Since we’re good and law abiding citizens we DID’NT use the Default MP, but made a new unsealed MP named ‘Modifications Company X’. Let’s pour it into a picture so we’re all thinking the same here:

We really feel good about our selves. Why? Well we made a new unsealed MP AND we didn’t use the Default MP. Wow! We ROCK! Or don’t we?

Let’s take it a step further in order to see what will happen when the SQL MP gets an update. The guide tells it all and boy, we WANT that new version of the SQL MP. But the newest version of the SQL MP doesn’t allow an upgrade of any previous version of the SQL MP. No. The previous version must be removed first.

But now some alarm bells start to ring. When creating an override and storing it in an unsealed MP, a dependency is created as well. So in this case the SQL MP has become dependent of the unsealed MP  ‘Modifications Company X’. As a result the SQL MP can only be removed AFTER that unsealed MP, containing the overrides for SQL, is removed first.

And now we’re in trouble. Yes, we can remove the ‘Modifications Company X’ MP. But doing so will also remove the overrides made for the Server OS and IIS MP. And that’s not what we want. No way! Yes, we can remove the MP temporarily and import it back in after the old SQL is removed and the new SQL MP imported. But since the new SQL MP is totally different compared to the old version, the old overrides set for SQL aren’t valid anymore. This can cause some strange side effects in your SCOM environment.

So basically this situation is just as bad as putting ALL overrides in the Default MP. So simply don’t do that.

I see similar situations where the unsealed MPs containing the overrides have names like Server X or Server Y. So unsealed MP ‘Server X’ contains overrides for the Server OS MP, SQL MP and IIS MP targeted against Server X. This is equally bad or even worse since you’re creating TONS of dependencies! So simply don’t do that either.

Let’s take a look at another scenario I sometimes bump into. Isn’t good either.

The Ugly
OK. We learned our lesson well. We know about the bad situation and we don’t want to go there.

Let’s assume we have the same three sealed MPs in place: Server OS, SQL and IIS. All related guides have been read (and understood!). Based on those guides and the requirements of the organization, the MPs have been modified. The resulting Overrides are saved into a multiple unsealed MPs.

But while we were at it, we didn’t stop. So the SQL MP doesn’t have one unsealed MP containing all the SQL related overrides. No. Because we made many overrides: for SQL Server 2000 but also SQL Server 2005 and let’s not forget SQL Server 2008, SQL Server 2008 R2 and generic SQL overrides.

We really want to differentiate between those overrides so we created five unsealed MPs only for the SQL MP: ‘Overrides SQL 2000’, ‘Overrides SQL 2005’, ‘Overrides SQL 2008’, ‘Overrides SQL 2008 R2’ and ‘Overrides SQL’…

Boy! Are we smart or what?

Let’s pour it into a picture so we’re all thinking the same here:

Let’s take it a step further in order to see what will happen when the SQL MP gets an update. But the newest version of the SQL MP doesn’t allow an upgrade of any previous version of the SQL MP. The previous version must be removed first.

Most sealed MPs come in different components. So the SQL MP for monitoring SQL 2000, 2005 and 2008 consists out of 7 components. With the 5 unsealed MPs – for the overrides - we added our selves, there are 12 component MPs in place only for monitoring SQL. The more the merrier! Or not? Soon with all the references we created (per unsealed MP a reference is created) we find ourselves in a world of spaghetti.

Of course, so many MPs create a burden on the total amount of required administration of SCOM. And is prone to error as well. One could easily remove one MP to many with some unneeded results. So this is a bad situation and one to stay away from as well.

Let’s move on to the scenario which is best and should be followed to the letter.

The Good
Phew! We’ve come a long way. Covered many miles and learned our lessons.

Let’s assume we have the same three sealed MPs in place: Server OS, SQL and IIS. All related guides have been read (and understood!). Based on those guides and the requirements of the organization, the MPs have been modified. The resulting Overrides are saved into a per MP single dedicated unsealed MPs.

This  sounds good doesn’t it? Let’s visualize it so we’re on the same line:

Let’s take it a step further in order to see what will happen when the SQL MP gets an update. But the newest version of the SQL MP doesn’t allow an upgrade of any previous version of the SQL MP. The previous version must be removed first.

We stored all SQL MP related overrides into a single SQL dedicated unsealed MP, ‘Overrides SQL’. Whether it was an override for a Rule targeted against SQL 2000 or a Monitor targeted against SQL Server 2008 R2, we used the same single SQL dedicated unsealed MP.

So when we want to remove the SQL MP we must first remove the single unsealed MP containing the SQL related overrides. This is just one MP and only touches the SQL MP and nothing more.

Now we’re in the clear! Nice! No unwanted side effects or tons of dependencies.

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.