Data Protection Manager 2010 Won’t Install on SQL Server 2008 R2

Insane. That’s the only word I can think to describe the decision to not offer support for installing DPM 2010 on an instance of SQL Server 2008 R2. The dreaded error:

Setup has detected that SQL Server 2008 Service Pack 1 has not been installed on the <sql instance>  instance. Install SQL Server 2008 Service Pack 1 or higher and try again.

I get that it couldn’t be offered at release, but surely that could be patched in rather quickly! Is it more than just a setup issue, or is DPM doing some rather strange things with SQL Server 2008 that require more specific features? Maybe.

Anyway, I wanted to try and investigate what the DPM installer is doing to find out what version of SQL is running on the instance. At the “SQL Settings” screen after inputting your connection information I put a SQL Profiler trace and found that it ran the following SQL commands:


Fairly innocuous – just checking that the account you have provided in a local admin on the server, and the account is a sysadmin on the SQL box.

SELECT SUBSTRING(physical_name, 1, CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
FROM master.sys.master_files
WHERE database_id = 1 and file_id = 1

This one is interesting – more on this later.

SELECT count(*) from sys.databases where name = 'DPMDB'

This statement was a curious one, so I created a database called DPMDB for fun and it returns an error in the setup “…DPM cannot be installed on an existing database…”. Deleting the database again made this issue disappear.

Back to the SUBSTRING statement. Why would DPM care where the Master database is installed? I had a horrible initial thought that perhaps it is using the physical path to determine the version, but seeing as you can install SQL just wherever you want to, this doesn’t seem feasible so I discounted that theory. And here’s where things really got down into the weeds… I tried a hunch that the installer was looking in the registry on the SQL Server and ran the utility Process Monitor to track down what registry access it was using. There were repeated requests for the following interesting-looking keys:

HKLM\Software\Microsoft\Microsoft SQL Server\<sql instance name>\Setup\ProductCode

HKLM\Software\Microsoft\Microsoft SQL Server\<sql instance name>\Setup\Version

HKLM\Software\Microsoft\Microsoft SQL Server\<sql instance name>\Setup\PatchLevel

It also seemed to be checking for <reporting services instance name> and a bunch of other registry keys. That’s about when I started to lose my urgency on hacking this through. Next steps would be to hack into the installer itself (which I think is built with the Candle/Light toolset) but that’s a blog of another day.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: