Managing the Allowed List for the Operations Manager CI Connector with PowerShell

  • Comments 8
  • Likes

The Operations Manager CI (Configuration Item) Connector automatically synchronizes discovered managed objects from Operations Manager to the Service Manager CMDB. For example, right out of the box, if you create a CI connector between Operations Manager and Service Manager the Windows computers discovered and managed by Operations Manager will automatically be moved to the Service Manager CMDB. That is because the Windows Computer management pack is imported in both Operations Manager and Service Manager out of the box.

If you want data of different classes like SQL Servers, databases, IIS web servers & sites, Exchange servers, etc. to automatically flow from SCOM to SCSM over the CI connector, all you have to do is import the same management pack into SCOM and SCSM. For example, if you want the Exchange servers to flow from SCOM to SCSM, just import the Exchange MPs into SCOM and SCSM. Technical footnote: All you really need are the MPs that contain the model (classes/properties, and relationship types), but importing other kinds of MPs is harmless if you are not sure which MPs contain the model information.

Operations Manager manages and monitors things at a very detailed level in some cases depending on the management pack. Since we don’t want to clutter up the SCSM CMDB out of the box we limit what kinds of data automatically flow over the CI connector. Only objects of classes that derive from classes in the ‘Allowed List’ will be synchronized.

Some classes of objects that you might want to flow from SCOM to SCSM might not derive from classes in the Allowed List out of the box. In that case, you can mange the Allowed List using PowerShell. Here’s how….

First, open PowerShell on a SCSM management server and add the SCSM PowerShell snapin.


Now, run get-command like this to see all of the commands related to managing the Allowed List.


Now, run Get-SCSMAllowList to see what the out of box list of classes in the Allowed List is:


There you go. Anything that derives from one of those classes will be synchronized over the CI connector into the Service Manager CMDB out of the box as long as the same management pack is imported into both SCOM and SCSM.

You can add classes to the list like this:


Remove is basically the same:


And you can reset the list back to the way it comes out of the box like this:


Note: This is a new PowerShell cmdlet that is only available in the RC builds (soon to be released).

Managing the Allowed List for the Operations Manager CI Connector with PowerShell

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Your description of the management-pack concept leads me to this question: How might I define a distributed application in SCOM that's specific to my company (creating my own management pack in SCOM) such that when I import the MP into SCSM, Service Manager sees a Microsoft.SystemCenter.BusinessService object?

    Suppose I have a system called XYZ-System. There's no MP from the vendor. I'd like SCOM to monitor the system's components, so I create a distributed app in SCOM called XYZ-System, with its own MP. I import that MP into SCSM, and I see XYZ-System under Business Services in the Config Items superbar, but XYZ-System is not of type Microsoft.SystemCenter.BusinessServices; rather it's of type XYZ-System, a completely new type!

  • @Adam -

    When you create a Distributed Application a new singleton class is created that derives from a class called 'System.Service'.  When you import that MP into SCSM it still derives from System.Service.  The only difference is that in the version of the common model that is in Service Manager there are some additional properties and relationship types for System.Service that are now inherited to your singleton class.  The 'Business Services' view in the Service Manager console shows all those services which derive from System.Service regardless of if they are distributed apps from SCOM or 'business services' created in SCSM.  Because your new singleton class derives from System.Service you can now set additional properties on it like the operating hours, status, etc. and relationship like the service owner user, etc.

    Hope that helps clear it up!

  • Travis, your explanation helps. At this point, I'd like to report on those System.Service objects. I know you indicated in your response to my comment on your blog that information on the SCSM database schema is forthcoming from Microsoft. Nevertheless, could you tell me at this time where I can find the System.Service objects in the DWDatamart database?

  • @Adam -

    ServiceDimVw is the view that you can look at the services on.  It's in the DWDataMart DB.

  • I don't see the SCOM distributed apps coming into the ServiceDimvw view in the dwdatamart, even though their classes are on the allowlist, etc., according to the above instructions. Should I be sealing the SCOM MP's before importing into Service Manager, and only then will they synch with the datamart?

  • @Adam -

    Yes, you'll need to seal those MPs.  We only move sealed MPs to the DW via MP Sync.

  • How do I found out the class name from 3rd party management packs ?

  • Hi Travis, great post!

    Is there a way to exclude only one object from class? For example exclude one windows computer to be imported in the CMDB?