While this has been mentioned multiple times on other blogs as a problem that has occurred after an upgrade from SP1 to R2, I wanted to throw this post up to let people know that I personally experienced the same thing during a fresh install of R2. In addition, I also was able to successfully use 3 completely separate service accounts on a single machine (for demo purposes). This is how I got it working:
The Setup
So we have a point of reference, here’s a quick overview of the setup, which was for a simple proof-of-concept lab demo I was working on:
- SCOrch Server Operating System: Windows Server 2012 R2
- Domain Controller/Exchange OS: Windows Server 2008 R2 SP1
- SQL Server Version: SQL 2012 Standard w/SP1
- Service Accounts:
(3) – SCOrchMgmtSvc, SCOrchRBSvc, SCOrchWebSvc - Install Account Permissions:
Domain Admin Rights/Local Admin/Sql Admin
The Install Order
I wanted to test setup that included service accounts for each component, so although I decided to do an all-in-one (including SQL) install into one demo box, I installed the components in a particular order individually, rather than selecting all items during the first installation.. Remember, if you install all of the components at once then the Management Service account will be used as the Runbook and Web Service Accounts, which may not jive with your organizations security requirements.
- Installation Step 1: Management Server – Use CONTOSO\SCOrchMgmtSvc
- Installation Step 2: Console/Web Service – Use CONTOSO\SCOrchWebSvc
- Installation Step 3: Runbook Server – Use CONTOSO\SCOrchRBSvc
- Installation Step 4: Install Runbook Designer
After the installation, all logs indicated a successful install, and the console launched from the runbook designer….
But then I recieved a couple of error popups:
Also, when trying to connect to the Web Service I saw this nasty little gem:
Post-Install Fixes I had to implement
After scouring the interwebs I decided to try the following tasks, as multiple sites indicated these steps after one fashion or another:
Step 1 – IIS Related Fixes
Source: TechNet Blogs – Travis Write – System Center Orchestrator Engineering Blog
The link above contains a few steps that I followed (despite the fact I wasn’t doing NLB as the blog post talks about) and summarized below:
- A) Change the Web Application Pool Accounts for each IIS SCOrch Site:
- B) Set the SPNs
- C) Configure Web Service App Pool Credentials
- D) Configure Orchestration Console Kernel Mode Settings
After I reset IIS – the problem still existed, so I moved on to the next set of instructions I found.
Step 2 – Database Permissions
Source: System Center Central – Request Error on Fresh SCOrch 2012R2 Install
Even though the suggestion from the source says that a workaround is to install all of the roles at the same time, I did not want to accept this.
Once I granted all three service accounts the db_owner role (more in a second on that), I restarted IIS, and lo and behold, both the console and the web service worked without issue:
Step 3 – “Tighten Up” Database Permissions
After I got them working, I wasn’t sure this was going to work, strictly speaking, as I wasn’t sure the runbook service actually needed the permissions. So naturally, being lazy and just playing around anyway, I decided to remove the permissions from the runbook service, reset IIS, and check again…
Web Service still comes up, check. And from other articles I read I knew I should leave the Mgmt Service as is. So now my lab is up and ready to rock!
As shown in this post, this information has been out there, but not mentioned usually with a “Fresh” install. Usually the instance occurred after the upgrade from SP1 to R2. So I just wanted to gather this information in one place and let people know that it definitely effects the clean install as well, when using multiple service accounts. And to mention that you don’t have to use a single service account for the demo labs or single server installations if you do not want to!
‘Till next time!
willcode4foodblog 