Here’s another new Knowledge Base article we published today. This one goes through some common troubleshooting tips for eliminating Event IDs 2115 in Operations Manager:

=====

Symptoms

In Operations Manager, one of the performance concerns surrounds Operations Manager Database and Data Warehouse insertion times. The following is a description to help identify and troubleshoot problems concerning Database and Data Warehouse data insertion.

Examine the Operations Manager Event log for the presence of Event ID 2115 events. These events typically indicate that performance issues exist on the Management Server or the Microsoft SQL Server that is hosting the OperationsManager or OperationsManager Data Warehouse databases. Database and Data Warehouse write action workflows run on the Management Servers and these workflows first retain the data received from the Agents and Gateway Servers in an internal buffer. They then gather this data from the internal buffer and insert it into the Database and Data Warehouse. When the first data insertion has completed, the workflows will then create another batch.

The size of each batch of data depends on how much data is available in the buffer when the batch is created, however there is a maximum limit on the size of the data batch of up to 5000 data items. If the data item incoming rate increases, or the data item insertion throughput to the Operation Manager and Data Warehouse databases throughput is reduced, the buffer will then accumulate more data and the batch size will grow larger. There are several write action workflows that run on a Management Server. These workflows handle data insertion to the Operations Manager and Data Warehouse databases for different data types. For example:

• Microsoft.SystemCenter.DataWarehouse.CollectEntityHealthStateChange
• Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData
• Microsoft.SystemCenter.DataWarehouse.CollectEventData
• Microsoft.SystemCenter.CollectAlerts
• Microsoft.SystemCenter.CollectEntityState
• Microsoft.SystemCenter.CollectPublishedEntityState
• Microsoft.SystemCenter.CollectDiscoveryData
• Microsoft.SystemCenter.CollectSignatureData
• Microsoft.SystemCenter.CollectEventData

When a Database or Data Warehouse write action workflow on a Management Server experiences slow data batch insertion, for example times in excess of 60 seconds, it will begin logging Event ID 2115 to the Operations Manager Event log. This event is logged every one minute until the data batch is inserted into the Database or Data Warehouse, or the data is dropped by the write action workflow module. As a result, Event ID 2115 will be logged due to the latency inserting data into the Database or Data Warehouse. Below is an example Event logged due to data dropped by the write action workflow module:

Event Type: Error
Event Source: HealthService
Event Category: None
Event ID: 4506
Computer: <RMS NAME>
Description:
Data was dropped due to too much outstanding data in rule "Microsoft.SystemCenter.OperationalDataReporting.SubmitOperationalDataFailed.Alert" running for instance <RMS NAME> with id:"{F56EB161-4ABE-5BC7-610F-4365524F294E}" in management group <MANAGEMENT GROUP NAME>.

Event ID 2115 contains 2 significant pieces of information. First, the name of the Workflow that is experiencing the problem and second, the elapsed time since the workflow began inserting the last batch of data.

For example:

Log Name: Operations Manager
Source: HealthService
Event ID: 2115
Level: Warning
Computer: <RMS NAME>
Description:
A Bind Data Source in Management Group <MANGEMENT GROUP NAME> has posted items to the workflow, but has not received a response in 300 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectPublishedEntityState
Instance : <RMS NAME>
Instance Id : {88676CDF-E284-7838-AC70-E898DA1720CB}

This particular Event ID 2115 message indicates that the workflow Microsoft.SystemCenter.CollectPublishedEntityState, which writes Entity State data to the Operations Manager database, is trying to insert a batch of Entity State data and it started 300 seconds ago. In this example the insertion of the Entity State data has not yet finished. Normally inserting a batch of data should complete within 60 seconds. If the Workflow Id contains Data Warehouse then the problem concerns the Operations Manager Data Warehouse. Otherwise, the problem would concern inserting data into the Operations Manager database.

Cause

As the description of Event ID 2115 states, this may indicate a database performance problem or too much data incoming from the agents. Event ID 2115 simply indicates there is a backlog inserting data into the Database; Operations Manager or Operations Manager Data Warehouse. These Events can originate from a number of possible causes. For example, a large amount of Discovery data, a Database connectivity issue or full database condition, potential disk or network constraints.

In Operations Manager, Discovery data insertion is a relatively expensive process. We define a burst of data as a short period of time where a significant amount of data is received by the Management Server. These bursts of data can cause Event ID 2115 since the data insertion should occur infrequently. If Event ID 2115 consistently appears for Discovery data collection, this can indicate either a Database or Data Warehouse insertion problem or Discovery rules in a Management Pack collecting too much discovery data.

Operations Manager configuration updates caused by Instance Space changes or Management Pack imports have a direct effect on CPU utilization on the Database Server and this can impact Database insertion times. Following a Management Pack import or a large instance space change, it is expected to see Event ID 2115 messages. For more information on this topic please see the following:

