If you have not seen it yet, Microsoft has now released a number of connectors for Ops Mgr 2007 R2. The System Center Operations Manager 2007 R2 Connectors provide System Center Operations Manager 2007 R2 alert forwarding to remote systems, such as an Enterprise Management System (EMS) or service desk system. One of the connectors that Microsoft has released is the universal connector, a connector that can be installed and configured for potentially any remote system that is hosted on a Windows system or on a supported UNIX system. More info and download here.

Each deployed Operations Manager 2007 R2 Connector has the following components:

Interop Provider – This service is installed on a Windows or UNIX server in a supported remote system environment and is automatically started at install. The Interop Provider receives alerts from the Connector Service in the Operations Manager 2007 R2 environment and forwards them to the supported remote system through APIs of that system. The Interop Provider also sends updates on those events back to the Connector Service.

Connector Service – This service is installed on a server in the Operations Manager 2007 R2 environment and is automatically started after configuration is completed. The Connector Service gathers alerts from the Operations Manager 2007 R2 RMS and sends them to the Interop Provider that is installed on a remote system server. The Connector Service also receives updates from that Interop Provider for remote system events that were created from Operations Manager alerts.

Connector Configuration UI – This configuration dialog box is installed on a server on which an Operations Manager 2007 R2 console is installed, and it becomes an integrated component in that console. Use the Connector Configuration dialog box to configure communications for Operations Manager 2007 R2 servers with remote system servers. Tabs on the Connector Configuration dialog box also provide for mapping Operations Manager alert properties to properties of the remote system’s events and for configuring the High Availability feature.

The installation was pretty simple, the manual explain the different steps in a good way. You install the “Interop Provider” and the connector service. The connector configuration UI needs to be installed on a machine with the Ops Mgr R2 console as there is a integration between the two. It is not possible to upgrade any pre-RTM version of the connector, so if you have been running a pre-RTM version make sure you uninstall it before you tries to install the RTM version. When the installation is complete you will see a new connector in the console

On the Ops Mgr Universal Connector you can configure where your EMS server is, how ofter to synchronize, where your Ops Mgr server is and of course which alert fields to synchronize. You will also see a new connector under Internal Connectors. This is where you can configure which alerts that will be forwarded to the EMS server. With default settings all alerts are forwarded.

When a new alert is generated a XML file will be generated on the EMS server side. In this example I generate an alert for a event in the event viewer.

As you can see below, the alert has ID 8f474850-7308-41f8-ba40-0fb27b72084e, and there are XML files generated for the alert. The filesname is <AlertID>. <sequence number>.XML. The sequence number starting at 1, is added so that if an alert is forwarded and not processed in a timely manner of if an alert is updated multiple times in a short time period, the files are not overwritten. Overwritting the files could result in lose updates. It is important that the EMS system process the file with the lower numbers first so that the sequence of activities is not lost. Note that if you get two alerts at the same time they will be named <AlertID001>.1.XML and <AlertID002>.2.XML, the .X. number is common for the management group, and not a sequence number of each alert ID.

The next step is that the remote system needs to acknowledge (event type = 2) the alert back to Ops Mgr. This is done with a new XML file. Dont forget to delete the first XML file, so you dont process it again.

 

If you then want to update (event type = 1) the alert you generate a new XML file, in the following example the resolution state is set to 100. You can use the same XML code to update the resolution state to 255, in other words close an alert.

 

There are a couple of different event types you can use with the universal connector

• <EventType>0</EventType> = New Ops Mgr alert being forwarded
• <EventType>1</EventType> = Update to an Ops Mgr alert being forwarded to the remote system or update to the event/ticket on a remote system being forwarded to Ops Mgr
• <EventType>2</EventType> = Remote system acknowledgement of a new alert
• <EventType>3</EventType> = Remote system acknowledgement of an alert update

Summary: You can use the Universal connector to forward alert in XML or EVT format to remote systems. Remote systems can then generate files that the connector picks up and process in Operations Manager, for example update resolution state of an alert. You can run the connector against both Microsoft and non-Microsoft systems.

This is a example how you can configure a monitor to generate an alert if a log file contains a word more then X times during Y minutes. In the following example I have configure a monitor to generate a critical alert if the logfile contains “error” more then four times during a minute. The following example look in any file named logfile*.log in the C:\logfiles folder. It the application writes a “success” to the logfile, the monitor will be reset back to healthy.

1. Go to the Authoring workspace and create a new monitor, Log Files/Text Log/Repeated Event Detection/Event Reset

2. General
Name: Contoso – Logfile – Repeated Event w event reset
Monitor Target: for example Windows Server 2008 Computer (more about targeting here and here)
…next

3. Single Generic Log
Directory: C:\logfiles
Pattern: logfile*.log
…next

4. Single Event Expression
Parameter Name: Params/Param[1]
Operator: Contains
Value: success
…next

5. Repeated Generic Log
Directory: C:\logfiles
Pattern: logfile*.log
…next

6. Repeated Event Expression
Parameter Name: Params/Param[1]
Operator: Contains
Value: error
…next

7. Repeated Event Description
Counting mode: Trigger on count
Compare Count: 4
Based on items occurrence within a time interval: 1 Minutes
…next

 

8. Health
Event Raised: Healthy
Repeated Event Raised: Critical
…next

9. Alerting
Check “Generate alerts for this monitor”
Input a suitable alert description, also try include a couple of the data parameters
…create

