we have new installations of scsm 2012 and scorch 2012.  SSP is setup in scsm.

we created a basic runbook to create a new AD user, taking data from scsm 2012 using the initialize data object.  when we execute the runbook using the runbook tester, it works fine.  we verified the scsm security accounts have the proper permissions on teh runbook folder structure, and the runbooks themselves.

from that runbook in scsm2012 we created a runbook automation activity template, a SR template off of that, a request offering off of that and a service offering from that.  after doing that, we go into the SSP as a SCSM or SCORCH admin account and input the requested data (user name, employee ID, etc) and submit it

we see in scsm a SR is generated, as expected, with the input values from the user.  a runbook activity is created.  the log entries in the SCSM RB show the runbook is invokation is started and scsm attempts to pass the input parameters from the SSP. 

immediately, the RB activity in SCSM fails with the error:

"runbook invocation had an error.  possible reasons can be that permissions hav echanges, it no longer exists or its contract has changed.  See eventlog for additional information

Exception of type System.Data.Services.Client.DataServiceRequestException was thrown. The message is An error occurred while processing this request."

We reviewed permissions of our accounts in scsm and scorch, including on the runbooks themselves.  We tore down and rebuilt the SSP offering from scratch, and ensured the iniatialize data parameter on the runbook hadn't changed and the runbook showed as 'Active' in SCSM.

We do not see any log of the runbook being executed in SCORCH at all.

We even reinstalled SCORCH 2012 with a new DB and rebuilt our runbooks.

What are we missing?

Hi Beneb,

It seems to me that you've changed something in the initialize data activity after the runbook has been synchronized to SCSM, which will break the relationship.

If you open SCSM console and go to Library - Runbooks you'll probably see that the status is missing.

The only thing you can do is to delete the runbook and sync it over Again - after that you'll need to create the runbook activity template Again and so on.

Let me know if this is the issue.

Br,

I've seen this happen for different reasons in our environment, but the most simplest reason is normally that i have forgotten to check in the Runbook. There were some permission issues that caused this as well, i'll try and dig out what i did there also.

• Marked as answer by beneb Tuesday, June 26, 2012 7:49 PM

I've seen this happen for different reasons in our environment, but the most simplest reason is normally that i have forgotten to check in the Runbook. There were some permission issues that caused this as well, i'll try and dig out what i did there also.

• Marked as answer by beneb Tuesday, June 26, 2012 7:49 PM

Kenneth,

Thanks for your suggestion, but if you read my initial post carefully you will see that is not the case.

In SCSM our runbooks show up as 'Active'.  We have gone so far as to delete everything associated with that runbook in SCSM (service offering, request offering, SR template, runbook automation activity template, runbooks and scorch connector) and rebuilt in reverse taking care not to modify the runbook at all.

The contract for the runbooks in scsm is fine, as far as we can see.

Andrew,

Great point.  I'll try this again, taking care to check in the runbook first.  I look forward to any other information you have related to permissions.

Sure my mistake. :-( As Andrew say - you might check if the runbook is checked in.

Andrew,

As embarrassing as this is to admit, our problem was caused by not checking in our Runbook prior to executing the service offering.

As soon as we checked it in, our runbook ran properly when executed from our SSP Service Offering.

Thanks for the good suggestions!

-Ben

It sounds as though you've got the permissions sussed out, but here's the steps i had to work through initially using these two articles...

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

http://blog.scsmfaq.ch/2011/11/12/news-in-scsm12-beta-8-permissions-for-triggering-system-center-orchestrator-runbooks/

Essentially i had to add the Service Manager Workflow account to the Orchestrator Users Group, in fact i think i also added the Operational Database Account for safe measure i got so fed up with it. But i think you can test this by logging onto a machine as the Workflow Account, browsing to http://<SCO SERVER>:82, and try running the runbook. If the account didn't have permissions this should fail.

No worries it's often the simplest thing that catches me out. Trust me i was about to wreck the office by the time i figured that one out :-)

______________________________________________________

Andrew France http://andrewsprivatecloud.wordpress.com/

I had a problem that we have user creation service request which uses runbook to create the user (it has child run books) .we are able to create first user without issues but unable to create second user with the same service request template.when we create second request the parent runbook change status to "run" but nothing happens after that. Note:we have checked the same with runbook tester and succeed .