In the first part of this series I showed how to synchronize objects that live in SCOM to the Service Manager CMDB. This works fine, but in some situations it’s possible that objects will not be visible – because they do not synchronize as expected. In this second part I will show you why and how to solve this problem. For this example I will use the class “IIS 7.0 ASP.NET Application Endpoint”. One of my customers needed this class in the CMDB, so this is a real world example.

When you imported the IIS7 Management Pack in SCOM, objects of the mentioned class will be automatically discovered. You can make those objects visible by using the Discovered Inventory view (or of course by creating a specific view).

By using the Discovered Inventory view you can also see that this class comes from the Management Pack named “Windows Server 2008 Internet Information Services 7.0”. That means that you have to import this Management Pack into Service Manager first. Details about this can be found in the first part of the series.

Caveat: It’s possible that you have to import other Management Packs as well because of references. If your Management Pack import fails, you will see a message telling you what other management Packs need to be imported first.

After a successful import, you have to create a view to display objects of the desired class. Because we just imported the IIS7 Management Pack, the needed class can be used to create the view.

After that, reconfigure the SCOM connector to synchronize objects of the new Management Pack and start the synchronization afterwards. Maybe you have to hit the Refresh button to make the new Management Pack visible for selection.

After a successful synchronization you will see that your view does not show any objects. Restart the Service Manager Console to make sure that this is not a caching problem.

The reason why you will not see any objects is that Service Manager uses a filter on the SCOM connector. This way, you have detailed control of what will get imported to the CMDB using the SCOM connector. Without this filter functionality, tons of objects would be synchronized to the CMDB that are not of any interest. For our special need, we have to add an entry to the filter, so that the connector will synchronize the objects of the class we need.

To display and configure the filter you must use Powershell and add the default Service Manager Snap-In “smcmdletsnapin”. After the import, use the cmdlet “get-scsmallowlist” to display the actual filter configuration. You will now see all the classes that are synchronized by default. Everything that derives from the displayed classes will be synchronized as well.

Since our class (IIS 7.0 ASP.NET Application Endpoint) is not on the list and it does not derive from one of the listed classes, we have to add the class to the filter. To find out the exact name of the needed class you can use the Operations Manager Shell on one of the SCOM Servers. Using the cmdlet “get-monitoringclass” you can display all classes. Use a where-statement to narrow down the displayed classes. At the end, note the name of the class that you need. In our example the name is “Microsoft.Windows.InternetInformationServices.2008.AspNetWebApplicationEndpoint”.

Now switch back to the Powershell Console on the Service Manager Server and add the class name to the filter by using the cmdlet “add-scsmallowlistclass”.

Caveat: If you want to reset the filter to the default configuration, you can use the cmdlet “reset-allowallowlist”.

After the filter is configured with the new class, you have to start the synchronization manually. After a couple of minutes you will see the exact same objects that are visible in SCOM in your view in the Service Manager Console. Maybe you have to restart the Console.

By using the procedure in this post, you can bring any object that lives in SCOM to the CMDB – and you have full control over the SCOM connector filter. That’s pretty cool!

See you
Marcel