Installing the OpsMgr R2 Universal Connector

Microsoft provides some free connectors, for sending alerts from OpsMgr to other management systems.

These connectors are available for download here:

This release of the Operations Manager 2007 R2 Connectors includes the following Connectors:

  • Microsoft System Center Operations Manager 2007 R2 Connector for IBM Tivoli Enterprise Console
  • Microsoft System Center Operations Manager 2007 R2 Connector for HP OpenView Operations for Unix
  • Microsoft System Center Operations Manager 2007 R2 Connector for HP OpenView Operations for Windows
  • Microsoft System Center Operations Manager 2007 R2 Connector for BMC Remedy ARS
  • Microsoft System Center Operations Manager 2007 R2 Universal Connector


This is article is just going to be a quick run down of getting the basic Universal Connector set up and running, and troubleshooting a few issues you might have.


Always start out with the guide that ships with the connectors.  Download the SCInterop_R2_RTM.exe file, and extract it to wherever you keep your OpsMgr source files, updates, hotfixes, and prerequisite files.

Once you extract it, in the \DOCS folder – you will find the Installation guide, the MP guide, and the release notes.

Start with the release notes.  Read through the known issues just so you will be familiar with them in case you have any problems getting it set up that are already known.  There is also a best practices section that is very helpful.

Next up – read the Deployment guide for installing the connector. 


From the release notes and the deployment guide – we can gather some prerequisite and design information:

  • There are 3 primary roles for the Universal connector:
    • Interop Provider role
    • Connector Service Role
    • Connector Configuration UI role

The Connector Service polls the SDK on the RMS for alerts, using a subscription.  The connector service sends these alerts via secure WSMAN HTTPS to the Interop Provider.  The Provider receives these alerts (and alert updates) and also forwards remote system updates back to the connector, to modify the alert (like passing back a ticket ID).  Here is an image from the guide:



  • The Universal Provider and Connector can be installed on Windows Server 2003 (SP1 or later) or Windows Server 2008.  There is a different connector MSI for x86 or x64 OS version.  The Provider application is x86 only, but can be installed on a x86 or x64 OS.
  • The Interop Provider must be installed before the Connector components are installed.
  • It is recommended that the Connector Service and Interop Provider be installed on separate servers.
  • The Connector service can be installed on an OpsMgr server.  However, it can also be installed on a stand alone server, as long as it is in the same domain as the OpsMgr servers.
  • The Connector UI component can be installed on the RMS, but does not have to be.  It can also be installed on the Connector Service server, but again – does not have to be.  It just needs to be installed somewhere that has an OpsMgr console installed.
  • The Connector installation will need to create a database, which the connector will use.  You need to plan to have a SQL 2005 (or later) server available to host this database, with a collation of SQL_Latin1_General_CP1_CI_AS ONLY.
  • There are some prerequisites for each role:
    • Universal Interop Provider
      • The English version of Microsoft Visual C++ 2008 Redistributable Package (x86) (download)
      • WS-Management 1.1 (download)
    • Connector Service
      • The English version of Microsoft Visual C++ 2008 Redistributable Package (x86) (download)
      • WS-Management 1.1 (download)
      • .NET Framework 3.0 SP1 or later (download)
  • We will need a domain account for the connector service.  In general, a good account to use here is the OpsMgr SDK (System Center Data Access) account, as it will need log on as a service rights, and access to the SDK.  I will add this account to the Local Admins group on the Connector and Provider servers.

That covers requirements pretty well.  Here are some examples of how it could be installed/designed:


Smaller environments, test labs, etc:

  • You can install the Connector Service together with the Connector Configuration UI on the existing RMS or a Management Server.  (Don’t install the connector service on a clustered RMS).  Have a dedicated machine for the interop provider (can be a VM)

Larger environments, production use:

  • Use a dedicated server for the Connector Service role together with the Connector Configuration UI.  (can be a VM)
  • Use a dedicated server for the Universal Interop Provider server role.  (can be a VM)


Ok – lets get started deploying.


I will be deploying two dedicated VM’s.

OMCONN – the connector service and connector UI.

OMPROV – the Universal Interop provider.


I start with the pre-requisites. 

  • I deploy two new VM’s using Windows 2008 SP2 x64.
  • I install WSMAN 1.1 on both.  (already included on Windows 2008)
  • I install .NET 3.0 SP1 or later on both.  (added as a Feature on Windows 2008)
  • I install Microsoft Visual C++ 2008 Redistributable Package (x86) on both.  (yes – install the x86 version even if your OS is x64)
  • I install PowerShell on the Connector Service server.
  • I install the OpsMgr Console on the Connector Service Server (for the connector configuration UI component)

