Locating Orchestrator Runbooks using bad credentials

A problem recently encountered was causing major headaches. There was a runbook somewhere in the system that had an action running with the security credentials of a user that had left sometime ago. Their account had recently been disabled and the Orchestrator was logging thousands of errors and causing the Orchestrator database to grow at a massive rate. OBJECTINSTANCEDATA was growing at thousands of rows a second and hit 50 million rows and 16GB in size after only a few days.

Orchestrator 2012 Web Console shows no details

On a brand new System Center Orchestrator 2012 install the web console was showing the basic site, but would show no details for Runbooks or Runbook Servers.

It would work fine if I connected using the “Orchestrator Admin” account used during install, but other accounts were all having problems. It seemed obvious that permissions were the problem, but where exactly? All those same users could use the Orchestrator Designer console without any problem, so it seemed they had all the permissions needed.

Orchestrator 2012 Web Console permissions do not reset

Have found an issue when using the Orchestrator Web Console where the permissions a user has are still active after they have been removed.

Scenario:

1. Permissions are granted to an AD group to a runbook folder using the Designer console
2. User is added to the AD group
3. User can connect to Designer and also the Web Console to see and manage the runbooks in that folder
4. Remove the user from the group
5. In Designer, the user no longer has access and cannot see the folder or runbooks
6. In the Web Console, the permissions are unchanged and the user can still view and manipulate the runbooks

Suggestions provided through a post to the technet forums suggested that the permissions are cached in the SQL database in the “Microsoft.SystemCenter.Orchestrator.Internal.AutorizationCache” table, however this table was already empty

Restarting the Servers, services, logging the user off and on etc made no difference. The permissions still persisted the following day.

Another user suggested this is a known bug and that they resolved it with a call to Microsoft. I can find no other mention/reference of this bug, so a call to Microsoft it is…

Finding the Opalis database

Picture this scenario:
You’ve just inherited an existing Opalis implementation and the guy that set it up didn’t write any doco (or it’s lost). You want to do something that requires connection to the Opalis database…but you have no idea what server the database is on.

Interestingly enough, while starting my learning of Opalis/Orchestrator I’ve discovered there is no obvious place that you can see what database is being used. I’ve searched the registry, the console, and all the files and the closest is a mention of the SQL server in a log file if an Action server can’t connect.
If you run the Database Configuration tool, you need to enter all details from scratch, it doesn’t tell you the current setting. I would have also thought there would be a setting in the console *somewhere* that would show the server.
So anyway, I’ll see if someone on the MS forums has an answer, and will see if the situation is improved in Orchestrator.