2603913 - How to detect and troubleshoot frequent configuration changes in Operations Manager (http://support.microsoft.com/kb/2603913)

If the Operations Manager or Operations Manager Data Warehouse databases are out of space or offline, it is expected that the Management Server will continue to log Event ID 2115 messages to the Operations Manager Event log and the pending time will grow higher. 

If the write action workflows cannot connect to the Operations Manager or Operations Manager Data Warehouse databases, or they are using invalid credentials to establish their connection, the data insertion will be blocked and Event ID 2115 messages will be logged accordingly until this situation is resolved.  

In Operations Manager, expensive User Interface queries can impact resource utilization on the Database which can lead to latency in Database insertion times. When a user is performing an expensive User Interface operation it is possible to see Event ID 2115 messages logged. 

Event ID 2115 messages can also indicate a performance problem if the Operations Manager Database and Data Warehouse databases are not properly configured. Performance problems on the database servers can lead to Event ID 2115 messages. Some possible causes include the following:

• The SQL Log or TempDB database is too small or out of space.
• The Network link from the Operations Manager and Data Warehouse database to the Management Server is bandwidth constrained or the latency is large. In this scenario we recommend to Management Server to be on the same LAN as the Operations Manager and Data Warehouse server.
• The data disk hosting the Database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a function problem. In this scenario we recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.
• The Operations Manager Database or Data Warehouse server does not have sufficient memory or CPU resources.
• The SQL Server instance hosting the Operations Manager Database or Data Warehouse is offline.

Resolution

The first step in troubleshooting Event ID 2115 is to identify what Data Items are being returned within the Event. For example, the Workflow ID indicates what type of Data Items (Discovery, Alerts, Event, Perf) as well as what Database in question. From the Workflow ID we can then determine the corresponding database. If the Workflow ID contains the term DataWarehouse, then the focus should be towards the Operations Manager Data Warehouse. In other instances the focus would be towards the Operations Manager Database.

The seconds indicator in the Event ID 2115 message returns how long the workflow in question has been waiting to insert the data items into the Database.

Scenario 1

In the example Event ID 2115 below, the problem concerns the workflow Microsoft.SystemCenter.CollectSignatureData.

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Computer: <RMS NAME>
Description:
A Bind Data Source in Management Group <MANGEMENT GROUP NAME> has posted items to the workflow, but has not received a response in 300 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectSignatureData
Instance : <RMS NAME>
Instance Id : {F56EB161-4ABE-5BC7-610F-4365524F294E}

Resolution 1

We can identify the Performance Signature Data Collection Rules in this example by executing the following SQL Query. This query should be executed in SQL Management Studio against the Operations Manager database.

-- Return all Performance Signature Collection Rules
Use OperationsManager
select
managementpack.mpname,
rules.rulename
from performancesignature with (nolock)
inner join rules with (nolock)
on rules.ruleid = performancesignature.learningruleid
inner join managementpack with(nolock)
on rules.managementpackid = managementpack.managementpackid
group by managementpack.mpname, rules.rulename
order by managementpack.mpname, rules.rulename

This query will return all Performance Signature Collection Rules and their respective Management Pack name. A column is returned for Management Pack name and Rule name.

The following Performance Monitor Counters on a Management Server will provide information concerning Database and Data Warehouse write action insertion batch size and time. If the batch size is growing larger, for example the default batch size is 5000 items, this indicates either the Management Server is slow inserting the data to the Database or Data Warehouse, or is receiving a burst of Data Items from the Agents or Gateway Servers.

· OpsMgr DB Write Action Modules(*)\Avg. Batch Size
· OpsMgr DB Write Action Modules(*)\Avg. Processing Time
· OpsMgr DW Writer Module(*)\Avg. Batch Processing Time, ms
· OpsMgr DW Writer Module(*)\Avg. Batch Size

From the Database and Data Warehouse write action account Average Processing Time counter, we can understand how long it takes on average to write a batch of data to the Database and Data Warehouse. Depending upon the amount of time it takes to write a batch of data to the Database, this may present an opportunity for tuning.

Scenario 2

The SQL Server instance hosting the Operations Manager Database or Data Warehouse is offline. Event ID 2115 as well as Event ID 29200 appear within the Operations Manager Event log. For example:

Log Name: Operations Manager
Source: HealthService
Date:
Event ID: 2115
Level: Warning
Description:

A Bind Data Source in Management Group MSFT has posted items to the workflow, but has not received a response in 60 seconds. This indicates a performance or functional problem with the workflow.

Workflow Id : Microsoft.SystemCenter.CollectEventData
Instance : name.contoso.local
Instance Id : {88676CDF-E284-7838-AC70-E898DA1720CB}

Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29200
Level: Error
Description:

OpsMgr Config Service has lost connectivity to the OpsMgr database, therefore it can not get any updates from the database. This may be a temporary issue that may be recovered from automatically. If the problem persists, it usually indicates a problem with the database. Reason:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Resolution 2

To resolve the issue in this scenario, follow these steps:

1. Connect to the Server hosting the Operations Manager database.
2. Open the Services applet.
3. Verify that the SQL Server (MSSQLSERVER) service is started and running.
4. If the SQL Server (MSSQLSERVER) service is not started and running, start the service.

Once Database connectivity is restored workflows should resume successfully storing data within the respective database. Event ID 31554 validates that the information has been written successfully.

For example:

Log Name: Operations Manager
Source: Health Service Modules
Event ID: 31554
Task Category: Data Warehouse
Level: Information

Description:
Workflow succeeded storing data in the Data Warehouse

One or more workflows were affected by this.

Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectEventData
Instance name: name.contoso.local
Instance ID: {88676CDF-E284-7838-AC70-E898DA1720CB}

Scenario 3

Event ID 2115 caused by invalid RunAs Credentials.

Resolution 3

Examine the Operations Manager Event log for the following events. These events typically indicate that the Data Warehouse SQL Server Authentication Account may have incorrect credentials.

Log Name: Operations Manager
Source: HealthService
Event ID: 7000
Task Category: Health Service
Level: Error
Description:

The Health Service could not log on the RunAs account <ACCOUNT NAME> for management group <MANGEMENT GROUP NAME>. The error is Logon failure: unknown user name or bad password.(1326L). This will prevent the health service from monitoring or performing actions using this RunAs account

Log Name: Operations Manager
Source: HealthService
Event ID: 7015
Task Category: Health Service
Level: Error
Description:

The Health Service cannot verify the future validity of the RunAs account <ACCOUNT NAME> for management group <MANGEMENT GROUP NAME>. The error is Logon failure: unknown user name or bad password.(1326L).

To resolve the issue in this scenario, follow these steps:
1. Open the Operations Manager console.
2. Select Administration.
3. Select Run As Configuration\Accounts.
4. Configure the appropriate credentials for the Data Warehouse SQL Server Authentication Account.

Scenario 4

Event ID 2115 caused by disk performance issues. The data disk hosting the Database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a functional problem. In this scenario we recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.

Resolution 4

Counters to identify disk pressure

Capture these Physical Disk counters for all drives that contain SQL data or log files:

• % Idle Time: How much disk idle time is being reported. Anything below 50 percent could indicate a disk bottleneck.
• Avg. Disk Queue Length: This value should not exceed 2 times the number of spindles on a LUN. For example, if a LUN has 25 spindles, a value of 50 is acceptable. However, if a LUN has 10 spindles, a value of 25 is too high. You could use the following formulas based on the RAID level and number of disks in the RAID configuration:

• • RAID 0: All of the disks are doing work in a RAID 0 set
  • Average Disk Queue Length <= # (Disks in the array) *2
  • RAID 1: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • RAID 10: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • RAID 5: All of the disks are doing work in a RAID 5 set
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • Avg. Disk sec/Transfer: The number of seconds it takes to complete one disk I/O
  • Avg. Disk sec/Read: The average time, in seconds, of a read of data from the disk
  • Avg. Disk sec/Write: The average time, in seconds, of a write of data to the disk
  • Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
  • Disk Transfers/sec: The number of input and output operations per second (IOPS)

  NOTE The last three counters in this list should consistently have values of approximately .020 (20 ms) or lower and should never exceed.050 (50 ms). The following are the thresholds that are documented in the SQL Server performance troubleshooting guide:

  • 1. • Less than 10 ms: very good
       • Between 10 - 20 ms: okay
       • Between 20 - 50 ms: slow, needs attention
       • Greater than 50 ms: serious I/O bottleneck
  • Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
  • Disk Transfers/sec: The number of input and output operations per second (IOPS)

• Troubleshooting Performance Problems in SQL Server 2008
• Troubleshooting Performance Problems in SQL Server 2005

Scenario 5

Event ID 2115 is logged, and a management server generates an "unable to write data to the Data Warehouse" alert in System Center Operations Manager.
You experience the following symptoms on a management server computer that is running Microsoft System Center Operations Manager:

• The management server generates one or more alerts that resemble the following:
  Performance data collection process unable to write data to the Data Warehouse
  
  Performance data collection process unable to write data to the Data Warehouse. Failed to store data in the Data Warehouse. Exception 'SqlException': Management Group with id '9069F7BD-55B8-C8E8-1CF9-4395F45527E2' is not allowed to access Data Warehouse under login 'DOMAIN\Action_Account' One or more workflows were affected by this. Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Instance name: dataWarehouseServer.domain.com Instance ID: {48936EE3-4E3E-BEE1-8C09-AFDAB8ECF236} Management group: Management Group Name.
• The following event is logged in the Operations Manager event log on the management server:
  Event Type: Warning
  Event Source: HealthService
  Event Category: None
  Event ID: 2115
  Date: date
  Time: time
  User: N/A
  Computer: ManagementServerName
  Description: A Bind Data Source in Management Group Management Group Name has posted items to the workflow, but has not received a response in 1712 seconds. This indicates a performance or functional problem with the workflow. Workflow Id : Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Instance : ManagementServerName.domain.com Instance Id : {C7FDDE2A-E0AA-4B80-70DE-1D50D9965221}

Resolution 5

This issue may occur if the management server does not have accounts that are specified for its data warehouse "Run As" profiles. This issue is more likely to affect a secondary management server.

To resolve this problem, follow these steps:

1. On the computer that is running System Center Operations Manager, open the Operations Console.
2. In the navigation pane, click Administration.
3. Expand Security, and then click Run As Profiles.
4. In the Run As Profiles view, double-click Data Warehouse Account.
5. In the Run As Profile Properties - Data Warehouse Account properties dialog box, click the Run As Accounts tab, and then click New.
6. In the Run As Account list, click Data Warehouse Action Account.
7. In the Name list, click the management server that generated the alert.
8. Click OK two times.
9. Follow steps 4 through 8 to assign the appropriate Run As account to the following profiles:
   Data Warehouse Configuration Synchronization Reader Account
   Data Warehouse Report Deployment Account
   Data Warehouse SQL Server Authentication Account
10. For each profile, select the Run As account that matches the name of the Run As profile. For example, make the following assignments:
    Assign the Data Warehouse Configuration Synchronization Reader Account to the Data Warehouse Configuration Synchronization Reader Account profile.
    Assign the Data Warehouse Report Deployment Account to the Data Warehouse Report Deployment Account profile.
    Assign the Data Warehouse SQL Server Authentication Account to the Data Warehouse SQL Server Authentication Account profile.
11. On the management server that generated the alert, restart the OpsMgr Health Service.
12. In the Operations Manager event log on the management server, verify that event ID 31554 events are logged.
    NOTE Event ID 31554 indicates that the monitor state has changed to Healthy. This change resolves the alert.

Scenario 6

Event ID 2115 occurs on a server running HP MPIO FF DSM XP v3.01 to which there are no LUNs presented. When the user opens Performance Monitor and attempts to add a counter, Performance Monitor will hang and the handle count for this application increases rapidly.

Resolution 6

There are two workaround regarding this issue.

1. Rename the HPPerfProv.dll file and reboot Windows. Performance Monitor will work without issue when the file is renamed and not loaded.
2. Have at least 1 LUN present on the system.

For more information on this issue please see the following:

Event ID 2115 is caused by HPPerfProv.DLL
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01743552&prodTypeId=18964&prodSeriesId=421492

=====

For the most current version of this article please see the following:

2681388 : How to troubleshoot Event ID 2115 in Operations Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published this morning. This one is more of a heads-up but it explains what you may see if you try to import a Management Pack in OpsMgr but haven’t imported the other Management Packs that are listed as dependencies first.

=====

Summary

When importing a management pack in System Center Operations Manager 2007 that has a dependency on another management pack, the import may fail with the following message:

<ManagementPackName> could not be imported.

If any management packs in the Import list are dependent on this management pack, the installation of the dependent management packs will fail.
The requested management pack was invalid. See inner exception for details.
Parameter name: managementPack

More Information

This issue occurs because a management pack that the management pack being imported depends on isn't imported in the management group. In order to work around this problem, import the dependent management packs first then import the management packs that depend on them.

NOTE If you're unsure of the dependencies for a management pack, they will be listed in the management pack guide.

=====

For the most current version of this article please see the following:

2698846 : Importing a Management Pack in System Center Operations Manager fails if a dependent management pack isn't imported

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s one more Knowledge Base article we published this morning. This one shows you how to easily fix an issue where the Microsoft System Center Operations Manager 2007 R2 (OpsMgr) Connector for HP OpenView fails to auto-forwarding alerts to an HP OVO server.

=====

Symptoms

The Microsoft System Center Operations Manager 2007 R2 (OpsMgr) Connector for HP OpenView Operations for Windows fails to auto-forwarding alerts to an HP OVO server. You also find information similar to the following in the SCInterop log file:

[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] ERROR Could not deliver some events. No providers were available. Cannot create WSManConfig for any providers
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Microsoft.SystemCenter.Interop.NoProviderAvailableException: Cannot create WSManConfig for any providers
at Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule.BuildWsmanConfigList(IConfig c)
at Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule.XFormOutboundAlerts_Callback(Topic topic, Payload payload)
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Exiting WSRxAlerts_Callback method...
[Microsoft.SystemCenter.Interop.Framework.Modules.XFormModule] DEBUG Leaving CacheAlerts_Callback
[Microsoft.SystemCenter.Interop.Framework.Modules.Cache] DEBUG Leaving FilterAlerts_Callback
[Microsoft.SystemCenter.Interop.Framework.Modules.FilterModule] DEBUG alerts published
[Microsoft.SystemCenter.Interop.Framework.Modules.FilterModule] DEBUG Leaving OpsAlerts_Callback
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG 3 alerts published
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG acking alerts 3 to sdk
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG 3 alerts acked to sdk
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG Leaving TimerCallback
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Entering TimerCallback method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Retrieving events...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG locked on WSRxAlerts
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG BuildWsmanConfigList called
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Not all providers have be queried for WSManType. Attempting to query each provider
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManConfig] DEBUG WSManConfig constructor called
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManConfig] DEBUG Creating WSManConfig for OVO Server
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Entering GetWSManType method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Entering CreateSession method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG using basic auth
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Calling WSMAN Session host OVO Server with parameters...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG ResourceUri : https://OVO Server:1270
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG SessionFlags : 266241
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG UserName : root
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Exiting CreateSession method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Calling WSMAN Identify on host OVO Server with parameters...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Flags : 0
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Exception A security error occurred occurred while determining WSMan type of server OVO Server
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Exiting GetWSManType method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG System.Runtime.InteropServices.COMException (0x80072F8F): A security error occurred
at WSManAutomation.IWSManSession.Identify(Int32 flags)

Cause

This can occur if there are no providers can be contacted to get an update event.

Resolution

To resolve this issue, run scicert.exe to import the certificate from the provider into the connector server. To do this, on the server that the OpsMgr Connector for HP OpenView Operations service is installed, run the following command from a command prompt window:

C:\Program Files\System Center Operations Manager 2007 R2 Connectors\OpsMgr Connector for HP OpenView Operations\

Then run the following command:

scicert <OVO server> <wsman user> <wsman password> "OpsMgr Connector for HP OpenView Operations"

NOTEReplace <OVO server> with your OVO server name

NOTE<wsman user> will be the user you setup in the Connector Configuration UI (e.g., - doman\wsman user or root account)

If this is successful it will display the certificate thumbprint and ask if you want to continue. Enter Yes to import the certificate.

Once you have the certificate imported, restart the OpsMgr Connector for HP OpenView Operations service and check the log.

You should no longer see the error and should now be able to forward alerts to the OVO Server.

=====

For the most current version of this article please see the following:

2693106 : The Operations Manager OpenView connector fails to auto-forwarding alerts to an HP OVO server

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

We are very happy to announce that seven of the Product Solution Centers on http://support.microsoft.com are featuring new Top Solutions sections that pull dynamically from the Top Solutions RSS feeds. The Top Solutions are usually listed on the page for the Key Resources tab.

The following solution centers have dynamic Top Solutions; the rest will be updated in the near future. Check out the new look and functionality!

• Windows Server 2008 R2
• SQL Server
• System Center 2012– select the tabs for the following products
  • Configuration Manager
  • Data Protection Manager
  • Operations Manager
  • Virtual Machine Manager
• Lync Server

If you want to keep up to date on all the latest top solutions you’ll definitely want to check these out.

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published this morning. This one discusses regular expression support in System Center Operations Manager.

=====

Summary

The authoring of management packs may need to include regular expression matching in discoveries and groups, as well as for pattern matching in expression criteria in monitors and rules.

There are two different types of regular expression support in the SCOM product, and you have to know which element you are working in to choose the correct one. Specifically, Group membership calculation and expression filters use distinctly different syntaxes for pattern matching.

More Information

Group calculation uses PERL regular expression syntax. By default, the matching is case insensitive, but in the XML you can specify that an expression needs to be….

=====

For the rest of this article please see the following:

2702651 - Regular expression support in System Center Operations Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Cumulative Update 6 for System Center Operations Manager 2007 R2 is available. Cumulative Update 6 for Operations Manager 2007 R2 resolves the following issues:

• RMS promotion fails if NetworkName and PrincipalNames are not in sync for agents.
• UI is limited to only 100 MB for the Memory Usage field in the wizard.
• Additional OIDs in auth certificate are not processed correctly.
• AEM creates duplicate computer objects in OpsMgr based on Agents NetBIOS name.
• Cannot open reporting pane on OpsMgr 2007 R2 remote console.
• Cannot view schedule for scheduled report.
• ManagementServerConfigTool with the option "promoterms" fails because it stops polling the SDK Service.
• OpsMgr reports are failing on Windows 7 with the error: "Cannot initialize report."
• ACS events have "n/a" as their category in the ACS database.
• Watch agentless monitoring listener to detect failure to respond.
• SCOM SDK memory leak on cryptography keys and cryptography contexts.
• After you click Edit Schedule, a message box appears, and you cannot save the change value.
• Audit events can be lost when the AdtServer process crashes.

• The installation process for the IBM AIX 6.1 agent incorrectly checks for AIX 5.3 packages.
• After a system restart, the OpsMgr agent for Solaris may start to run before local file systems are mounted.
• On Red Hat Linux version 4 and SUSE Linux version 9, LVM disks are not discovered and cannot be monitored.
• The OpsMgr agent for AIX does not report the arguments for monitored processes.
• When Microsoft security update MS12-006 is installed on an OpsMgr management server, that management server can no longer communicate with the OpsMgr agent on any Linux or UNIX server.
• On HP-UX, OpsMgr cannot discover and monitor a logical volume that is composed of more than 127 physical volumes.

• Support for IBM AIX 7.1 (POWER).
• Support for Oracle Solaris 11 (x86 and SPARC).

For all the details and a download link, see the following Knowledge Base article:

KB2626076 - Cumulative Update 6 for System Center Operations Manager 2007 R2 is available

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published. This one is a basic overview of what Maintenance Mode is and when/how you’d want to use it, plus a couple common issues you may run into.

=====

=====

For the most current version of this article please see the following:

2704170 - Understanding Operations Manager Maintenance Mode

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebook andTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published. This one talks about an issue where an Operations Manager AD Replication Monitor generates an "Invalid Script Parameter Configuration" error message.

=====

Symptoms

System Center Operations Manager 2007 generates alerts on Domain Controllers regarding incorrect script parameters with an alert context similar to the following:
Script Parameters are configured incorrectly And Invalid Script Parameter Configuration

AD Replication Monitoring : detected an error with one or more parameters. The error is:
InterSiteExpectedMaxLatency must be greater than the IntrasiteExpectedMaxLatency parameter. IntersiteExpectedMaxLatency = 15
IntrasiteExpectedMaxLatency = 30
IntersiteExpectedMaxLatency will be set to the value 90 for this execution of this script.
You also see an event with ID 66 in the Domain Controller's Operations Manager log:
Log Name: Operations Manager
Source: Health Service Script
Date:
Event ID: 66
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: DC1.contoso.com
Description:
AD Replication Monitoring : detected an error with one or more parameters. The error is:
InterSiteExpectedMaxLatency must be greater than the IntrasiteExpectedMaxLatency parameter. IntersiteExpectedMaxLatency = 15
IntrasiteExpectedMaxLatency = 30
IntersiteExpectedMaxLatency will be set to the value 90 for this execution of this script.
To correct the error, find the rule 'Script - AD Replication Monitoring' and from the response tab of its properties, edit the script and modify the parameter in question.

Cause

Though the alert context points us towards fixing the AD Replication Monitor and a script, the error occurs due to a rule that has incorrect values specified in the overrides.

Resolution

To resolve this issue follow these steps:

1. Go to Authoring pane in the SCOM Admin Console.
2. Select Overrides under Management Pack Objects.
3. Look for overrides on "AD Replication is occurring slowly" rule.
4. In the list of overrides on 'AD Replication is occurring slowly' rule, check for overrides on Instrasite Expected Max Latency parameter. If the overridden value for this parameter is lesser than the value of Intersite Expected Max Latency parameter, modify it to a lesser value.
5. By default Instrasite Expected Max Latency = 5 and Intersite Expected Max Latency = 15 and we can see that Intrasite value is lesser than Intersite value.
6. Once you change the override, click on OK.
7. Allow the configuration to be propagated to all the Domain Controllers. Slowly, you should stop receiving further alerts.

=====

For the most current version of this article please see the following:

2722619 - Operations Manager AD Replication Monitoring generates "Invalid Script Parameter Configuration" error

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

The information below applies to the monitoring of HP-UX PA-RISC computers with:

• Operations Manager 2007 R2
• System Center 2012 – Operations Manager

Background

Operations Manager uses the WS-Management protocol over SSL/TLS to communicate with UNIX and Linux agents. A certificate used for SSL/TLS is generated on each UNIX and Linux computer during agent installation and signed by a Management Server during agent discovery. For all cases except for HP-UX PA-RISC computers, the certificate is generated with a 2048 bit key. By default, HP-UX PA-RISC computers use a 512 bit key to generate this certificate, due to increased CPU utilization that has been observed on HP-UX PA-RISC computers when establishing SSL/TLS connections with a larger key size.

