SCOM: Troubleshoot SQL version is unsupported while upgrading
Upgrading SCOM in a high security environment can be challenging from time to time. You actually need a lot of rights (some of them just temporarily of course) to get things installed.
Besides the user rights needed by the user which you launch the install with ( http://technet.microsoft.com/en-us/library/hh212808.aspx ) you’ll need access to SQL, the machines where you want to perform the upgrade,…
Getting all this access can be challenging and adds an extra layer of complexity to the upgrade.
However I came across a common error message during installation which had a rather uncommon cause…
Problem:
"The installed version of SQL Server is not supported. Verify that the computer and installed version of SQL Server meet the minimum requirements for installation. Please see the Supported Configurations document for further information"
(Of course I did not take a screenshot in the heat of the moment but this is the actual message on the prereq checker and a good reference for search engines)
Solution:
This can have many causes but the most common is in fact you do not have a required version installed. Check and double check whether your SQL is up to spec. To find out which versions are supported check here: http://technet.microsoft.com/en-us/library/dn249696.aspx
If you are 100% sure that your version is correct chances are that SCOM prereq can’t check the version and just throws this message. Make sure you have proper firewall ports open if there’s a firewall in between the SQL and management server. Check this article for pointers: http://geekswithblogs.net/mattjgilbert/archive/2013/02/15/scom-2012—the-installed-version-of-sql-server-is.aspx
If this is ok check the rights on the SQL server. You need to have enough rights to check the SQL version and be able to create a new dbase. A tip here is to use the SDK account this probably has all the sufficient rights to do so.
Actually I’m running an upgrade from SP1 to R2 so the version should be ok no?
If all this fails (or even sooner) it’s time to look at the log files. As soon as SCOM starts it’s install it creates log files to document it’s progress.
This post easily documents where to find these log files: http://www.systemcentercentral.com/opsmgr-2012-my-installation-failed-what-log-files-do-i-read-and-where-can-i-find-them/
For reference when the link above should become broken:
“Logs are located in the %LocalAppData%\SCOM\Logs directory for the account under which installation was run. On a default installation on Windows 2008 R2, that would be c:\users\<UserName>\Appdata\Local\SCOM\Logs where <UserName> is the name of the account you used to run the installation.”
So In my particular case I opened the log file and found the issue below:
The lines in the above excerpt “Exception Error code: 0x80070005, Exception.Message: Access to the path is denied.” and “Error: Could not create the directories for the specified DB Path” caught my attention.
After checking I found out I did not have access to the path where the dbase files are stored neither with the SDK nor with my account. After I got access to the path the installation of the R2 upgrade went without an issue.
As this is not documented (by my knowledge) or not a common issue I’ve encountered during my many SCOM installs / upgrades I documented it here on my blog hoping it will save you some troubleshooting time.