OCS R2 Management Pack for SCOM Snafu (No display name for the classes)
Where I work we have OCS R2 deployed. The OCS ops team is not happy with the level of alerting despite several tuning efforts for this management pack. We finally decided to just keep it installed for “information” and develop our own custom management pack that will include classes for OCS, GroupChat, and FaceTime IM Auditor. I could break these out by application, but since this MP will be pretty light I will probably gather the requirements and create one management pack that would discovery all of these applications. Down side to this is, of course, that any changes will be pushed to the other applications even if the monitors were not targeting them. I will deal with it.
Anyway, if you are not fortunate enough to have a SCOM administrator who can create a new mp for you, then you might be unhappy with a few issues in this R2 MP such as the LACK of a display name for the classes. This is problematic when creating custom views targeting the OCS classes, as well as setting up subscriptions. Whenever you set these up, you will not know what your target is. That might be an issue for you or your organization. This is what you will experience if you do not modify the management pack:
Custom Alert View:
Go to your “Workspace” and create a new Alert View:
Now change the “Show data related to:” box so that you have OCS R2 Enterprise Edition selected:
Now look at what you have (What class is THAT?):
Now if you want to set up a subscription for this class this will be your experience:
Create a new subscription and select “raised by instance of a specific class”:
Filter by ‘Enterprise’ and select the OCS R2 EE class:
Look at the results:
Your SCOM admin quits, you hire a new guy, something is wrong with the subscription, how is he supposed to know? Of course you could name it and give it a description, but how do you know that the subscription hasn’t been modified to another OCS R2 class that also has no display name? Well you won’t know unless maybe you dive into the notifications management pack. Who wants to do that?
Now, I have a feeling there will be no updates to the current release of the OCS R2 management pack. Therefore, to fix this, I will export the MP via power shell and modify the unsealed MP in the authoring console (give the classes display names). Then I will seal it, delete the original and any dependencies in my SCOM configuration group, then import this modified sealed vendor mp and the dependency management packs.
For the OCS dependent custom management packs you have (override, custom, etc) you will have to update the references section of the MP to now use the new OCS MP. If you don’t do this, then you will not be able to import them. It’s pretty easy to update references for unsealed custom management packs (you can just edit the XML). If they are sealed custom MP’s then you will have to do this via the authoring console with the unsealed custom MP, then seal it, and re-import it.
*Keep in mind that you should do this in a lab first, test it, and then understand that this is NOT supported by MSFT. This means, if you ever have issues with the OCS MP or one of it’s workflows, etc., then you would be in an unsupportable situation. Also, if the OCS team does release an updated MP that is upgrade compatible, then you will have to probably delete this MP first. Therefore do these steps at your own risks!*
Open up the SCOM power shell and export the OCS MP from your configuration group:
Now that it is unsealed, open it up in the Authoring Console and look at the various classes. You will notice most are missing a name for the display string. Naughty, naughty!:
Double click on any of those classes that are missing a display name and add it yourself (warning may require a lot of typing):
Now view your mastery at work in the Authoring console and save that updated MP:
Now seal this mp using mpseal and your friendly little certificate:
Before you can import this modified sealed mp, you will have to delete your management packs that are referencing/dependant on the original OCS MP and then delete it as well. Once you do this, you can import this updated MP which has the incremented number of .22 instead of .21.
After the import verify it is there and the correct version:
Now step through creating a view or subscription again (for this example we will use a subscription):
Viola (that was easy, but time consuming and really not our job)!
Happy authoring/modification and don’t forget to update the MP’s that were dependent on the original OCS MP so that you can use them.