A Windows update expected to release on August 14, 2012 will block the use of RSA keys less than 1024 bits in length for any Windows computer where the update is installed. More information about this Windows update can be found in the More Information section below. When this update is installed on Operations Manager Management Servers or Gateways that are managing HP-UX PA-RISC computers, the HP-UX computers will generate heartbeat and SSL certificate alerts, and all monitoring of the computers will be interrupted until remediation is performed.

Only HP-UX PA-RISC computers monitored by Operations Manager are affected by this Windows update. HP-UX Itanium and all other UNIX and Linux operating systems and architectures are not affected.

Symptoms

Following installation of the Windows server update that requires certificates associated with keys greater than 1023 bits on Operations Manager Management Servers and Gateways, the following symptoms will occur:

· HP-UX PA-RISC computers (11iv2 and 11iv3) will generate heartbeat alerts and all Operations Manager monitoring of the computers will fail. An “SSL Certificate Error” will also be generated with the description: The SSL Certificate used by the Agent has a configuration error.

· Operations Manager will fail to discover new HP-UX PA-RISC computers due to a “signed certificate verification” error.

Resolution

There are two options to restore monitoring communication between Operations Manager and HP-UX PA-RISC computers:

1. Allow RSA keys less than 1024 bits on each Management Server and Gateway that manages HP-UX PA-RISC computers

2. Creating and signing a new certificate with a 1024 bit key on HP-UX PA-RISC computers

Both of these options restore communication between Operations Manager and HP-UX PA-RISC computers. Allowing RSA keys less than 1024 bits on the Operations Manager server effectively disables the changes made by the Windows update. Creating and signing a new certificate with a 1024 bit key on HP-UX PA-RISC computers allows the changes made by the Windows update to stay in effect on Operations Manager servers, but may have some performance impact on HP-UX computers. We recommend that you try option #2 in a pilot environment to ensure that the additional CPU overhead on the HP-UX PA-RISC computer does not impact your production workloads.

Allowing RSA keys less than 1024 bits on Operations Manager servers

On each Operations Manager Management Server or Gateway that manages HP-UX PA-RISC computers, perform the following steps:

1. Launch a command prompt as administrator

2. In the command prompt, run the following command:

Certutil -setreg chain\minRSAPubKeyBitLength 512

Creating and signing a new certificate with a 1024 bit key on HP-UX PA-RISC computers

For each HP-UX PA-RISC computer monitored by Operations Manager, perform the following steps:

1. Establish a console session with the HP-UX computer, locally or via Secure Shell (ssh), as the root user

2. Change to the Operations Manager agent tools directory: cd /opt/microsoft/scx/bin/tools

3. Run the scxsslconfig utility to force certificate generation with a 1024 bit key:

./scxsslconfig –v –f –b 1024

where:

-v = verbose
-f = force overwrite of existing certificate
-b = number of key bits

The output of this command will display the Host Name, Domain Name, and Cert Length used in certificate generation. Confirm that the Cert Length value is 1024. Confirm that the Host Name and Domain Name are appropriate for the FQDN used by Operations Manager to reach the computer. These values can be explicitly specified when running the scxsslconfig command with –h and –d switches.

4. The new certificate must now be signed by the Operations Manager server. Using a secure file transfer protocol such as sftp or scp, copy the file: /etc/opt/microsoft/scx/ssl/scx-host-<hostname>.pem (where <hostname> is the hostname of the HP-UX computer) to the Operations Manager server that manages the HP-UX computer.

5. On the Operations Manager server, launch a command prompt as administrator

6. In the command prompt, change directories to the program directory for Operations Manager.
Default paths are:

a. Operations Manager 2007 R2: C:\Program Files System Center Operations Manager 2007

b. System Center 2012 – Operations Manager: C:\Program Files\System Center 2012\Operations Manager\Server

7. Run the scxcertconfig.exe command:

scxcertconfig -sign <path to certificate .pem file> scx_new.pem    

Where <path to certificate .pem file> is the full path to the certificate file copied from the HP-UX PA-RISC computer

8. Using a secure file transfer protocol such as sftp or scp, copy the scx_new.pem file to the directory: /etc/opt/microsoft/scx/ssl on the HP-UX computer. Rename the scx_new.pem file in the /etc/opt/microsoft/scx/ssl directory to overwrite the existing: /etc/opt/microsoft/scx/ssl/scx-host-<hostname>.pem file

9. Restart the Operations Manager agent with the following command (executed in a console or ssh session on the HP-UX computer):

/opt/microsoft/scx/bin/tools/scxadmin -restart

Bringing new HP-UX PA-RISC computers under OpsMgr management

If the second resolution approach is taken (Creating and signing a new certificate with a 1024 bit key on HP-UX PA-RISC computers), newly discovered HP-UX PA-RISC computers that are brought under management by OpsMgr will experience the same symptoms because the automatically generated certificate will have a 512 bit key. The steps outlined above must be taken on each new HP-UX PA-RISC computer to create and sign a new certificate with a 1024 bit key.

In the future, Microsoft will release an update to the OpsMgr agent for HP-UX PA-RISC computers. For HP-UX PA-RISC computers that are newly brought under OpsMgr management with this updated agent, the automatically generated certificate will have a 1024 bit key, and no additional resolutions steps will be needed. But for already managed computers, installing this updated agent does not automatically a new certificate, and the above outlined resolution steps must still be followed.

More Information

Windows PKI Blog posts about the Windows update:

http://blogs.technet.com/b/pki/archive/2012/07/13/blocking-rsa-keys-less-than-1024-bits-part-2.aspx
http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx.

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity- support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

With the latest update rollup we resolved 2 major user experience issues customers have given us feedback on.

1. Hostname\Display Name in “Object by Performance” widget is empty

I am happy to announce that we addressed the issue where the display name in Object By Performance widget was never returned. I showed that we fixed this issue at my MMS 2013 dashboarding session last Tuesday and all 850 people that attended applauded. I know this was a big hurdle for most of you and I apologize in any delay in getting this issue resolved.

 2. OpsMgr Web Console Performance Improved

We have made some significant web console performance improvements with this update rollup in particular view load times. We made some changes in the code which now helps views like the alert view loads in a couple of seconds. This is another big customer request where we have addressed with this update.

You can download the update from here: http://support.microsoft.com/kb/2802159

Here’s a new Knowledge Base article we published today. This one talks about an issue where OpsMgr integration with System Center 2012 Virtual Machine Manager fails with error 10218:

=====

Symptoms

When creating the integration from System Center 2012 Virtual Machine Manager (SCVMM 2012) to Operations Manager, the integration fails with the following error:

Error (10218)
Setup could not import the System Center Virtual Machine Manager Management Pack into Operations Manager server because one or more required management packs are missing. The SCVMM Management Packs cannot be deployed unless the following component management packs are present in Operations Manager 2007:
Windows Server Internet Information Services 2003,
Windows Server 2008 Internet Information Services 7,
Windows Server Internet Information Services Library,
SQL Server Core Library.

NOTE All required Management Packs have been imported in Operations Manager.

Cause

In this scenario, the Virtual Server 2005 R2 Management Pack was imported which imports the Microsoft Virtualization Core Library. The cause of the problem is that SCVMM 2012 will import a newer version of the Microsoft Virtualization Core Library Management Pack and the old version cannot be present in order for integration to complete successfully.

Resolution

There are two potential solutions:

1. Remove the old version of the Microsoft Virtualization Core Library and the Microsoft Virtual Server 2005 R2 Management Pack.

or

2. Configure a second Operations Management group for the SCVMM 2012 integration and configure the SCVMM 2012 server as well as the Hyper-V servers to report to this new management group.

More Information

The Microsoft Virtualization Core Library is a Hyper-V Management Pack developed by the Hyper-V team. It has been updated to support the latest version of Hyper-v and improve monitoring of the hosts.

=====

For the most current version of this article please see the following:

2674625 : Operations Manager integration with System Center 2012 Virtual Machine Manager fails with error 10218

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published today. This one explains why you can’t see a SQL Server replication status even though you have the SQL Server MP loaded in SCOM 2007:

=====

Symptom

When using Microsoft System Center Operations Manager Server 2007 R2 with the Microsoft SQL Server Management Pack, items within SQL Server Replication report a Not Monitored state under Publication State, Publisher State and Subscription State.

Cause

This behavior is by design. There are no replication monitors in the Microsoft SQL Server Management Pack for Operations Manager 2007 SP1 and R2. http://www.microsoft.com/download/en/details.aspx?id=10631. If you check in Authoring Console Monitors for SQL replication you will see that when the SQL 2008 Publication\Entity Health\Availability entry is expanded there is no monitor to update information to rollup monitors.

Resolution

Replication monitors are introduced in the SQL Server 2012 Management Pack that will be released following the release of System Center 2012 Operations Manager.

More Information

This article only applies to the Microsoft SQL Server Management Pack for Operations Manager 2007 SP1 and R2 . This Management Pack provides discovery and monitoring of SQL Server 2005, 2008, and 2008 R2.

=====

For the most current version of this article please see the following:

2673200 : System Center Operations Manager 2007 is unable to monitor SQL Server replication status

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published today. This one talks about troubleshooting an issue where configuration doesn’t update in System Center Operations Manager 2007:

=====

Symptoms

You may experience one or more of the following symptoms in a System Center Operations Manager 2007 Management Group:

