System Center Orchestrator Not Working, Diagnosed and Fixed (2026 Guide)
Why This Is Happening
I know exactly how this feels. You've got runbooks waiting to run, automations queued up, maybe a change window tonight, and your System Center Orchestrator Runbook Service just will not stay running. You start the orunbook service, watch it flip to Running in Services, and then 30 to 60 seconds later it's dead again. No helpful error dialog. Just a quiet, infuriating stop.
Here's the honest truth: the error message Microsoft surfaces in this situation, error code -2147467259 (0x80004005), is one of the least informative codes in the Windows ecosystem. It translates roughly to "unspecified error," which is Microsoft's polite way of saying the service hit an unhandled exception it couldn't describe cleanly. That doesn't help you at midnight before a maintenance window. So let's break down what's actually going on.
In the overwhelming majority of cases where System Center Orchestrator is not working and the Runbook Service keeps crashing, the root cause is a broken or misconfigured connection to the Orchestrator SQL Server database. The service boots, attempts to reach its backend database, gets refused or times out, and exits cleanly with that cryptic 0x80004005 exit code. There are six specific sub-causes that account for almost every case I've seen:
- The SQL Server instance that hosts the Orchestrator database simply isn't running
- The SQL Server hostname doesn't resolve correctly in DNS, especially common after a server rename or network migration
- An incorrect SQL Server instance name has been configured inside Orchestrator's settings
- A mismatched TCP/IP port, either Orchestrator is targeting the wrong port, or SQL Server's listener port was changed without updating Orchestrator
- TCP/IP protocol isn't enabled in SQL Server Configuration Manager, or an alternative protocol like Named Pipes is configured at a higher priority and failing
- The service account running
orunbookdoesn't have the necessary permissions to log into the Orchestrator database
There's also a separate, less common cause involving a SQL Server configuration option called disallow results from triggers. When this server-level option is set to 1, it blocks certain stored procedures that Orchestrator's runtime depends on, specifically the CompleteJob procedure called inside sp_UnpublishPolicyRequest. This causes a different class of Orchestrator runtime failure that I'll cover in the Advanced section.
You'll see specific Event IDs in your System event log when this happens: Event ID 7036 fires twice (once for "entered the running state," once for "entered the stopped state"), followed by Event ID 7023 with the error text "terminated with the following error: %%-2147467259." Those three events in sequence are the fingerprint of this problem. If that's what you're seeing, you're in the right place.
System Center Orchestrator not working properly doesn't have to derail your day. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into TCP/IP configurations or DNS troubleshooting, start here. This single check resolves more than half the cases I've seen where the Orchestrator Runbook Service keeps stopping.
Open SQL Server Configuration Manager on your SQL Server host (not the Orchestrator runbook server, the actual machine running SQL Server). Go to SQL Server Services in the left pane. Look at the instance that hosts your Orchestrator database. If its state shows Stopped, that's your answer. Start it, then go back to your Orchestrator runbook server and start the orunbook service again. Nine times out of ten, it stays running.
If SQL Server is running, the next fastest check is a manual connection test. Open SQL Server Management Studio (SSMS) on the Orchestrator runbook server itself, not the SQL Server host, specifically the runbook server machine. Attempt to connect to the SQL instance name exactly as it's configured in Orchestrator. If the connection fails from that machine, you've confirmed a network or name resolution problem without having to dig through logs.
To find what SQL instance Orchestrator is actually configured to connect to, open the Orchestrator Runbook Designer, go to Options > Runbook Server, and note the SQL Server name and instance listed there. That string must match exactly what SQL Server is listening on, and it must resolve from the runbook server's perspective.
If SSMS connects fine but the service still crashes, run this from an elevated Command Prompt on the runbook server:
sc query orunbookAfter the service stops, look at the WIN32_EXIT_CODE line. If you see -2147467259 (0x80004005), you're dealing with the database connectivity issue this guide covers. If you see a different code, check the exception logs at:
C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookService.exe\LogsThose logs often contain a .NET exception stack trace that points directly at the failing component.
This is ground zero. Open SQL Server Configuration Manager on the SQL Server host. Navigate to SQL Server Services. Find the instance that hosts your Orchestrator database, if you're not sure which one, it's usually listed in the Orchestrator setup documentation for your environment or in the Orchestrator Deployment Manager settings.
Confirm the service state shows Running. If it's stopped, right-click and select Start. Watch for it to stabilize, occasionally SQL Server will start and then stop immediately if there's a separate underlying issue like a corrupt system database or insufficient disk space for transaction logs.
Once SQL Server is confirmed running, verify basic network reachability. From the Orchestrator runbook server, open an elevated PowerShell window and run:
Test-NetConnection -ComputerName YOUR_SQL_SERVER_HOSTNAME -Port 1433Replace YOUR_SQL_SERVER_HOSTNAME with the actual hostname or FQDN. If TcpTestSucceeded comes back False, you have a network or firewall block between the runbook server and SQL Server. Contact your network team, port 1433 must be open between those two machines, or whatever custom port your SQL instance uses if it's been changed from the default.
If the TCP test succeeds but the Orchestrator Runbook Service still crashes, move to Step 2. If it fails, don't waste time on anything else until port access is resolved.
What success looks like: TcpTestSucceeded : True in the PowerShell output, and the SQL Server service showing Running in Configuration Manager. Then attempt to start the orunbook service and watch if it holds.
Even when SQL Server is running and ports are open, System Center Orchestrator not working can trace back to a DNS resolution failure that's invisible unless you specifically look for it. This is especially common after server renames, datacenter migrations, Active Directory changes, or when the Orchestrator runbook server lives in a different subnet or domain from the SQL Server host.
From the Orchestrator runbook server, open PowerShell and run:
Resolve-DnsName YOUR_SQL_SERVER_HOSTNAMEThe IP address returned must match the actual IP of the SQL Server host. Cross-check this by running the same command from another machine on the same network, if the results differ, you have a DNS inconsistency.
Also verify the reverse lookup. Run:
Resolve-DnsName THE_SQL_SERVER_IP_ADDRESSSome SQL Server configurations and Kerberos authentication flows require reverse DNS to work correctly. If this returns the wrong hostname or fails entirely, that alone can cause authentication failures that manifest as Orchestrator database connectivity errors.
If DNS resolution is correct, double-check the exact hostname string that's configured inside Orchestrator. Open the Orchestrator Runbook Designer, navigate to Options > Runbook Server, and compare the SQL Server name field character-for-character with what Resolve-DnsName returned. A mismatch here, even a trailing dot, a different case in the FQDN, or a short name vs. fully qualified name, is enough to cause connection failures under certain network configurations.
What success looks like: Resolve-DnsName returns the correct IP, the reverse lookup returns the correct hostname, and the name in Orchestrator's settings matches exactly what you tested.
When System Center Orchestrator is configured during setup, the installer asks for a SQL Server instance name. If anyone has ever changed the SQL Server instance name, migrated the database to a different server, or if the original setup was done with a typo, the Orchestrator Runbook Service will fail to connect every single time, and the error it gives you won't say "wrong instance name." It'll just say 0x80004005.
Go to the Orchestrator server where the Orchestrator Management Server role is installed. Open Orchestrator Deployment Manager. Under the management server node, you'll see the SQL Server and database name that Orchestrator is targeting. Confirm this matches your actual SQL Server instance and that the database named there actually exists.
To confirm the database exists on the SQL side, open SSMS and connect to the instance. In the Object Explorer, expand Databases and look for the Orchestrator database (typically named Orchestrator). If it's not there, it may have been accidentally dropped, the backup may need to be restored, or the instance name in Orchestrator's config is simply pointing at the wrong SQL Server.
If the database is present, also check that it's not in a suspect, restoring, or offline state. In SSMS, right-click the database and select Properties. The State field on the General page must show Normal. Any other state means the database needs attention before Orchestrator can connect to it.
What success looks like: Deployment Manager shows the correct SQL instance and database name, SSMS confirms the database exists in Normal state, and no mismatch exists between the two.
This step trips up even experienced admins. SQL Server doesn't always listen on TCP/IP by default, and even when it does, the port may not be what Orchestrator expects. Meanwhile Orchestrator defaults to TCP/IP for its database connections, so if Named Pipes is the only enabled protocol, or TCP/IP is enabled but on a non-standard port that Orchestrator doesn't know about, you'll get that 0x80004005 error every time.
On the SQL Server host, open SQL Server Configuration Manager. Expand SQL Server Network Configuration and click on Protocols for [your instance name]. Verify that TCP/IP is Enabled. If it shows Disabled, right-click it, select Enable, and restart the SQL Server service for the change to take effect.
While you're here, also check the priority order. Right-click Client Protocols under SQL Native Client Configuration and confirm that TCP/IP is at the top of the order, or at least above Named Pipes. If Named Pipes sits higher and that protocol is having any connectivity issues, SQL Server connections will attempt Named Pipes first, fail or time out, and may not fall through to TCP/IP cleanly.
To check the actual TCP port SQL Server is listening on, double-click TCP/IP under the instance's protocols. Go to the IP Addresses tab and scroll to IPAll at the bottom. The TCP Port field shows what port the instance is listening on. If it's blank, it's using a dynamic port, check TCP Dynamic Ports instead. Note this port number.
If Orchestrator is configured with a static port in its connection string, verify that port matches. You can check the Orchestrator connection string in the registry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center 2012\Orchestrator\RunbookService\What success looks like: TCP/IP shows as Enabled for the SQL instance, the port numbers match between SQL Server and Orchestrator's configuration, and TCP/IP is at a higher priority than Named Pipes.
The Orchestrator Runbook Service runs under a service account. That account needs specific permissions on the Orchestrator database, not just "some" permissions, but the right ones. If the account's password was rotated and the service wasn't updated, or if someone tightened database permissions during a security review without checking Orchestrator's requirements, you'll see the service start and stop with exactly the symptoms described here.
First, find out what account the Runbook Service is running under. Open Services (services.msc), find Orchestrator Runbook Service, right-click, select Properties, and go to the Log On tab. Note the account name.
Open SSMS and connect to the Orchestrator SQL instance. Navigate to Security > Logins and find the service account. If it's not listed at all, that's your problem, right-click Logins, select New Login, add the account, and under User Mapping, map it to the Orchestrator database with at minimum db_owner membership (Orchestrator requires this level of access for its schema operations).
If the account is already listed, right-click it, go to Properties > User Mapping, and verify that it has the appropriate role on the Orchestrator database. Also check whether the login is disabled, under Status, confirm Login: Enabled.
Finally, verify the password hasn't expired or been changed. In the Log On tab of the service's Properties in services.msc, re-enter the password even if you think it's correct, click Apply, and then try starting the service. Windows caches service account credentials and an expired password will cause exactly this startup failure.
What success looks like: The service account has an active, enabled login in SQL Server with db_owner access to the Orchestrator database, and the password configured in the service matches the current Active Directory password for that account.
Advanced Troubleshooting
If you've worked through all five steps and System Center Orchestrator is still not working, you're dealing with one of the less common scenarios. Here's where to go next.
The disallow results from triggers SQL Server Setting
This one catches people completely off guard. There's a server-level SQL Server configuration option called disallow results from triggers. When it's set to 1, SQL Server blocks stored procedures from returning result sets when they're called from within a trigger context. Orchestrator's internal runtime calls a stored procedure called CompleteJob via sp_UnpublishPolicyRequest, and this interaction can fail silently if this option is enabled.
This is particularly relevant in environments where SQL Server has been hardened according to a security baseline, a CIS benchmark, or a STIG, many of those baselines recommend setting disallow results from triggers to 1. Your security team may have flipped this without knowing it would break Orchestrator.
To check the current setting, open SSMS and run this against the SQL instance hosting Orchestrator:
EXEC sp_configure 'disallow results from triggers'Look at the config_value column in the results. If it shows 1, this option is enabled and needs to be changed. Run the following to correct it:
EXEC sp_configure 'disallow results from triggers', 0
RECONFIGUREAfter running this, restart the Orchestrator Runbook Service and test. Note: Microsoft has flagged that this configuration option will be removed in a future version of SQL Server, and the long-term recommendation for that version is to keep it at 1. But for current System Center Orchestrator versions, it must be 0 for the product to function correctly. Work with your security team to document this as an accepted exception if you operate under a hardening standard.
Reading the Runbook Service Exception Logs
The exception logs at C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookService.exe\Logs contain .NET exception stack traces that are far more informative than what Windows Event Log surfaces. Open the most recent log file (sorted by date modified) and look for lines containing Exception, Error, or SqlException. A SqlException with error number 4060 means the database wasn't found. Error number 18456 means a login failure for the service account. Error number 10060 means TCP connection refused, pointing back to Step 4.
Event Viewer Deep Dive
Beyond the System log, check the Application log on the runbook server. Orchestrator will sometimes log additional detail there that doesn't appear in the System log. Filter by source OrchestratorRunbookService or .NET Runtime. A critical application event ID 1000 with a .NET exception fingerprint confirms a code-level crash, whereas Event ID 7023 in the System log confirms the service framework detected the exit. Both together give you a complete picture.
Network-Level and Domain-Joined Scenarios
In environments where the Orchestrator runbook server and SQL Server are in different domains or trust zones, Kerberos authentication can fail in ways that TCP connectivity tests don't reveal. Check whether SQL Server is configured for Kerberos or NTLM by running the following query in SSMS while connected from the runbook server:
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPIDIf this returns NTLM instead of KERBEROS, and your environment requires Kerberos, contact your AD team to verify the SQL Server SPN (Service Principal Name) is correctly registered. A missing or duplicate SPN will cause Orchestrator authentication to fall back to NTLM and may fail entirely depending on your security policies.
disallow results from triggers setting is 0, and the Orchestrator Runbook Service still crashes, it's time to escalate. Gather the full contents of the RunbookService exception log folder, the relevant Event Viewer entries (System and Application logs filtered to the time of the crash), and the output of sc query orunbook immediately after a failed start. Submit these to Microsoft Support when opening your case, it will dramatically speed up the diagnostic process and get you to a solution faster.
Prevention & Best Practices
System Center Orchestrator not working tends to happen at the worst possible moments, during an active incident, before a scheduled change window, or right after a "routine" infrastructure change that nobody mentioned to the Orchestrator admin. Most of these failures are preventable with a few proactive habits.
The number one thing you can do is monitor the SQL Server service with the same priority as Orchestrator itself. Orchestrator is completely dependent on its database backend, but many organizations don't have alerting configured on the SQL instance, only on Orchestrator. Add a service health monitor for the SQL Server service to whatever monitoring platform you use (SCOM, Nagios, Datadog, whatever). When SQL goes down, you want to know before your Orchestrator runbooks fail silently.
Second, document your SQL instance configuration, the server name, instance name, port, service account, and database name, in your internal wiki right now, before you forget. Every time someone needs to troubleshoot Orchestrator connectivity from scratch, they waste 30 minutes finding this information. Having it documented means the first step of the investigation takes 30 seconds instead.
Third, implement a service account password rotation process that includes service dependencies. This is one of the most common causes of Orchestrator failures in well-managed environments, a scheduled password rotation runs, the service account password changes, and nobody updated the Orchestrator Runbook Service's stored credentials. Build a checklist that includes updating the service in services.msc every time the account password changes.
Fourth, test SQL connectivity from the runbook server after any infrastructure change, server renames, IP changes, DNS updates, firewall rule modifications, SQL Server upgrades, or even Windows Updates on the SQL Server host. A quick Test-NetConnection takes ten seconds and can catch a broken configuration before it impacts production automation.
- Set up an alert on Windows Event ID 7023 from source Service Control Manager on all Orchestrator runbook servers, this fires every time a service crashes and is the earliest automated signal you'll get
- Schedule a monthly test of the Orchestrator Runbook Service startup on non-production runbook servers, catch configuration drift before it hits production
- Keep a copy of the Orchestrator exception log directory path (
C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookService.exe\Logs) bookmarked in your runbook for incident response, log files there expire and rotate, so check them fast after a crash - After any SQL Server maintenance, explicitly restart the Orchestrator Runbook Service and confirm it stays running for at least 90 seconds before closing your change record, 30–60 seconds is how long it takes to fail, so 90 seconds gives you a clean confirmation window
Frequently Asked Questions
Why does the Orchestrator Runbook Service start but then stop after 30 seconds?
This is almost always a database connectivity problem. The Orchestrator Runbook Service starts successfully, attempts to establish a connection to the Orchestrator SQL Server database, and then terminates when that connection fails or times out. The service is designed to exit cleanly rather than run in a degraded state without a database connection. Check that SQL Server is running, that the hostname resolves correctly, and that port 1433 (or your custom SQL port) is reachable from the runbook server using Test-NetConnection. The exit code you'll see in sc query orunbook will be -2147467259 (0x80004005), which confirms this connectivity failure pattern.
What does WIN32_EXIT_CODE -2147467259 mean for the orunbook service?
The hex equivalent is 0x80004005, which is a generic COM/HRESULT error code meaning "unspecified error." In the context of the Orchestrator Runbook Service (orunbook), this specific exit code is the fingerprint of a database connection failure. It doesn't tell you which connectivity problem you have, but it definitively tells you the service couldn't reach or authenticate against its SQL database backend. Use the exception logs at C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookService.exe\Logs to find the specific SQL error number that will narrow down the exact cause, login failure, database not found, TCP refused, and so on.
How do I find the Orchestrator Runbook Service crash logs?
The exception logs live at C:\ProgramData\Microsoft System Center 2012\Orchestrator\RunbookService.exe\Logs on the Orchestrator runbook server, not the management server, the specific runbook server that's failing. Open File Explorer, navigate to that path (you may need to enable hidden files/folders since ProgramData is hidden by default), and sort the files by Date Modified. Open the most recent file and search for keywords like Exception, SqlException, or Error. The .NET stack trace you find there will give you a much more specific error than anything Windows Event Viewer surfaces.
Can the "disallow results from triggers" SQL Server setting break Orchestrator?
Yes, and this one is surprisingly easy to miss. When disallow results from triggers is set to 1 on the SQL Server instance hosting your Orchestrator database, it can block internal stored procedure calls that Orchestrator's runtime depends on, specifically around job completion processing in sp_UnpublishPolicyRequest. You can check this with EXEC sp_configure 'disallow results from triggers' in SSMS. If the config_value is 1, run EXEC sp_configure 'disallow results from triggers', 0 followed by RECONFIGURE. This is a common issue in hardened SQL Server environments where security baselines have been applied without accounting for Orchestrator's requirements.
What permissions does the Orchestrator Runbook Service account need on SQL Server?
The service account running the Orchestrator Runbook Service needs to be a valid SQL Server login and must have db_owner role membership on the Orchestrator database. This level of access is required because Orchestrator performs schema operations, stored procedure executions, and various write operations against its database that require more than just read/write permissions. If your security team is uncomfortable with db_owner, engage Microsoft support for guidance on a minimal permission set, but out of the box, db_owner is what Orchestrator requires. Also make sure the login is enabled (not disabled) under Security > Logins > [account name] > Properties > Status.
System Center Orchestrator runbooks stopped running but the service is up, what's wrong?
If the Orchestrator Runbook Service is showing as Running but runbooks aren't executing, this is a different problem from the service crash scenario. Check a few things: first, verify the runbooks are actually set to Check Out is not active on them in Runbook Designer, a checked-out runbook won't execute. Second, confirm that your runbook servers are properly registered and showing as active in Runbook Designer under Runbook Servers. Third, check whether any runbook jobs are queued but stuck by querying the POLICY_REQUEST_ACTION_SERVERS table in the Orchestrator database, deadlocks or blocking queries in that table can freeze the job dispatch mechanism. Finally, review the Application event log for any errors from the Orchestrator source that indicate a workflow engine issue separate from the service startup failure.