Here’s a new Knowledge Base article we published today. This one talks about an issue where the Orchestrator Runbook Service starts and then stops after 30-60 seconds and logs a 7023 event.
The Orchestrator Runbook Service (orunbook) on a System Center Orchestrator Runbook Server starts successfully but then terminates after 30-60 seconds. In the System Event Log of the System Center Orchestrator Runbook Server, the following sequence of events will be seen:
Log Name: System Source: Service Control Manager Date: Event ID: 7036 Task Category: None Level: Information Keywords: Classic User: N/A Computer: <Computer> Description: The Orchestrator Runbook Service service entered the running state.
Log Name: System Source: Service Control Manager Date: Event ID: 7036 Task Category: None Level: Information Keywords: Classic User: N/A Computer: <Computer> Description: The Orchestrator Runbook Service service entered the stopped state.
Log Name: System Source: Service Control Manager Date: Event ID: 7023 Task Category: None Level: Error Keywords: Classic User: N/A Computer: <Computer> Description: The Orchestrator Runbook Service service terminated with the following error: %%-2147467259
Additionally the following may be observed.
When querying the status of the Orchestrator Runbook Service using SC.exe, the following output shows the last exit code when the service is in a stopped state:
C:\Windows\system32>sc query orunbook
SERVICE_NAME: orunbook TYPE : 10 WIN32_OWN_PROCESS STATE : 1 STOPPED WIN32_EXIT_CODE : -2147467259 (0x80004005) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0
One or more exceptions may be captured in the Orchestrator Runbook Service logging folder on the Orchestrator Runbook Server computer. The default path for these logs is "C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookService.exe\Logs".
The Orchestrator Runbook Service was not able to connect to the Orchestrator database. This could be due to any of the following reasons:
Correct the problem that is preventing the Orchestrator Runbook Service from connecting to the Orchestrator database.
The Orchestrator Runbook Service will only terminate due to failed connectivity to the Orchestrator database during the service start. Once the service has successfully started with full database connectivity, any future database issues will be captured and logged without the service terminating. This issue occurs most frequently when the System Center Orchestrator environment is restarted and the Orchestrator Runbook Service starts before the Orchestrator database is fully online. In this case, configuring the Orchestrator Runbook Service Recovery Properties can often automatically remediate the problem by having the service wait a period of time and then attempt to start again.
For the most current version of this article please see the following:
2702157 - The Orchestrator Runbook Service starts and then stops after 30-60 seconds
J.C. Hornbeck | System Center & Security Knowledge Engineer
Get the latest System Center news on Facebook and Twitter:
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 encountered this issue when I was deploying a single server scenario. Except mine wasn't truly a single server as I had a remote SQL server. After verifying none of the possible causes existed in my configuration, I uninstalled all the Orchestrator components. I then re-installed them, one at a time, on a single server and haven't seen this symptom recur.