Sometimes when you create a Runbook in Orchestrator and then synchronise the Orchestrator connector the Runbook doesn’t appear in the Runbooks view in the Service Manager Console. This is because the Orchestrator authorisation cache hasn’t updated yet to allow the connector access to the folder / Runbook.
Run the following SQL script against the Orchestrator database to resolve the issue:
TRUNCATE TABLE [Microsoft.SystemCenter.Orchestrator.Internal].AuthorizationCache
N.B. Credit to Stefan Johner who first blogged about it here!
So you’ve setup your Windows Server Failover Cluster and deployed SQL AlwaysOn Availability Group to it. You’ve tested the port, and failover using a test database to ensure it’s accessible through the firewall or network security group.
You come to install the Service Manager database but when you input the name of your AAG listener, the instance is automatically detected but you receive the entitled message “A required SQL Server service is not running on MSSQLServer”. Similarly if you attempt the deployment from the command line you’ll get an “Access was denied” error in the log.
There are two solutions to this issue. One, very cumbersome method is to deploy to a single SQL server, then go through the process of updating the registry and SQL table properties (as you would if you were migrating SQL servers). This will resolve the problem, but it can be very painful. It also doesn’t solve your problem if you are installing a secondary Management Server, or recovering a Management Server.
An alternate solution is to add a simple entry to the registry of all SQL servers participating in your SQL AAG. This will allow named pipes to be opened in a fashion that the Service Manager installer understands.
Registry setting as follows:
Once this value is in place the installer will instantly see the SQL AAG Listener and you can continue deploying Service Manager!
N.B. Edit the registry at your own risk!