Microsoft supports Windows Server 2008 R2 (with or without Service Pack 1) and SQL 2008 R2 for SCOM 2007 R2 for some time now. This can be found on the ?Supported Confiugrations? page.
However, there is a special installation procedure required to do a fresh installation of SCOM 2007 R2 directly on a SQL 2008 R2 database server. This procedure is described in the following KB-Article. You have to create the SCOM databases manually using the DBCreate tool on the SCOM 2008 R2 DVD instead of using the regular setup procedure.
In this case, i installed SCOM and SQL on the same server to prevent extra monitoring / SCOM related load on the production SQL infrastructure.
First i got the following error message during the setup of the SCOM base (the management server). This is not the primary issue of the article, but i receive quite some questions on this one. That?s why i cover it briefly.
This issue can be resolved easily using this article.
However, when i worked myself through this procedure i literally got stuck when running the SCOM reporting setup. The CPU jumped to 100% and the SQL database was unreachable, the SQL management studio responded with connection errors. This happened after clicking next in the step shown below.
The funny thing was, that if we killed the MSIEXEC process that was attached to the user account that we used to run the installation, the setup proceeded to the next step.
However, the installation ends in a SQL error. Unfortunately there was hardly any logging on SQL, SCOM or the regular event viewer, so troubleshooting was hard.
After checking SQL reporting itself, consulting some colleagues, we decided to call Microsoft support. I did many implementations of SCOM, but never ran into this behavior.
After some mail traffic with Microsoft support, they decided to set up a remote desktop session, so they could see what happened on the server. This procedure was very plain and simple using a remote assist toolkit.
After installing and running several logging tools (the remote support session took more than 2 hours) we finally found the issue?
In the KB-article that you have to run through to install SCOM 2007 R2 on SQL 2008 R2 is written that you have to rename the following local SQL group before installing the SCOM Reporting part:
The article describes just to remote the _50 from the group name. In the first part the group name above is mentioned, in a later section they use a name that is just a little different (check the S in $MSSRS10 section). The system however generates $MSSRS10 by default, so that seems to be the right one.
NOT!
For some reason the setup of reporting refers to $MSRS10 instead of $MSSRS10 as part of the group name?
Bug? Well, at least an issue that is hard to find, but very easy to solve 
If you face this, just rename the group to the value below and your issue is solved?
Renaming the group back to the original name (as described in the KB article) was not required according to Microsoft support, but we will see if there are any issues. So far SCOM is running fine now.
To be clear:
The wrong group name (for the SCOM Reporting setup at least)
SQLServerReportServerUser$<hostname>$MSSRS10.<SQLInstanceName>
And the name you have to use to run the SCOM 2007 R2 reporting setup properly?
SQLServerReportServerUser$<hostname>$MSRS10.<SQLInstanceName>
I would like to thank the Microsoft support team for their excellent support and fast response!
1 reactie