Now that pre-reqs are done, we can deploy the connector.

Starting with OMPROV, install the provider.

  • Run SciProviderSetup.msi from the installation media.
  • Choose to install the Universal Provider
  • On the Custom Setup screen – think about a good location to install the provider, this will be the default location where the provider will dump the XML/EVT files from OpsMgr which contain alert data for each alert sent across the connector.
  • The installation complete very quickly.

On the provider server, lets take a look at what got installed.  There is no service, all the configuration was passed to WSMAN.  A new folder was created where you chose to install the provider.  Mine used the default, C:\Program Files\System Center Operations Manager 2007 Providers\.  Browse this folder structure.

  • The alert files will be dropped into \System Center Operations Manager 2007 Providers\Operations Manager 2007 Connector to Microsoft Universal Provider\UnvEvents\FromOpsMgr\
  • The logs are written to \System Center Operations Manager 2007 Providers\Operations Manager 2007 Connector to Microsoft Universal Provider\logs
  • There is a certificate file (servername.cer) located at \System Center Operations Manager 2007 Providers\Operations Manager 2007 Connector to Microsoft Universal Provider.  We will use this certificate in a later step.

Now – moving on to OMCONN, to install the connector.

  • Since my Connector OS is x64, I will run SciConnectorSetup_x64.msi from the installation media.
  • Since I am installing both the connector service and connector UI together, I will choose to install the entire feature of both:



  • On the SQL Server Configuration page – input your SQL server name, instance (if using a named instance) and port (if using a custom port).  You can use a dedicated SQL server for this, or a shared database server.  This database will not be very heavy I/O, nor will it generally grow very large, so using your SQL instance that hosts the OpsMgr database or Warehouse is fine.


