What Version of SQL Server AM I Running?

I’m in the midst of a project using System Center Configuration Manager’s (SCCM) Desired Configuration Management (DCM) component. It has taken us some time to come up to speed on this, so our initial configuration checks were strictly against the Windows OS. Last week, we started working on the first SQL check—checking for service pack level. Initially, and for simplicity reasons, I wanted to avoid logging into to the database. So we put together the following PowerShell script.

It looked simple enough—we wrapped some version logic around it, and then tried to run it on a mass scale. It returned some of the following version numbers:

A few of those are actual legitimate build numbers, but most are not in the list at SQL Server Builds. This pattern is consistent in both the registry and the advanced properties of the SQL Server service in configuration manager. A connect item has been filed specifically about SP1 for 2008R2 doing this, but as the above data shows, it appears to be occur across multiple versions.

Additionally, I have a Premier support ticket open with Microsoft, but we haven’t had a solid response yet.

On Friday night after a glass of wine or two, I decided to see what would happen if I hacked the registry back to the “correct” version. I built a new VM using SQL 2008 R2 SP1—version is 10.50.2500, but shows as 10.51.2500. I did a global find and replace in the registry for 10.51 to 10.50, as well as replacing MinorVersion from 51 to 50. It worked in so far as PowerShell and SQL Config Mgr reported the proper version; however when I attempted to apply a CU to the instance, the installer broke. Don’t try this at home!

We can always log into the database and run select serverproperty(‘productversion’) and get the correct version—which SQL Server clearly isn’t getting from the operating system. This is a relatively minor issue, but I’m surprised it hasn’t risen to the surface more.