If any file named logfile*.log in the C:\logfiles folder now writes four “error” within one minute an critical alert will generated. Then, if a “success” is any file the monitor will be set back to healthy state. Step 3 and 4 configure the event that will set the monitor back to healthy.

(click on a picture twice to enlarge it)

Some time ago I posted an article about gateway servers, Ops Mgr R2 and Server 2008. This week I have extended that scenario by adding two more management servers and one more gateway server.

To make this scenario work I had to configure both my gateway servers to use corp-MS03 and corp-MS02 as primary and secondary management servers. You can do that with operations manager command shell.

Log on to a machine with command shell installed, for example a workstation. Run the following script (save it as a .ps1 script file)

$primaryMS = Get-ManagementServer | where {$_.Name -eq 'corp-ms02.corp.contoso.local'}
$failoverMS = Get-ManagementServer | where {$_.Name -eq 'corp-r2.corp.contoso.local'}
$gatewayMS = Get-GatewayManagementServer | where {$_.Name -eq 'dmz01'}
Set-ManagementServer -GatewayManagementServer: $gatewayMS -primarymanagementserver: $primaryMS -FailoverServer: $failoverMS

That script configure the gateway server, DMZ01, to use corp-MS02 as primary management server and corp-R2 as failover management server. When you run this command you have to be aware that when the current management server gets this update it will stop accepting connections from your gateway server (if it is not primary or failover management server in the new configuration). That could result in a orphaned gateway server, the gateway server is not allowed to communicate with any management server. If this happends you will have to logon to your gateway server, check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Server Management Group\<Management Group Name>\Parent Health Services\0 and look for the authenticationName string. You must then run the set-managementserver cmdlet again and change the management server back to the one in the register. To make sure you don´t end up with orphaned gateway servers use your current management server as failover server in your script, then the gateway server can receive new configuration from the new failover server (current management server) and when you have confirm the configuration change, you can update the failover server for the gateway server.

To verify that your gateway server has received the new configuration you can look in the OpsMgrConnector.Config.XML file on your Gateway server, search for Parents in the file. Default location is C:\Program Files\System Center operations Manager 2007\Health Service State\Connector Configuration Cache\.

You can also run the following command shell commands to see he primary and failover server for a gateway server

Get-GatewayManagementServer | where {$_.Name -like 'DMZ01'} | Get-PrimaryManagementServer
Get-GatewayManagementServer | where {$_.Name -like 'DMZ01'} | Get-FailoverManagementServer

If everything looks ok, you could now run the power shell script again, and update the failoverMS to the correct failover management server.

To configure the agent to communicate with the two gateway servers I ran the following two scripts. corp-r2 was the primary/only management server for the agent when I started.

$primaryMS = Get-GatewayManagementServer | where {$_.Name -eq 'dmz01'}
$failoverMS = Get-ManagementServer | where {$_.Name -eq 'corp-r2.corp.contoso.local'}
$agent = Get-agent | where {$_.Name -eq 'DMZ-A01'}
Set-ManagementServer -AgentManagedComputer: $agent -PrimaryManagementServer: $primaryMS -FailoverServer: $failoverMS

after I verified that the agent had recived the new configuration I ran

$primaryMS = Get-GatewayManagementServer | where {$_.Name -eq 'dmz01'}
$failoverMS = Get-gatewayManagementServer | where {$_.Name -eq 'dmz-02'}
$agent = Get-agent | where {$_.Name -eq 'DMZ-A01'}
Set-ManagementServer -AgentManagedComputer: $agent -PrimaryManagementServer: $primaryMS -FailoverServer: $failoverMS

The result of these commands is that my agent (DMZ-A01) can communicate with both gateway servers. Both my gateway servers can communicate with both my management servers. If I shutdown DMZ01 my agent, DMZ-A01, failover to DMZ-02. If I start DMZ01 again the agent will automatic return to DMZ01. If I shutdown corp-MS02 my gateway server will automatic failover to corp-ms03. If I shutdown one gateway server and one management server the agent will still communicate with the management group.

If you want to see the active node for a cluster group you can do that with a task. Create a task target to “Cluster Node”, then add the following command line configuration

Full path to file: %WINDIR%\system32\cluster.exe
Parameters: $Target/Property[Type="MicrosoftWindowsClusterManagementLibrary6065680!Microsoft.Windows.Cluster.Node"]/ClusterName$ group

You can then run the task from the Cluster Node State view in the cluster MP. The task will list status for all available resource groups.

A couple of days I ago when I was working with a SQL cluster I found something interesting. I had problem with a SQL cluster, Operations Manager 2007 R2 only found the first network name in my cluster group, not the one for my SQL cluster. After some time I found the following text in the SQL management pack guide:

Having a SQL Server cluster resource group that contains more than one network name resource might mean that the clustered SQL Server resource is not monitored. For more information, see Knowledge Base article 919594.

…and KB 919594 tells you

To resolve this issue, configure existing resources in the cluster group so that System Center Operations Manager or MOM detects the virtual server, or create and configure the necessary resources. For example, you may have to create a generic application resource that does nothing. This generic application resource will enable System Center Operations Manager or MOM to discover the virtual server on which the resource is hosted.

Note If more than one Network Name resource is configured in a group, System Center Operations Manager or MOM uses the first network name that it detects as the name of the virtual server..

As soon as I had re-organized my cluster resources for SQL into a new cluster group Operations Manager 2007 R2 found the other cluster resource group and the SQL running on it. It also discovered all the SQL components for example databases and logical disks.

There is a KB article about this, KB959865, that shows you another solution, where you can do a override and enable “Multiple Servers Discovery” within the cluster MP.