Dear All,

In this post, I’ll explain you how to install an Orchestrator 2012 runbook server in an untrusted Active Directory domain.
Installing a runbook server in an untrusted AD domain is required when your integration pack or workflow activities are not able to manage several Active Directory domain/credentials and are using only the Orchestrator Service Account to run.

With this new runbook server installed, you will be able to start runbooks from your Runbook management server located in your primary domain and execute it directly on the runbook server hosted in the untrusted domain. You just need to ensure that the service account which is used by the runbook server in the untrusted domain has the necessary rights to execute the required actions in that untrusted active directory domain.

Let’s go for this implement J

Prerequisites:

Definition

I will define two “key words” that I’ll use for the rest of this post:

• Primary domain: Active Directory domain where you have your Orchestrator 2012 infrastructure installed.
• Untrusted domain: Active Directory domain that doesn’t have any AD trust with your Primary domain.

Infrastructure

• An Orchestrator 2012 infrastructure installed in your primary domain.
• A fresh new installed server in the untrusted domain on which we will install the runbook server role.

Service Accounts

• In your primary domain, on your SQL server, Orchestrator 2012 SQL Instance, you have to create a SQL User Account that is DB_Owner of the Orchestrator database.
• Ensure the SQL is in mixed mode and allows connection from AD and SQL accounts.
• In the untrusted domain, you have to create a service account that is identical (Same SamAccoutName and Password) to the Orchestrator service account that is currently used by the Orchestrator 2012 infrastructure in you primary domain. If the service account used in your primary domain is SA_Orchestrator with the password: P@$$w0rd you have to create the service account SA_Orchestrator with the same password in the untrusted domain. This account must be local admin of the server on which you will install the Orchestrator Runbook server role.

   

Installation:

You have new an Ochestrator Runbook server that is installed in another active directory domain that your Orchestrator Management server.
I hope that this post is helpful for your and fell free to post your comments

Christopher

directory domain · Infrastructure · key words · Orchestrator · service accounts

Hi

During a migration project from Opalis 6.3 to Orchestrator 2012, I had to migrate a runbook that was using the Monitor SNMP Trap activity. The idea of this runbook is to receive a trap that is composed of two OIDs, first one contains the target name and the second one contains the description and to raise an alert in Operations Manager (SCOM) based on there values.

In Opalis, as I explained here : http://scug.be/christopher/2011/06/17/system-center-opalis-monitor-snmp-trap-activity/ this configuration is working. Now, it’s time to migrate it ! As this is a quite simple runbook, I just did a runbook export in Opalis, an import in Orchestrator and started the runbook.

To test the good working of my newly imported runbook, I sent several SNMP traps to my orchestrator server. I noticed that the Monitor SNMP Trap activity catch the trap, published the result correctly, but when I checked the content of the trap, the result was really not what I was expecting. Let’s me explain what I did in detail.

