When you create a new distributed application you need to select a management pack to store it in. If you later would like to see in which management pack you stored it, it can be difficult to find a way in the console. But there is at least one way:

1. Navigate to Authoring, Distributed Applications
2. Right-click the distributed  application and select Edit… from the menu
3.  In the Distributed Application Designer Window, select a component group
4. In the component group details pane, click Configure Health Rollup
5. In the Override Properties window, you will see the management pack under “select destination management pack”

In Operations Manager 2007 R2 there is a new view in the auhtoring workspace called Overrides. You can use the override view to edit/view/add overrides. You can also use it to show what overrides you have in which management pack. Click on the Override view and then right-click in the result pane, select personalize view, then select to group items by Override Management Pack. That will give you a list of all overrides, groups by the management pack that stores the override.

I did a Ops Mgr 2007 SP1 upgrade to Ops Mgr R2 upgrade this week too. The RMS was installed on a cluster. There was no problem upgrading the first RMS cluster node. The important thing is to make sure that the Ops Mgr service (SDK, health and config) cant fail over to the second node during the upgrade. That upgrade took around 20 minutes. Then we moved over to the second RMS cluster node, the upgrade was interrupted with the following error:

System Center operations Manager Cross Platform management packs(s) are imported in this management group. Please delete these management packs(s) before upgrading to System Center Operations Manager R2

This management group have never run a beta version of X plat. The only UNIX MPs we had was the default management packs:

• UNIX LogFile Template Library
• UNIX View Library
• UNIX Service Template Library
• Unix Core Library

We deleted them and tried to upgrade the second RMS cluster node again. But without luck. We then figure that maybe the cluster resources must be owned by the second node (found that later in the upgrade guide too) so we moved the cluster over to node 2. The installation was running a little bit longer but was “interrupted before success”. In the logfile we found:

