You are browsing the archive for 2012 August.

Orchestrator 2012 : Kelverion IP – problem with the update activity

9:17 am in Orchestrator by Christopher Keyaert

Hi Guys,

I recently worked on a project for creating a connection between Operations Manager 2007 (SCOM) and BMC Remedy. As we have Orchestrator 2012 in place, we will use the Kelverion IP (

This integration pack use the BMC Remedy Web Service, it’s quite easy to configure. Everything was working as expected, excepted the Update Request activity.


The field was well updated in Remedy but the activity always returned with a failed status :


In fact, the response returned from the Set operation does not contain any fields.

The Kelverion Support Team haven’t seen this before as in Remedy v7.1, 7.5 & 7.6 there is always a field returned.  This appears to be a Remedy version 7.01 web service anomaly.

The solution is quite simple, in the configuration of the Set operations of the Remedy Web Service, just return a field. In our case, we configured the Remedy Web Service to return the Incident_Number. Don’t forget to delete your cache : Orchestrator 2012 / Kelverion IP : Remedy Web Service Reference Cache


And after that the Update activity from the Kelverion Integration Pack is now returning a Success Smile


I would like to thank Greg Charman from the Kelverion Support Team for his contribution.



SCOM 2007 R2 : Configuration not loaded

7:45 am in Operations Manager by Christopher Keyaert

Hi Guys,

On Tuesday, the SCOM 2007 R2 infrastructure of one of my customer reflected the following symptoms :

  • Newly installed agents display as "Not Monitored" in the Operations Console.
  • 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 will 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.
  • SCOM Email alerts will not triggered.
  • RMS event log is flooded by event 21042: Operations Manager has discarded 1 items in management group MGTGROUP, which came from $$ROOT$$. These items have been discarded because no valid route exists at this time. This can happen when new devices are added to the topology but the complete topology has not been distributed yet. The discarded items will be regenerated.
  • RMS contains the event 29106: The request to synchronize state for OpsMgr Health Service identified by "a340d2a9-ab1b-2e53-ca78-d303510c831d" failed due to the following exception "Microsoft.EnterpriseManagement.Common.DataItemDoesNotExistException: An instance was deleted before its properties could be read.On the RMS, if you deleted the Health Service State folder and restarted the 3 SCOM Services, the file "OpsMgrConnector.Config.xml" is not generated and on the MS you have the event 20070: The OpsMgr Connector connected to RMSFQDN, but the connection was closed immediately after authentication occurred. The most likely cause of this error is that the agent is not authorized to communicate with the server, or the server has not received configuration. Check the event log on the server for the presence of 20000 events, indicating that agents which are not approved are attempting to connect.

Concerning the resolution, the first step is to make sure to have a good backup of all your Operations Manager databases /!\ The actions below are not supported, do it at your own risk /!\

Connect on the OperationsManager Database and run the following query :

This query will look for the objects that have not been completely and correctly deleted from the database. Normally this query must return nothing, but in our case, it returned a BaseManagedEntityId. This GUID correspond to an object that has been deleted but some references are still existing in the DB.


We have now to identify which computer is behind this id. For that run that following query


In our case, it returned an exchange server, I did a quick check of the server itself, SCOM agent is installed, nothing strange in the log. I went back in my SCOM console, and there, impossible to find the computer in the agent managed view. The object is well deleted but not all his references.

As this server seems to be cause of our trouble, we will delete all his references from the database by running the following query.

Now, go back to the RMS, stop the 3 SCOM services, delete the ‘Health Service State’ folder and restart the 3 SCOM services.

Normally, after a few second the OpsMgrConnector.Config.xml file will be created in the “%ProgramFiles%\System Center Operations Manager 2007\Health Service State\Connector Configuration Cache\MGTGROUP” and everything will start to work correctly.

Now concerning the root cause itself, I don’t have any explication, why this server and all his references have not been successfully deleted the first time ? How one server references could cause so much trouble to the infrastructure?

I would like to thank you my MVP friends Silvio Di Benedetto, Marnix Wolf, Bob Cornelissen and also Mihai Buia from the Microsoft Premier Support for their help to resolve this problem.



Online Meeting : Expert Round Table on Veeam Virtualization Experience

8:01 am in Uncategorized by Christopher Keyaert

Hi Guys,

With my friends Kenny (SCCM MVP) and Alex (SCOMMVP), we will participate to an online meeting organized by Veeam: “Expert Round Table – Veeam Virtualization Experience”. This free online round table will take place on September 27th, don’t forget to register :



Orchestrator 2012 / Kelverion IP : Remedy Web Service Reference Cache

12:56 pm in Uncategorized by Christopher Keyaert

Hi Guys,

I’m currently working on an integration between Orchestrator 2012 and BMC Remedy. For that, I’m using the free Integration Pack from Kelverion and I’ll provide more information about the Web Service Reference Cache that is used by this IP.

The Kelverion Integration Pack for BMC Remedy AR System uses web services to integrate with Remedy AR System. In order to support on-demand connections to any Remedy AR System web service the integration pack will automatically download the appropriate WSDL and generate the required web service proxies as required. This process can be time consuming, so in order to improve performance, the integration pack maintains a local cache of web service proxies on
each runbook service and Runbook Designer host system.

Although the cache provides a significant performance benefit, there is a chance that these files can become outdated whenever changes are made to a Remedy AR System web service. In order to synchronize changes to a Remedy AR System web service, you must clear the local web service cache so that the required files can be re-generated.

To remove the Remedy AR System web service cache on Windows Server R2:

  • Close the Orchestrator Runbook Designer
  • Delete the *.dll files from the folder C:\Users\%USERPROFILE%\AppData\Local\Kelverion Automation\Integration Pack for BMC Remedy\%WebServerURL%\arsys\%ARServer%


  • Repeat for each user profile that is used by Orchestrator components.
  • Delete the *.dll files from the folder C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Kelverion Automation\Integration Pack for BMC Remedy\%WebServerURL%\arsys\%ARServer%


Each time that you update your Remedy Web service, you’ll have to delete the Remedy Web Service Reference Cache on the Orchestrator server.