I used the command line application SNMPTrapGen ( http://www.snmpsoft.com/freetools/snmptrapgen.html ) , to send a SNMP trap to the Orchestrator server. Below the content of my SNMP Trap :

C:\SnmpTrapGen.exe -r:OrchestratorServer -v:2c -p:162 -to:.1.3.6.1.4.1 -vid:.1.3.6.1.4.1.11307.10.1 -val:'azerty' -vtp:str
SnmpTrapGen v1.1 - Copyright (C) 2009 SnmpSoft Company
[ More useful network tools on http://www.snmpsoft.com ]

OK

 

As my trap contained the string ‘azerty’, I was expecting to receive the same value from the Monitor SNMP Trap activity in Orchestrator, but I received the following value :

399712210111411612139

I did several tests and every time that I sent a SNMP Trap that was containing a string to Orchestrator, the Monitor SNMP Trap activity published a suite of numbers, which was really not the contain that I was expecting. I also did a network capture on the Orchestrator to check if the trap content was correct and yes, it was.

As it was not working when I sent a string value, I tried to sent an integer value to Orchestrator :

C:\SnmpTrapGen.exe -r:gdcgmsoap702 -v:2c -p:162 -to:.1.3.6.1.4.1 -vid:.1.3.6.1.4.1.11307.10.1 -val:12345 -vtp:int
SnmpTrapGen v1.1 - Copyright (C) 2009 SnmpSoft Company
[ More useful network tools on http://www.snmpsoft.com ]

OK

and there, Orchestrator returned the right value.

12345

After all my tests, I observed that the Monitor SNMP Trap activity always returned a suite of number when the SNMP trap was containing a string value. In that project, It’s what I need to do, I have to pass a string value to this activity. As this was working perfectly with Opalis and not anymore with Orchestrator, I continued my investigation and I focused on the Monitor SNMP Trap activity itself.

By default, this activity  use the Microsoft SNMP Trap Services :

I decided to choose the “No dependency’” connection. For that configuration, the first step is to stop and disable the SNMP Trap service on the Orchestrator server.

I changed the connection setting of the Monitor SNMP Trap activity and I started my runbook again.

I sent a new trap, which was containing a string value, to my Orchestrator with the SNMPTrapGen command line..

C:\SnmpTrapGen.exe -r:gdcgmsoap702 -v:2c -p:162 -to:.1.3.6.1.4.1 -vid:.1.3.6.1.4.1.11307.10.1 -val:"azerty test" -vtp:str
SnmpTrapGen v1.1 - Copyright (C) 2009 SnmpSoft Company
[ More useful network tools on http://www.snmpsoft.com ]

OK

And this time, when I checked the value returned by the Monitor SNMP Trap activity, it was correct

azerty test

Yes, We have a solution to get this working ! I don’t know exactly why this was working correctly with the Microsoft SNMP Trap Service in Opalis 6.3 and not anymore with the same service in Orchestrator 2012. If you have me more information about it, please contact me.

As I changed the Monitor SNMP Trap activity connection to No Dependency, we are now limiting to run only one instance of the Monitor SNMP Trap activity on this Orchestrator server (on the same port),  which was not the case by using the Microsoft SNMP Trap Service connection. By changing the connection type, this activity is taking the control on the defined port and it seems logical that it cannot be shared with another activity.

Now that I can only use one Monitor SNMP Trap activity, what can I do if I need to receive SNMP Traps from several locations  ? Well, You will have to redesign your runbooks to get only one entry point for all the SNMP traps :

Configured the Monitor SNMP Trap activity to get and publish all the different OIDs that you will need .

On the link between the Monitor SNMP Trap and the Invoke Runbook activities, apply a filter based on the SNMP Trap sender IP address.

You have to define all the published OIDs value that you need to pass to your Invoke Runbook activity.

And finally pass these information to your original runbook by replacing the Monitor SNMP Trap activity with an Initialize Data activity .

I hope this post could help you to configure the SNMP Trap monitor with Orchestrator 2012.

Christopher Keyaert

Orchestrator

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 (http://www.kelverion.com/).

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 :

Failed to execute 'Set' operation. Sequence contains no elements

Exception: RemedyServiceException
Target site: ExceptionFactory.SetException

Stack trace:
   at Kelverion.BMC.Remedy.Web.WebCore.ExceptionFactory.SetException(Exception cause)
   at Kelverion.BMC.Remedy.Web.WebCore.RemedyService.Set(IEnumerable`1 values)
   at Kelverion.BMC.Remedy.Domain.DomainCore.UpdateRequestCommand.DoExecute()
   at Kelverion.BMC.Remedy.Domain.DomainCore.ExecuteContext.ExecuteActivity(UpdateRequestActivity activity)
   at Kelverion.BMC.Remedy.Activities.UpdateRequestActivity.Execute(IExecuteContext context)
   at Kelverion.BMC.Remedy.Activities.RemedyActivity.Execute(IActivityRequest request, IActivityResponse response)

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

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

Regards

Christopher

context · Orchestrator · remedy · SetException · update

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 (http://www.kelverion.com/).

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 :

Failed to execute 'Set' operation. Sequence contains no elements

Exception: RemedyServiceException
Target site: ExceptionFactory.SetException

Stack trace:
   at Kelverion.BMC.Remedy.Web.WebCore.ExceptionFactory.SetException(Exception cause)
   at Kelverion.BMC.Remedy.Web.WebCore.RemedyService.Set(IEnumerable`1 values)
   at Kelverion.BMC.Remedy.Domain.DomainCore.UpdateRequestCommand.DoExecute()
   at Kelverion.BMC.Remedy.Domain.DomainCore.ExecuteContext.ExecuteActivity(UpdateRequestActivity activity)
   at Kelverion.BMC.Remedy.Activities.UpdateRequestActivity.Execute(IExecuteContext context)
   at Kelverion.BMC.Remedy.Activities.RemedyActivity.Execute(IActivityRequest request, IActivityResponse response)

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

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

Regards

Christopher

DoExecute · Orchestrator · Pack · Scom · Set

Dear All,

Yesterday, it was the Community Day 2012 event in Belgium and I was there to speak about “How to automate your server provisioning”.
I just published my Slide deck on SlideShare :

I also uploaded the Orchestrator Runbook and the Service Manager Management Pack that we created during the demo. http://scug.be/christopher/files/2012/06/CommunityDay.zip

The session has been also recorded and will be available soon online.

I was really a great event, and I hope to see you there next year !!!

Regards
Christopher

belgium · event · Manager · Orchestrator · PowerPoint