The situation
A SCOM R2 environment based on W2K08 R2 SP1 servers. One RMS (duh!), two dedicated SQL Engine instances (one for the OpsMgr database and the other for the DW database) and a dedicated SQL Server Reporting Services (SSRS) instance. The SSRS databases are hosted by the same SQL server hosting the DW database. All SQL servers are SQL Server 2008 R2 CU#6 based. And all SQL instances are named instances.
Since the SCOM R2 installation media doesn’t recognize SQL Server 2008 R2 instances correctly, the SCOM R2 databases must be created by running the tool DBCreateWizard.exe, as I blogged before.
The creation of both SCOM R2 databases went fine, as well as the installation of the RMS. The installation and configuration (manually) of the SSRS instance went OK as well. When tested the Report Server responded as expected: 
What happened
So now it was time to install SCOM R2 Reporting. This is performed on the SQL server hosting SSRS. The installer was started locally with elevated permissions since it’s a W2K08 R2 server. The account being used is Domain Admin and has Sys Admin permissions on SQL servers which are being used by SCOM.
Setup went fine for a while. After all required information (RMS, DW, SSRS instance and accounts) has been entered setup started running but stopped dead after it made a connection with the Management Group. Than the not so much respected (duh!) roll back kicked in…
Time for a check, double check and triple check
Of course, when the installation of SCOM R2 Reporting fails in a situation where the DW is split from SSRS, this procedure found on the blog of Graham Davies has to be followed. Otherwise the installation keeps on failing…
The account which was used had all the required permissions: domain admin and also admin on all SQL servers (not a GPO in place blocking it). Also the same account has sys admin permissions on all SCOM R2 related SQL servers. So no issues there.
Checked the log file (found in the folder %temp% with the name MOMReporting0.log. But I couldn’t find anything wrong there. Perhaps I was missing something. So I send it to my fellow MVPs and Kevin. Soon they send me an answer, found in the log file: 
First the permissions for the SCOM R2 service accounts were suspected. Some of those accounts might lack log on locally permissions on the SQL servers and RMS. Investigation showed this wasn’t the case. All SCOM R2 service accounts are local admin on all related SCOM R2 servers.
So it was time for another approach.
How it got fixed
Normally I run the SCOM R2 installations with a domain admin account (also to get the SPNs correctly registered) which has also SCOM Admin and SQL Admin permissions. But now this approach wasn’t successful.
The SDK account was granted temporarily Domain Admin permissions and with this account I started the SCOM R2 Reporting installation on the SSRS server. This way I hoped to get more information about what went wrong and why.
Soon the first error popped up, right after the Connect to the Root Manager Server screen: Couldn’t verify if current user is in sysadmin role.
It turned out the SDK account hadn’t sufficient permissions on the SQL Server instance hosting the OpsMgr database. So that was fixed. The same permissions were set for the Data Reader and Data Writer account as well.
Now setup continued to the next screen Connect to the Operations Manager Data Warehouse. But right after that screen a new error was shown: The user running setup is not in sysadmin role in the reporting database.
This one took a little bit longer to tackle. The SDK account (the Data Reader and Data Writer account as well) did have sysadmin permissions on that database (ReportServer): 
Also checked the Data Warehouse database (hosted on the same server) and the same permissions were in place there as well. A last check was performed on Security > Server Roles > sysadmin. 
In this Server Role the SDK account wasn’t present nor the two Data Warehouse accounts. So these were added here as well and the changes saved.
Back to SCOM R2 Reporting installation
Now it was time to rerun the SCOM R2 Reporting installation. And now all went just fine. All required information was entered and setup started running. Took about 20 minutes to finish but finally this screen was showed: 
Nice! Checked the OpsMgr log file on the RMS and everything was OK (no errors nor warnings). Within 20 minutes the first Reports were uploaded to the SSRS instance and shown in the SCOM R2 Console. Phew!
Conclusion
Whenever SCOM R2 Reporting installation goes wrong, run the setup with the SDK account and go on from there. Solve all issues you encounter and treat the Data Warehouse Read and Write account the same when setting permissions for the SDK account. Soon you’ll be in the clear. Don’t forget the earlier mentioned blog posting of Graham Davies either…
No comments:
Post a Comment