• Newly installed agents display as "Not Monitored" in the Operations Console, yet existing agents are monitored.
• One or more monitors on one or more agents may not change state when healthy or unhealthy conditions are met.
• Agents show as being in maintenance mode in the Operations Console, yet the workflows are not actually unloaded by the System Center Management service on the monitored computer.
• Configuration changes, new rules or monitors, or overrides are not applied to some agents.
• The Operations Manager event log on one or more agents will display event 21026, indicating that the current configuration is still valid, even though the configuration for these agents should have been updated.
• The file "OpsMgrConnector.Config.xml" in the management group folder under "Health Service State"\"Connector Configuration Cache" does not update for long periods of time relative to the rest of the management group on one or more agents.

In addition, the Operations Manager event log may display one or more event with an ID 29106 when the System Center Configuration Management service restarts. For example

Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29106
Level: Warning
Description:
The request to synchronize state for OpsMgr Health Service identified by "da4d36df-ce22-8930-e6d4-45b783e9fdb1" failed due to the following exception "System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.

Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29106
Level: Warning
Description:
The request to synchronize state for OpsMgr Health Service identified by "fc1c815b-c0c4-242d-ae27-30db4ef99b54" failed due to the following exception "Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistException: TypedManagedEntityId = 'ac8f3d08-ee2a-ae21-0e46-19c3da794183' is deleted.

Collecting ETL logs against the Configuration Service at INF level might reveal lines similar to that below:

Note the timestamp in line 3326 is set to 04/11/2074. If this appears in ETL logging, use the SQL queries in the "More Information" section to confirm the condition listed in the "cause" section exists.

Cause

The System Center Management Configuration service uses a timestamp to determine when new configuration data needs to be calculated for agents and management servers. If the system clock on an agent is faster than the system clock on the RMS, discovery data from this agent will set the timestamp for one or more managed instances hosted by that agent to the current agent system clock time. The System Center Configuration Management service will delay calculating configuration updates for the instances on that agent until the system clock on the RMS is current with the timestamp for that discovery data. If the agent system clock was significantly faster than RMS system time when discovery data was sent, or the agent continues to send data with a future timestamp, then it is possible that the management group would experience the symptoms listed above.

Setting the agent system clock time to match the RMS system clock time will not reset the timestamp for the existing discovery data and the issue will remain until the RMS system clock time exceeds the discovery data by the grooming interval, when the obsolete discovery data will be groomed normally.

Resolution

1) The system clocks for all agents and management servers in the management group must not significantly exceed the system clock on the RMS when submitting ANY data. If any agents or management servers have system clocks more than a few minutes faster than the RMS, they should be corrected first to avoid any additional data with future timestamps being added to the database.

2) The future timestamps for the discovery data that has already been submitted must be modified in the OperationsManager database to reflect the current time.

3) The System Center Configuration Management service and System Center Management service on the RMS must be restarted after both the above conditions are met.

More Information

1) Use the following three queries to determine if this condition exists. The queries must be run against the OperationsManager database. If the timestamp with the greatest value in the table is greater than the current time (in UTC format), then the condition exists.

2) The following three queries can be used to determine which computers may have submitted discovery data with a future timestamp. If the system clocks on these agents are not current, set them to current time before taking any additional action.

3) To correct the existing data, run the following commands against the affected tables.

Update DiscoverySource
Set TimeGeneratedOfLastSnapshot = GETUTCDATE()
where TimeGeneratedOfLastSnapshot > GETUTCDATE()

Update DiscoverySourceToTypedManagedEntity
Set TimeGenerated = GETUTCDATE()
where TimeGenerated > GETUTCDATE()

Update DiscoverySourceToRelationship
Set TimeGenerated = GETUTCDATE()
where TimeGenerated > GETUTCDATE()

4) The following query can be used to see what additional data has been submitted to the database with a timestamp in the future. The tables related to maintenance mode should have several rows, assuming there are agents currently in maintenance mode which is scheduled to end at some time. All other tables should have timestamps with the current time, or in the past.

=====

For the most current version of this article please see the following:

2635742 : Configuration may not update in System Center Operations Manager 2007

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

I was looking through all of the new articles over on our TechNet Wiki and came across this one that I thought you might find useful.  It was written by Microsoft Premier Field Engineer Mazen Ahmed and it contains a few PowerShell commands that will come in handy when managing System Center Operations Manager 2007.  And since it’s part of our Wiki, that means if you have a couple of your own favorites you can edit the article and add them as well.  Enjoy!