Error:Unable To Connect to SDK To Retrieve MP: Error: The sdk service is either not running or not yet initialized.
Error:StackTrace:    at Microsoft.EnterpriseManagement.DataAbstractionLayer.SdkDataAbstractionLayer.HandleIndigoExceptions(Exception ex)
   at Microsoft.EnterpriseManagement.DataAbstractionLayer.SdkDataAbstractionLayer.CreateChannel(TieredManagementGroupConnectionSettings managementGroupTier)
   at Microsoft.EnterpriseManagement.DataAbstractionLayer.SdkDataAbstractionLayer..ctor(DuplexChannelFactory`1 channelFactory, TieredManagementGroupConnectionSettings managementGroupTier, IClientDataAccess callback, CacheMode cacheMode)
   at Microsoft.EnterpriseManagement.DataAbstractionLayer.SdkDataAbstractionLayer.CreateEndpoint(ManagementGroupConnectionSettings connectionSettings, IClientDataAccess clientCallback)
   at Microsoft.EnterpriseManagement.DataAbstractionLayer.SdkDataAbstractionLayer.Connect(ManagementGroupConnectionSettings connectionSettings)
   at Microsoft.EnterpriseManagement.ManagementGroup..ctor(String serverName)
   at Microsoft.EnterpriseManagement.ManagementGroup.Connect(String serverName)
   at Microsoft.MOMv3.Setup.MOMv3ManagedCAs.DetectXPlatMPs(Session session)
Action ended 11:00:38: _CheckXplatBetaMPPresent.540EA3C0_A5E9_41EA_A585_822C09EA2650. Return value 1.
MSI (s) (FC:94) [11:00:38:424]: Doing action: _AbortXPlatMPFound.540EA3C0_A5E9_41EA_A585_822C09EA2650
Action 11:00:38: _AbortXPlatMPFound.540EA3C0_A5E9_41EA_A585_822C09EA2650.
Action start 11:00:38: _AbortXPlatMPFound.540EA3C0_A5E9_41EA_A585_822C09EA2650.
System Center Operations Manager Cross Platform management pack(s) are imported in this management group. Please delete these management packs(s) before upgrading to System Center Operations Manager R2.
MSI (s) (FC:94) [11:02:09:347]: Product: System Center Operations Manager 2007 R2 — System Center Operations Manager Cross Platform management pack(s) are imported in this management group. Please delete these management packs(s) before upgrading to System Center Operations Manager R2.

We realized that during the upgrade of the Ops Mgr services the node stops the services and they fail over to the first node. So we removed the first node from “available nodes” in the cluster administrator console. That step, “locking” the cluster resources on the node that you upgrade is not really in the upgrade guide. After that the installation was interrupted again, and in the logfile we found

Error: ImportUnixDataItemTransforms: Error: Cannot insert the value NULL into column ‘DatatypeID’, table ‘dbOpsMgr.dbo.UIDatatypeTransform’; column does not allow nulls. INSERT fails.
The statement has been terminated.

So we imported all four default UNIX management packs again, and tried again and it finally worked. Upgrade of the other components of the management group was really easy and fast.

Summary: If you see a error saying that you have cross platform management packs installed and they have to be removed before upgrade, make sure the SDK service is running and it is running on the machine you are trying to upgrade. In some phase of the upgrade you will run the RMS role on the not-yet-upgraded RMS cluster node together with a upgraded ops mgr db. The Ops Mgr db was upgraded together with the first RMS node.

Yesterday the product group launched a new connect portal that will allow you to provide feedback to the OM team as well as participate in surveys that have been traditionally reserved for TAP programs. All you need to do is be registered on connect and you’ll be able to participate. Check it out here.

In Operations Manager 2007 Sp1 when you created a distributed application there was also a group created, including all objects in the distributed application. I cant find a corresponding group in Ops Mgr R2. I used that group for notification, notification for everything in a distributed application. If you want to do the same thing in R2, get notification for all new alerts for all objects in a distributed application, you can

1. Create a distributed application
2. Create a new group with the following forumla “( Object is Contoso - Distributed Application - Spoolers AND ( Display Name Matches wildcard * ) AND True ) “. “Contoso – Distributed Application – Spoolers”  is the name of my distributed application. To build the forumla select your distributed application as class and then “Display Name Matches wildcard *” as expression. Remember to add the forumla under dynamic members.
3. Create a new subscription with the following subscription critiera
Notify on all alerts
raised by any instance in a Contoso - Group - Print Spooler DA group
and with New (0) resolution state
“Contoso – Group – Print Spooler DA” is the name of my group.

When a monitored object, such as a computer or distributed application, goes offline for maintenance, Operations Manager 2007 detects that no agent heartbeat is being received and, as a result, might generate numerous alerts and notifications. To prevent alerts and notifications, place the monitored object into maintenance mode. In maintenance mode, alerts, notifications, rules, monitors, automatic responses, state changes, and new alerts are suppressed at the agent.
More info about maintenance mode here (source).

Boris Yanushpolsk wrote a power shell script to use to see what is actually in maintenance mode. You run the script in Operations Manager command shell. If you want to publish this information to a web page, for example to share it between colleagues, you can use this modified version of the script. You could also schedule the script to make sure you have an updated web page all the time.

 

If you want to get notified when a new maintenance window starts you could use the following script to get a notification. This script will send you an e-mail with information regarding new maintenance windows. It will also log the information to a logfile that you later can use to generate reports for maintenance windows within your environment. Read this post about generating reports based on logfiles. Download the script here. Remember to rename the file to .ps1 and run it from Operations Manager command shell. The following picture shows a notification e-mail from the script.

With default settings the script will look for maintenance windows created in “now-72 hours”. You can change this with the $seconds, $hours and $hours variable. For example if you schedule the script to run every two minute you want to change it to $minutes=2. If you want the script to generate a logfile you will need to change $log to $true. If you want to get notified with e-mail you need to specify $e-mail=$true and then smtphost, from, to and subject.

Big thanks to Marco Shaw (power shell MVP), read his blog here.