Update 11-26-2009: Microsoft has documented this problem as a bug but only for internal purposes. Only when more customers are having similar problems, they will give it prority for fixing. But, if you do have this problem you can fix it on your own. Using the descriptive explanation in this blog.
Sunday, November 15, 2009
Saturday, November 14, 2009
SCOM: Sealing 'Operations Console-build' Management Packs
This blog is about the problems you can run into when you seal a management pack which is build from the Operations Console and deploy it in another Management Group.
When you create a management pack from the Operation Console a few standard items are added by default like some references to standard libraries.
If you want to delegate a logical group of computers combined with some views to a group of administrators for monitoring, usually you do the following:
This will work great in the Management Group the MP is created in, but when you seal this MP and want to use it in another SCOM Management Group, a problem arrises. e.g. Creating a MP in a test SCOM Management Group, sealing the MP and deploying the MP in a production management group.
The problem: Although the group is likely to be populated with objects that comply with the group dynamic inclusion rules, none of the items show up in the State View.
The cause: The State View is targeted at the 'My Computer Group' but under the hood the group's GUID is used instead of it's ID. The GUID is the 'unique?' BaseManagementID within the Management Group. This will only get noticed when you use this MP in another Management Group as a sealed MP. As a unsealed MP the group, frankly, uses the 'same!' GUID and the view will work.
The solution: Edit the MP XML file manually and replace the GUID within the view's target to the ID of 'My Computer Group'. You can find the ID in the 'Language Pack'-section of the MP. Note that you'll find two targets. This concerns the subelement Target and not the attribute from the view element itself.
Example:
Orginal XML
New XML
You might say, "why is this a problem, i'll just won't seal my MP's". Well you could do that, but most people think you should develop a MP in one environment and deliver the MP as a sealed box to the other environment. This way it's not possible for a MP to have a higher version number in e.g. a production environment than the same MP in your test/development environment.
And remember even if you dó choose to work without sealing, and you and your collegues agree nót to add any changes to a MP in your production environment, one day it will happen. And then you release your amazing new version of the MP, following the standard release process, and all changes of your collegue could get lost.
When you create a management pack from the Operation Console a few standard items are added by default like some references to standard libraries.
If you want to delegate a logical group of computers combined with some views to a group of administrators for monitoring, usually you do the following:
- Create new Management Pack
- Create a group
- For example: My Computer Group
- Create dynamic inclusion rules (like "OU matches wildcard "*Web Servers*"
- Create a view
- State view (for example)
- Data related to "Windows Computer"
- Data contained within group "My Computer Group"
This will work great in the Management Group the MP is created in, but when you seal this MP and want to use it in another SCOM Management Group, a problem arrises. e.g. Creating a MP in a test SCOM Management Group, sealing the MP and deploying the MP in a production management group.
The problem: Although the group is likely to be populated with objects that comply with the group dynamic inclusion rules, none of the items show up in the State View.
The cause: The State View is targeted at the 'My Computer Group' but under the hood the group's GUID is used instead of it's ID. The GUID is the 'unique?' BaseManagementID within the Management Group. This will only get noticed when you use this MP in another Management Group as a sealed MP. As a unsealed MP the group, frankly, uses the 'same!' GUID and the view will work.
The solution: Edit the MP XML file manually and replace the GUID within the view's target to the ID of 'My Computer Group'. You can find the ID in the 'Language Pack'-section of the MP. Note that you'll find two targets. This concerns the subelement Target and not the attribute from the view element itself.
Example:
Orginal XML
<view id="myview1234" target="systemlib!windows computer">
<columns>
....
<columns>
<target>EA99500D-8D52-FC52-B5A5-10DCD1E9D2BD</target>
</view>
New XML
<view id="myview1234" target="systemlib!windows computer">
<columns>
....
<columns>
<target>$MPElement[Name="My.Computer.Group.ID"]$</target>
</view>
You might say, "why is this a problem, i'll just won't seal my MP's". Well you could do that, but most people think you should develop a MP in one environment and deliver the MP as a sealed box to the other environment. This way it's not possible for a MP to have a higher version number in e.g. a production environment than the same MP in your test/development environment.
And remember even if you dó choose to work without sealing, and you and your collegues agree nót to add any changes to a MP in your production environment, one day it will happen. And then you release your amazing new version of the MP, following the standard release process, and all changes of your collegue could get lost.
Subscribe to:
Posts (Atom)