Useful PowerShell Commands for Operations Manager 2007 (http://social.technet.microsoft.com/wiki/contents/articles/7865.useful-powershell-commands-for-operations-manager-2007.aspx)

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published today. This one walks you through monitoring txt and CSV log files in System Center Operations Manager:

=====

Summary

Configuring System Center Operations Manager to monitor plain text and delimited text log files from various sources is straightforward but there are some scenarios of which to be aware.

More Information

See the link below for instructions on how to create a Simple Event Detection monitor for a plain text (non-delimited) log file in System Center Operations Manager 2007 and 2007 R2:

http://technet.microsoft.com/en-us/library/bb381375.aspx

NOTE This information should also apply to System Center 2012 Operations Manager

Follow the procedure at the link above to create a monitor for a delimited (CSV) log file with the following exceptions:

Step 7: In the Create Monitor Wizard, on the Select a Monitor Type page, expand Log Files, expand Text Log (CSV), expand Simple Event Detection, click Event Reset, and then click Next.

Step 10: The separator must also be entered on the Application Log Data Source page. The separator does not have to be a comma, but it must be a printable character.

Step 12: When entering a parameter name, the number in Params/Param[x] represents the field on which the operation will take place. For example, Params/Param[1] is the first field of the delimited file; Params/Param[2] is the second field of the delimited file, and so forth.

Steps for creating a rule to monitor a log file

The following steps illustrate how to create a rule that targets the Windows Computer class and monitors a log file in System Center Operations Manager 2007 and 2007 R2. For more information on selecting a target for a workflow (which includes rules and monitors) see Selecting a Target for a Workflow

1. Log on to the computer with an account that is a member of the Operations Manager Administrators user role or Operations Manager Authors user role for the Operations Manager management group.

2. In the Operations console, click the Authoring button.

3. In the Authoring pane, expand Authoring, expand Management Pack Objects, and then click Rules.

4. In the toolbar, click Scope.

5. In the Scope Management Packs Objects dialog box, in the Find text box, type Windows Computer, select the Windows Computer target check box, and then click OK.

6. In the Rules pane, right-click Windows Computer and then click Create a New Rule

7. In the Create Rule Wizard, on the Select the type of rule to create page, expand Collection Rules, expand Event Based, and select Generic Text Log or Generic CSV Text Log

NOTE If an alert will be configured, choose Alert Generating Rules, expand Event Based, and select Generic Text Log or Generic CSV Text Log

8. Select a management pack from the Select destination management pack list (in System Center Operations Manager 2012, this list picker is labeled Select Management Pack) or create a new unsealed management pack by clicking New. By default, when creating a management pack object, an override, or disabling a rule or monitor, Operations Manager saves the setting to the Default Management Pack. As a best practice, create a separate management pack for each sealed management pack to be , rather than saving customized settings to the Default Management Pack. For more information, see Default Management Pack.

9. Click Next

10. On the General page, in the Name box, type a name for the rule, and then as an option, you can type a description.

11. Click the Rule Category arrow, select the appropriate category, and then click Next.

12. On the Application Log Data Source page under Define the application log data source, in the Directory text box, type a path to where the log files are located, for example, C:\logfiles

13. In the Pattern text box, type a pattern string to select log files. For example, application??.log will find any log file that starts with ‘application’ followed by zero to two characters with an extension of ‘.log’ (e.g. application.log, application1.log, application01.log, etc.).

14. For CSV log types, enter the separator. The separator does not have to be a comma, but it must be a printable character

15. Select UTF8 if applicable, and then click Next

16. On the Build Event Expression page (for the Build First Expression),click Insert and then do the following:

a. Under Parameter Name (on the left), type Params/Param[1]. Params/Param[1] is the only field available for Generic Text log, since each line in the file is considered a single field. For Generic CSV Text Log, the number in Params/Param[x] represents the field on which the operation will take place. For example, Params/Param[1] is the first field of the delimited file; Params/Param[2] is the second field of the delimited file, and so forth.

b. Under Operator, click the pull down menu and select an operator, for example Contains

c. Under Value enter the text that this monitor should trigger on as found in the log file, for example error

17. Click Create to create the rule. If Alert Generating Rules was chosen in step 7A, click next to configure the alert, then click Create to create the rule.

After the rule is created, edit the properties of the new rule to generate an alert when the rule is triggered. See How to Edit Properties of a Rule in Operations Manager 2007for more information on editing the properties of a rule.

Steps for creating a text log alert rule on System Center 2012 Operations Manager can be found under the section To create a delimited text log alert rule at http://technet.microsoft.com/en-us/library/hh457567.aspx.

To reference the fields that were read from the log when the rule is triggered in an alert, use the Params/Param[x] syntax.

For more information on the various settings available in the Create a unit monitor and Create Rule Wizard wizards, see the section Text Log Wizard Options at http://technet.microsoft.com/en-us/library/hh457567.aspx.

Additional Information

When monitoring a log file, Operations Manager remembers the last line read within the file (a 'high water mark'). It will not re-read data before this point unless the file is deleted and recreated, or renamed and recreated, which will reset the high water mark.

An implication of this is that log files that are cleared periodically without being renamed and recreated, or deleted and recreated, will not have entries in them processed until the high water mark from before the log is cleared is exceeded.

Operations Manager cannot monitor 'circular log files' (i.e. log files that get to a certain size or line count, then start writing the newest entries at the beginning of the log) for the same reason. The log file must be deleted or renamed and then recreated, or the application configured to write to a new log once the current log is filled.

Example:

• 100 lines are written to logfile.txt
• logfile.txt is cleared of all entries
• New log entries are written to logfile.txt (position 0 of the file)
• None of the new entries will be processed until line 101 is written

Each line of a log file must end with a new line (0x0A0x0A hex sequence) before it will be read and processed by Operations Manager.

If a rule or monitor is configured to match a pattern for log file names (e.g. using the ? or * wildcard characters), it is important that only ONE log that matches the pattern is written. If multiple logs that match the pattern are being written to, the high water mark is reset to the beginning of the file with each write to a different file. The result is that all previous log entries will be reprocessed.

Example:

• The log file name pattern is generic_csv??.txt
• The current log is generic_csv01.txt and writes happen to this log.
• A new log, generic_csv02.txt, is created. Writes occur to this log.
• When the next line is written to generic_csv01.txt, the Operations Manager will read from the beginning of generic_csv.txt, not from the last point that was read from generic_csv01.txt. Lines previously processed will be processed again, possibly resulting in alerts or other actions (depending on the rule configuration).

=====

For the most current version of this article please see the following:

2691973 : Monitoring Text and CSV log files in System Center Operations Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s another new Knowledge Base article we published today. This one talks about the cause and resolution of an issue where you get event ID 29112 logged after upgrading to System Center 2012 Operations Manager:

=====

Symptoms

After Upgrading from System Center Operations Manager 2007 R2 CU5 to System Center 2012 Operations Manager, the following error may be logged in the Operations Manager Event Log
Log Name: Operations Manager
Source: OpsMgr Management Configuration
Date:
Event ID: 29112
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
OpsMgr Management Configuration Service failed to execute bootstrap work item 'ConfigurationStoreInitializeWorkItem' due to the following exception

Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessException: Data access operation failed
at Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessOperation.ExecuteSynchronously(Int32 timeoutSeconds, WaitHandle stopWaitHandle)
at Microsoft.EnterpriseManagement.ManagementConfiguration.SqlConfigurationStore.ConfigurationStore.ExecuteOperationSynchronously(IDataAccessConnectedOperation operation, String operationName)
at Microsoft.EnterpriseManagement.ManagementConfiguration.SqlConfigurationStore.ConfigurationStore.Initialize()
at Microsoft.EnterpriseManagement.ManagementConfiguration.Engine.ConfigurationStoreInitializeWorkItem.ExecuteWorkItem()
at Microsoft.EnterpriseManagement.ManagementConfiguration.Interop.ConfigServiceEngineWorkItem.Execute()
-----------------------------------
Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessException: Data access operation failed to run SQL script. The following are the first 200 characters of the first failed batch
------

ALTER PROCEDURE CS.AgentCredentialDeltaSyncProcessStaging
@LogEnabledInd bit = 0
AS
BEGIN
SET NOCOUNT ON

DECLARE
@ErrorInd bit
,@ErrorMessage nvarchar(max)

-----------------------------------
System.Data.SqlClient.SqlException (0x80131904): Incorrect syntax near 'MERGE'.
Incorrect syntax near the keyword 'AS'.
Incorrect syntax near 'TRY'.
Incorrect syntax near 'CATCH'.
Incorrect syntax near 'END'.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.EndExecuteNonQuery(IAsyncResult asyncResult)
at Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.NonQuerySqlCommandOperation.SqlCommandCompleted(IAsyncResult asyncResult)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="OpsMgr Management Configuration" />
<EventID Qualifiers="49152">29112</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="xxxxxxx" />
<EventRecordID>5322</EventRecordID>
<Channel>Operations Manager</Channel>
<Computer>xxxxxxx</Computer>
<Security />
</System>
<EventData>
<Data>OpsMgr Management Configuration Service</Data>
<Data>ConfigurationStoreInitializeWorkItem</Data>
<Data>Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessException: Data access operation failed
at Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessOperation.ExecuteSynchronously(Int32 timeoutSeconds, WaitHandle stopWaitHandle)
at Microsoft.EnterpriseManagement.ManagementConfiguration.SqlConfigurationStore.ConfigurationStore.ExecuteOperationSynchronously(IDataAccessConnectedOperation operation, String operationName)
at Microsoft.EnterpriseManagement.ManagementConfiguration.SqlConfigurationStore.ConfigurationStore.Initialize()
at Microsoft.EnterpriseManagement.ManagementConfiguration.Engine.ConfigurationStoreInitializeWorkItem.ExecuteWorkItem()
at Microsoft.EnterpriseManagement.ManagementConfiguration.Interop.ConfigServiceEngineWorkItem.Execute()

Cause

This can occur if SQL Server is running the Operations Manager databases in SQL 2005 compatibility mode.

Resolution

To resolve this issue, change the SQL database Compatibility Level to SQL 2008 (100) by doing the following:

1. Open SQL Server Management Studio
2. Connect to the SQL server hosting the Operations Manager Databases
3. Expand Databases
4. Right Click on OperationsManager and click properties
5. Click Options
6. Change the Compatibility level: drop down to SQL Server 2008 (100)
7. Click OK
8. Right Click on OperationsManagerDW and click properties
9. Click Options
10. Change the Compatibility level: drop down to SQL Server 2008 (100)
11. Click OK

More Information

For more information on changing Database Compatibility Levels see the following:

http://msdn.microsoft.com/en-us/library/bb510680(v=sql.105).aspx

=====

For the most current version of this article please see the following:

2700028 : Event ID 29112 generated after upgrading to System Center 2012 Operations Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s another new Knowledge Base article we published today. This one goes through some common troubleshooting tips for eliminating Event IDs 2115 in Operations Manager:

=====

Symptoms

In Operations Manager, one of the performance concerns surrounds Operations Manager Database and Data Warehouse insertion times. The following is a description to help identify and troubleshoot problems concerning Database and Data Warehouse data insertion.

Examine the Operations Manager Event log for the presence of Event ID 2115 events. These events typically indicate that performance issues exist on the Management Server or the Microsoft SQL Server that is hosting the OperationsManager or OperationsManager Data Warehouse databases. Database and Data Warehouse write action workflows run on the Management Servers and these workflows first retain the data received from the Agents and Gateway Servers in an internal buffer. They then gather this data from the internal buffer and insert it into the Database and Data Warehouse. When the first data insertion has completed, the workflows will then create another batch.

The size of each batch of data depends on how much data is available in the buffer when the batch is created, however there is a maximum limit on the size of the data batch of up to 5000 data items. If the data item incoming rate increases, or the data item insertion throughput to the Operation Manager and Data Warehouse databases throughput is reduced, the buffer will then accumulate more data and the batch size will grow larger. There are several write action workflows that run on a Management Server. These workflows handle data insertion to the Operations Manager and Data Warehouse databases for different data types. For example:

• Microsoft.SystemCenter.DataWarehouse.CollectEntityHealthStateChange
• Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData
• Microsoft.SystemCenter.DataWarehouse.CollectEventData
• Microsoft.SystemCenter.CollectAlerts
• Microsoft.SystemCenter.CollectEntityState
• Microsoft.SystemCenter.CollectPublishedEntityState
• Microsoft.SystemCenter.CollectDiscoveryData
• Microsoft.SystemCenter.CollectSignatureData
• Microsoft.SystemCenter.CollectEventData

When a Database or Data Warehouse write action workflow on a Management Server experiences slow data batch insertion, for example times in excess of 60 seconds, it will begin logging Event ID 2115 to the Operations Manager Event log. This event is logged every one minute until the data batch is inserted into the Database or Data Warehouse, or the data is dropped by the write action workflow module. As a result, Event ID 2115 will be logged due to the latency inserting data into the Database or Data Warehouse. Below is an example Event logged due to data dropped by the write action workflow module:

Event Type: Error
Event Source: HealthService
Event Category: None
Event ID: 4506
Computer: <RMS NAME>
Description:
Data was dropped due to too much outstanding data in rule "Microsoft.SystemCenter.OperationalDataReporting.SubmitOperationalDataFailed.Alert" running for instance <RMS NAME> with id:"{F56EB161-4ABE-5BC7-610F-4365524F294E}" in management group <MANAGEMENT GROUP NAME>.

Event ID 2115 contains 2 significant pieces of information. First, the name of the Workflow that is experiencing the problem and second, the elapsed time since the workflow began inserting the last batch of data.

For example:

Log Name: Operations Manager
Source: HealthService
Event ID: 2115
Level: Warning
Computer: <RMS NAME>
Description:
A Bind Data Source in Management Group <MANGEMENT GROUP NAME> has posted items to the workflow, but has not received a response in 300 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectPublishedEntityState
Instance : <RMS NAME>
Instance Id : {88676CDF-E284-7838-AC70-E898DA1720CB}

This particular Event ID 2115 message indicates that the workflow Microsoft.SystemCenter.CollectPublishedEntityState, which writes Entity State data to the Operations Manager database, is trying to insert a batch of Entity State data and it started 300 seconds ago. In this example the insertion of the Entity State data has not yet finished. Normally inserting a batch of data should complete within 60 seconds. If the Workflow Id contains Data Warehouse then the problem concerns the Operations Manager Data Warehouse. Otherwise, the problem would concern inserting data into the Operations Manager database.

Cause

As the description of Event ID 2115 states, this may indicate a database performance problem or too much data incoming from the agents. Event ID 2115 simply indicates there is a backlog inserting data into the Database; Operations Manager or Operations Manager Data Warehouse. These Events can originate from a number of possible causes. For example, a large amount of Discovery data, a Database connectivity issue or full database condition, potential disk or network constraints.

In Operations Manager, Discovery data insertion is a relatively expensive process. We define a burst of data as a short period of time where a significant amount of data is received by the Management Server. These bursts of data can cause Event ID 2115 since the data insertion should occur infrequently. If Event ID 2115 consistently appears for Discovery data collection, this can indicate either a Database or Data Warehouse insertion problem or Discovery rules in a Management Pack collecting too much discovery data.

Operations Manager configuration updates caused by Instance Space changes or Management Pack imports have a direct effect on CPU utilization on the Database Server and this can impact Database insertion times. Following a Management Pack import or a large instance space change, it is expected to see Event ID 2115 messages. For more information on this topic please see the following:

2603913 - How to detect and troubleshoot frequent configuration changes in Operations Manager (http://support.microsoft.com/kb/2603913)

If the Operations Manager or Operations Manager Data Warehouse databases are out of space or offline, it is expected that the Management Server will continue to log Event ID 2115 messages to the Operations Manager Event log and the pending time will grow higher. 

If the write action workflows cannot connect to the Operations Manager or Operations Manager Data Warehouse databases, or they are using invalid credentials to establish their connection, the data insertion will be blocked and Event ID 2115 messages will be logged accordingly until this situation is resolved.  

In Operations Manager, expensive User Interface queries can impact resource utilization on the Database which can lead to latency in Database insertion times. When a user is performing an expensive User Interface operation it is possible to see Event ID 2115 messages logged. 

Event ID 2115 messages can also indicate a performance problem if the Operations Manager Database and Data Warehouse databases are not properly configured. Performance problems on the database servers can lead to Event ID 2115 messages. Some possible causes include the following:

• The SQL Log or TempDB database is too small or out of space.
• The Network link from the Operations Manager and Data Warehouse database to the Management Server is bandwidth constrained or the latency is large. In this scenario we recommend to Management Server to be on the same LAN as the Operations Manager and Data Warehouse server.
• The data disk hosting the Database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a function problem. In this scenario we recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.
• The Operations Manager Database or Data Warehouse server does not have sufficient memory or CPU resources.
• The SQL Server instance hosting the Operations Manager Database or Data Warehouse is offline.

Resolution

The first step in troubleshooting Event ID 2115 is to identify what Data Items are being returned within the Event. For example, the Workflow ID indicates what type of Data Items (Discovery, Alerts, Event, Perf) as well as what Database in question. From the Workflow ID we can then determine the corresponding database. If the Workflow ID contains the term DataWarehouse, then the focus should be towards the Operations Manager Data Warehouse. In other instances the focus would be towards the Operations Manager Database.

The seconds indicator in the Event ID 2115 message returns how long the workflow in question has been waiting to insert the data items into the Database.

Scenario 1

In the example Event ID 2115 below, the problem concerns the workflow Microsoft.SystemCenter.CollectSignatureData.

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Computer: <RMS NAME>
Description:
A Bind Data Source in Management Group <MANGEMENT GROUP NAME> has posted items to the workflow, but has not received a response in 300 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectSignatureData
Instance : <RMS NAME>
Instance Id : {F56EB161-4ABE-5BC7-610F-4365524F294E}

Resolution 1

We can identify the Performance Signature Data Collection Rules in this example by executing the following SQL Query. This query should be executed in SQL Management Studio against the Operations Manager database.

-- Return all Performance Signature Collection Rules
Use OperationsManager
select
managementpack.mpname,
rules.rulename
from performancesignature with (nolock)
inner join rules with (nolock)
on rules.ruleid = performancesignature.learningruleid
inner join managementpack with(nolock)
on rules.managementpackid = managementpack.managementpackid
group by managementpack.mpname, rules.rulename
order by managementpack.mpname, rules.rulename

This query will return all Performance Signature Collection Rules and their respective Management Pack name. A column is returned for Management Pack name and Rule name.

The following Performance Monitor Counters on a Management Server will provide information concerning Database and Data Warehouse write action insertion batch size and time. If the batch size is growing larger, for example the default batch size is 5000 items, this indicates either the Management Server is slow inserting the data to the Database or Data Warehouse, or is receiving a burst of Data Items from the Agents or Gateway Servers.

· OpsMgr DB Write Action Modules(*)\Avg. Batch Size
· OpsMgr DB Write Action Modules(*)\Avg. Processing Time
· OpsMgr DW Writer Module(*)\Avg. Batch Processing Time, ms
· OpsMgr DW Writer Module(*)\Avg. Batch Size

From the Database and Data Warehouse write action account Average Processing Time counter, we can understand how long it takes on average to write a batch of data to the Database and Data Warehouse. Depending upon the amount of time it takes to write a batch of data to the Database, this may present an opportunity for tuning.

Scenario 2

The SQL Server instance hosting the Operations Manager Database or Data Warehouse is offline. Event ID 2115 as well as Event ID 29200 appear within the Operations Manager Event log. For example:

Log Name: Operations Manager
Source: HealthService
Date:
Event ID: 2115
Level: Warning
Description:

A Bind Data Source in Management Group MSFT has posted items to the workflow, but has not received a response in 60 seconds. This indicates a performance or functional problem with the workflow.

Workflow Id : Microsoft.SystemCenter.CollectEventData
Instance : name.contoso.local
Instance Id : {88676CDF-E284-7838-AC70-E898DA1720CB}

Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29200
Level: Error
Description:

OpsMgr Config Service has lost connectivity to the OpsMgr database, therefore it can not get any updates from the database. This may be a temporary issue that may be recovered from automatically. If the problem persists, it usually indicates a problem with the database. Reason:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Resolution 2

To resolve the issue in this scenario, follow these steps:

1. Connect to the Server hosting the Operations Manager database.
2. Open the Services applet.
3. Verify that the SQL Server (MSSQLSERVER) service is started and running.
4. If the SQL Server (MSSQLSERVER) service is not started and running, start the service.

Once Database connectivity is restored workflows should resume successfully storing data within the respective database. Event ID 31554 validates that the information has been written successfully.

For example:

Log Name: Operations Manager
Source: Health Service Modules
Event ID: 31554
Task Category: Data Warehouse
Level: Information

Description:
Workflow succeeded storing data in the Data Warehouse

One or more workflows were affected by this.

Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectEventData
Instance name: name.contoso.local
Instance ID: {88676CDF-E284-7838-AC70-E898DA1720CB}

Scenario 3

Event ID 2115 caused by invalid RunAs Credentials.

Resolution 3

Examine the Operations Manager Event log for the following events. These events typically indicate that the Data Warehouse SQL Server Authentication Account may have incorrect credentials.

Log Name: Operations Manager
Source: HealthService
Event ID: 7000
Task Category: Health Service
Level: Error
Description:

The Health Service could not log on the RunAs account <ACCOUNT NAME> for management group <MANGEMENT GROUP NAME>. The error is Logon failure: unknown user name or bad password.(1326L). This will prevent the health service from monitoring or performing actions using this RunAs account

Log Name: Operations Manager
Source: HealthService
Event ID: 7015
Task Category: Health Service
Level: Error
Description:

The Health Service cannot verify the future validity of the RunAs account <ACCOUNT NAME> for management group <MANGEMENT GROUP NAME>. The error is Logon failure: unknown user name or bad password.(1326L).

To resolve the issue in this scenario, follow these steps:
1. Open the Operations Manager console.
2. Select Administration.
3. Select Run As Configuration\Accounts.
4. Configure the appropriate credentials for the Data Warehouse SQL Server Authentication Account.

Scenario 4

Event ID 2115 caused by disk performance issues. The data disk hosting the Database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a functional problem. In this scenario we recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.

Resolution 4

Counters to identify disk pressure

Capture these Physical Disk counters for all drives that contain SQL data or log files:

• % Idle Time: How much disk idle time is being reported. Anything below 50 percent could indicate a disk bottleneck.
• Avg. Disk Queue Length: This value should not exceed 2 times the number of spindles on a LUN. For example, if a LUN has 25 spindles, a value of 50 is acceptable. However, if a LUN has 10 spindles, a value of 25 is too high. You could use the following formulas based on the RAID level and number of disks in the RAID configuration:

• • RAID 0: All of the disks are doing work in a RAID 0 set
  • Average Disk Queue Length <= # (Disks in the array) *2
  • RAID 1: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • RAID 10: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • RAID 5: All of the disks are doing work in a RAID 5 set
  • Average Disk Queue Length <= # (Disks in the array/2) *2
  • Avg. Disk sec/Transfer: The number of seconds it takes to complete one disk I/O
  • Avg. Disk sec/Read: The average time, in seconds, of a read of data from the disk
  • Avg. Disk sec/Write: The average time, in seconds, of a write of data to the disk
  • Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
  • Disk Transfers/sec: The number of input and output operations per second (IOPS)

  NOTE The last three counters in this list should consistently have values of approximately .020 (20 ms) or lower and should never exceed.050 (50 ms). The following are the thresholds that are documented in the SQL Server performance troubleshooting guide:

  • 1. • Less than 10 ms: very good
       • Between 10 - 20 ms: okay
       • Between 20 - 50 ms: slow, needs attention
       • Greater than 50 ms: serious I/O bottleneck
  • Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
  • Disk Transfers/sec: The number of input and output operations per second (IOPS)

• Troubleshooting Performance Problems in SQL Server 2008
• Troubleshooting Performance Problems in SQL Server 2005

Scenario 5

Event ID 2115 is logged, and a management server generates an "unable to write data to the Data Warehouse" alert in System Center Operations Manager.
You experience the following symptoms on a management server computer that is running Microsoft System Center Operations Manager:

• The management server generates one or more alerts that resemble the following:
  Performance data collection process unable to write data to the Data Warehouse
  
  Performance data collection process unable to write data to the Data Warehouse. Failed to store data in the Data Warehouse. Exception 'SqlException': Management Group with id '9069F7BD-55B8-C8E8-1CF9-4395F45527E2' is not allowed to access Data Warehouse under login 'DOMAIN\Action_Account' One or more workflows were affected by this. Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Instance name: dataWarehouseServer.domain.com Instance ID: {48936EE3-4E3E-BEE1-8C09-AFDAB8ECF236} Management group: Management Group Name.
• The following event is logged in the Operations Manager event log on the management server:
  Event Type: Warning
  Event Source: HealthService
  Event Category: None
  Event ID: 2115
  Date: date
  Time: time
  User: N/A
  Computer: ManagementServerName
  Description: A Bind Data Source in Management Group Management Group Name has posted items to the workflow, but has not received a response in 1712 seconds. This indicates a performance or functional problem with the workflow. Workflow Id : Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Instance : ManagementServerName.domain.com Instance Id : {C7FDDE2A-E0AA-4B80-70DE-1D50D9965221}

Resolution 5

This issue may occur if the management server does not have accounts that are specified for its data warehouse "Run As" profiles. This issue is more likely to affect a secondary management server.

To resolve this problem, follow these steps:

1. On the computer that is running System Center Operations Manager, open the Operations Console.
2. In the navigation pane, click Administration.
3. Expand Security, and then click Run As Profiles.
4. In the Run As Profiles view, double-click Data Warehouse Account.
5. In the Run As Profile Properties - Data Warehouse Account properties dialog box, click the Run As Accounts tab, and then click New.
6. In the Run As Account list, click Data Warehouse Action Account.
7. In the Name list, click the management server that generated the alert.
8. Click OK two times.
9. Follow steps 4 through 8 to assign the appropriate Run As account to the following profiles:
   Data Warehouse Configuration Synchronization Reader Account
   Data Warehouse Report Deployment Account
   Data Warehouse SQL Server Authentication Account
10. For each profile, select the Run As account that matches the name of the Run As profile. For example, make the following assignments:
    Assign the Data Warehouse Configuration Synchronization Reader Account to the Data Warehouse Configuration Synchronization Reader Account profile.
    Assign the Data Warehouse Report Deployment Account to the Data Warehouse Report Deployment Account profile.
    Assign the Data Warehouse SQL Server Authentication Account to the Data Warehouse SQL Server Authentication Account profile.
11. On the management server that generated the alert, restart the OpsMgr Health Service.
12. In the Operations Manager event log on the management server, verify that event ID 31554 events are logged.
    NOTE Event ID 31554 indicates that the monitor state has changed to Healthy. This change resolves the alert.

Scenario 6

Event ID 2115 occurs on a server running HP MPIO FF DSM XP v3.01 to which there are no LUNs presented. When the user opens Performance Monitor and attempts to add a counter, Performance Monitor will hang and the handle count for this application increases rapidly.

Resolution 6

There are two workaround regarding this issue.

1. Rename the HPPerfProv.dll file and reboot Windows. Performance Monitor will work without issue when the file is renamed and not loaded.
2. Have at least 1 LUN present on the system.

For more information on this issue please see the following:

Event ID 2115 is caused by HPPerfProv.DLL
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01743552&prodTypeId=18964&prodSeriesId=421492

=====

For the most current version of this article please see the following:

2681388 : How to troubleshoot Event ID 2115 in Operations Manager

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s a new Knowledge Base article we published this morning. This one is more of a heads-up but it explains what you may see if you try to import a Management Pack in OpsMgr but haven’t imported the other Management Packs that are listed as dependencies first.

=====

Summary

When importing a management pack in System Center Operations Manager 2007 that has a dependency on another management pack, the import may fail with the following message:

<ManagementPackName> could not be imported.

If any management packs in the Import list are dependent on this management pack, the installation of the dependent management packs will fail.
The requested management pack was invalid. See inner exception for details.
Parameter name: managementPack

More Information

This issue occurs because a management pack that the management pack being imported depends on isn't imported in the management group. In order to work around this problem, import the dependent management packs first then import the management packs that depend on them.

NOTE If you're unsure of the dependencies for a management pack, they will be listed in the management pack guide.

=====

For the most current version of this article please see the following:

2698846 : Importing a Management Pack in System Center Operations Manager fails if a dependent management pack isn't imported

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Here’s one more Knowledge Base article we published this morning. This one shows you how to easily fix an issue where the Microsoft System Center Operations Manager 2007 R2 (OpsMgr) Connector for HP OpenView fails to auto-forwarding alerts to an HP OVO server.

=====

Symptoms

The Microsoft System Center Operations Manager 2007 R2 (OpsMgr) Connector for HP OpenView Operations for Windows fails to auto-forwarding alerts to an HP OVO server. You also find information similar to the following in the SCInterop log file:

[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] ERROR Could not deliver some events. No providers were available. Cannot create WSManConfig for any providers
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Microsoft.SystemCenter.Interop.NoProviderAvailableException: Cannot create WSManConfig for any providers
at Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule.BuildWsmanConfigList(IConfig c)
at Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule.XFormOutboundAlerts_Callback(Topic topic, Payload payload)
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Exiting WSRxAlerts_Callback method...
[Microsoft.SystemCenter.Interop.Framework.Modules.XFormModule] DEBUG Leaving CacheAlerts_Callback
[Microsoft.SystemCenter.Interop.Framework.Modules.Cache] DEBUG Leaving FilterAlerts_Callback
[Microsoft.SystemCenter.Interop.Framework.Modules.FilterModule] DEBUG alerts published
[Microsoft.SystemCenter.Interop.Framework.Modules.FilterModule] DEBUG Leaving OpsAlerts_Callback
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG 3 alerts published
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG acking alerts 3 to sdk
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG 3 alerts acked to sdk
[Microsoft.SystemCenter.Interop.Framework.Modules.OpsMgrModule] DEBUG Leaving TimerCallback
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Entering TimerCallback method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Retrieving events...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG locked on WSRxAlerts
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG BuildWsmanConfigList called
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG Not all providers have be queried for WSManType. Attempting to query each provider
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManConfig] DEBUG WSManConfig constructor called
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManConfig] DEBUG Creating WSManConfig for OVO Server
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Entering GetWSManType method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Entering CreateSession method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG using basic auth
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Calling WSMAN Session host OVO Server with parameters...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG ResourceUri : https://OVO Server:1270
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG SessionFlags : 266241
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG UserName : root
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Exiting CreateSession method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Calling WSMAN Identify on host OVO Server with parameters...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Flags : 0
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Exception A security error occurred occurred while determining WSMan type of server OVO Server
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManWrapper] DEBUG Exiting GetWSManType method...
[Microsoft.SystemCenter.Interop.Framework.Modules.WSManModule] DEBUG System.Runtime.InteropServices.COMException (0x80072F8F): A security error occurred
at WSManAutomation.IWSManSession.Identify(Int32 flags)

