Microsoft provides some free connectors, for sending alerts from OpsMgr to other management systems.
These connectors are available for download here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=592e4143-c5c8-4270-9a7a-cd0a31ab3189&displaylang=en
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 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
- Connector Service
- 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.
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)
- 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)
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.
- 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.
- 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.
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:
The Event ID is: 100.
The Logging Computer is: OMTERM.opsmgr.net.
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
Hiç yorum yok:
Yorum Gönder