***Note – if you are reinstalling the connector again, you can delete/drop the old database, as setup will recreate a new one.  If setup detects an existing one, it will still work and will prompt you if you want to overwrite it.

  • On the Connector Service Login page, type in the credentials for the connector service.  The connector service will be configured to run under these credentials.  This will be used to connect to the SDK on the RMS, and will be used to authenticate to the provider via WSMAN.  I like to use my SDK service account for this, since it already has access to the OpsMgr SDK.  We added this account to the local admins group on both servers during the prerequisites stage.


  • Choose Next, then Install.  In this example – I was reinstalling the connector, and did not drop my old database – so I get this popup error:



  • Setup completes, and I see the Configure Connector screen:



  • Click “Configure Universal Connector”
  • On the next screen – we need to provide:
  • Operations Manager Server (RMS name to connect to the SDK)
  • Universal Provider (Provider server NetBIOS name – NOT FQDN)
  • WS-Man Server credentials  (this is an account that has rights to the provider server via WSMan.


  • Click “Configure” and click Yes on the popup to test the connection to the provider server.


Now – this is the point where failure is the most common.  If all goes well at this point – you will get a successful configuration popup:



However, it is very common for this to fail.  See troubleshooting steps at the end of this article for more information.


  • Click OK on the Successfully Configured screen, and  certificate popup will run which will reach out to the provider server, grab the certificate file, and attempt to install the certificate here and a configure the provider server as a trusted root authority.



  • Click Next to import the certificate, and choose Yes on the confirmation screen.  If it all worked well, you will get the following:



  • You can click Done, and Finish.  Your connector is now working!  (almost)


  • Now – the setup routine creates the SCInterop database, however, it does NOT configure permissions.  These need to be set.  Since we used the SDK account for the Connector service – we need to make sure the SDK account has full access to the database.
  • In SQL Management Studio, connect to the SQL instance hosting the SCInterop database.  Create a new login for your SDK account (if one doesn’t already exist).
  • Open the properties of the SDK login, User Mapping, and check the box next to “SCInterop” database.  Then check “db_owner” in the database role membership:



  • Now that the connector service has access to the SCInterop database, we should be able to start the connector service.  Log back on to the Connector Service role server, and start the “OpsMgr Universal Connector” service.



  • If the service wont start – check the application log.  The connector will log any issues with starting.
  • At this point, we are ready to configure the subscriptions.  Open the OpsMgr console on the Connector Service server.
  • Browse to Administration > Product Connectors > Internal Connectors.
  • Right click the “OpsMgr Universal Connector” and choose properties.
  • Click ADD to add a new subscriptions for alerts that you want to send to the connector.
  • Give your subscription a name.
  • Set the criteria for the alerts.  This will generally be all groups, all targets, and then a very specific criteria for the alerts.  Very common would be “Critical Alerts only” or “All alerts in a custom resolution state”.  This depends on your alert lifecycle policy and how you plan to specify which alerts should be sent across the connector.
  • For this example – I will only send critical alerts across the connector.  (make sure to uncheck “closed”)



  • Click Create and OK.
  • Next, we need to configure the connector properties itself. 
  • Browse to Administration > Product Connectors > Interop Connectors > Universal Connector
  • Right click “OpsMgr Universal Connector” and choose properties.  This will launch the connector configuration UI.
  • On these tabs, you can configure the servers, accounts, polling, and most importantly, which fields from the alert, you want to be delivered to the connector.
  • Make sure you bounce the Connector Service each time you make changes to this page.

Our connector is set up.

It is installed, configured, validated, accessing the database, talking to the provider.

Now, we just need to create some alerts that match our subscription, so they can be sent to the Provider.

I created some test alerts in the console using a test rule.  I also added the views “Connector” and “Forwarding Status” to my alert view.  Sure enough – it is working:


On my provider server, in the location specified for the XML files – I can see:



Here is what got sent:


<?xml version="1.0" encoding="utf-8"?>
<Description>A test event was detected.

The Event ID is: 100.

The Logging Computer is:

The Event Source is: TEST.

The Event Level is: 1.

Event Description = This is a Test event 100

Time event generated = 2010-09-22T17:58:59.0000000-05:00</Description>

<ModifiedBy>Connector Framework Alert Write Action</ModifiedBy>
<Name>Custom - Test alert on event 100 from rule</Name>





Check back later for more stuff to be added to this section.

Comments (9)

  1. Kevin Holman says:

    NV – I agree – this is a BIG issue. For this reason – I cannot and do not recommend that customers alert on BOTH "bad" states of a three state monitor. Because we don’t create a NEW alert when we transition from warning to critical. We simply update the
    old alert. This old alert has already been inspected by SCOM connector, and therefore will never be processed by the connector. This leaves a big hole in the auto-ticketing strategy. I recommend disabling the alerts on the warning threshold states, always.
    If customers MUST have warning level emails, then use a secondary monitor for this and live with duplicate alerts, or use some other method to send the emails, such as orchestrator.

  2. hector says:

    Hi Kevin,

    can you point me to the latest Operations Manager 2007 R2 Connectors management pack?


  3. bill says:

    Hector, just followed the link at the top of this post.

  4. Chris says:

    Hi Kevin,

    We have followed your steps to setup the Interop Provider, but were unable to see the <servername>.cer certificate as what you mentioned above in that folder. Any idea? No error encountered during the installation, and we were able to see all the folders mentioned.


  5. Small / Large? says:

    Hi Kevin,

    What are the borders for Large and Small Environment? I have 800 servers?



  6. Ramesh says:

    Kevin – Do you know if any of these connectors will work with BMC Patrol? Currently we are forwarding alerts from BMC patrol to SCOM 2007 R2 using Quest connector/MP

    Currently Available Connectors

    The following connectors are currently deployable:

    1. Connector for BMC Remedy ARS Operations Manager 2007 Connector for the BMC Remedy Action Request System (ARS)

    2. Connector for HP Operations Manager Operations Manager 2007 R2 Connector for the HP Operations Manager (formerly HP OpenView Operations)

    3. Connector for IBM Tivoli Enterprise Console Operations Manager 2007 R2 Connector for the IBM Tivoli Enterprise Management Console (TEC)

    4. Universal Connector An Operations Manager 2007 R2 Connector that can potentially be installed and configured for any remote system that is hosted on a Windows system or on a supported UNIX system.

  7. NV says:

    Hi Kevin, How does the connector handle Disk alerts when they change from warning to Critical?

    In our environment we send only Critical alerts to OVO. When the disk hits the warning threshold, alert is generated in SCOM, connector doesn’t do anything as its Warning alert. However, when that same alert then becomes Critical the connector still doesn’t
    forward the alert.

    When we get a alert that is Critical at first, these get forwarded to OVO OK.


  8. jay says:

    Hi Kevin,

    I am working on a SCOM 2012 R2 Project that needs to forward alerts to BMC Patrol, I’m currently looking at Seamless Microsoft System Center Operations Manager (OpsMgr 2007 / 2012) to BMC Performance Manager (Patrol). Is there any other connector you can recommend?
    Is there a blog or something about OpsMgr 2012 R2 to BMC Patrol integration? I can’t seem to find one. Thanks.

  9. RS says:

    Hi Kevin, I don’t understand why I can’t see the subscription tab in the universal connector properties. I did the setup based on your post, different times also on different machines but the result is still the same. We have a clustered 2007 R2 CU6. Can
    you help me understand what is the problem?
    Many thanks

Skip to main content