Cause

This can occur if there are no providers can be contacted to get an update event.

Resolution

To resolve this issue, run scicert.exe to import the certificate from the provider into the connector server. To do this, on the server that the OpsMgr Connector for HP OpenView Operations service is installed, run the following command from a command prompt window:

C:\Program Files\System Center Operations Manager 2007 R2 Connectors\OpsMgr Connector for HP OpenView Operations\

Then run the following command:

scicert <OVO server> <wsman user> <wsman password> "OpsMgr Connector for HP OpenView Operations"

NOTEReplace <OVO server> with your OVO server name

NOTE<wsman user> will be the user you setup in the Connector Configuration UI (e.g., - doman\wsman user or root account)

If this is successful it will display the certificate thumbprint and ask if you want to continue. Enter Yes to import the certificate.

Once you have the certificate imported, restart the OpsMgr Connector for HP OpenView Operations service and check the log.

You should no longer see the error and should now be able to forward alerts to the OVO Server.

=====

For the most current version of this article please see the following:

2693106 : The Operations Manager OpenView connector fails to auto-forwarding alerts to an HP OVO server

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

We are very happy to announce that seven of the Product Solution Centers on http://support.microsoft.com are featuring new Top Solutions sections that pull dynamically from the Top Solutions RSS feeds. The Top Solutions are usually listed on the page for the Key Resources tab.

The following solution centers have dynamic Top Solutions; the rest will be updated in the near future. Check out the new look and functionality!

• Windows Server 2008 R2
• SQL Server
• System Center 2012– select the tabs for the following products
  • Configuration Manager
  • Data Protection Manager
  • Operations Manager
  • Virtual Machine Manager
• Lync Server

If you want to keep up to date on all the latest top solutions you’ll definitely want to check these out.

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/