SQL Installation and Reporting Issues with Data Protection Manager

I have seen enough calls come in for DPM that are related to the SQL Reporting services that I figured we should put out some general troubleshooting guides for these. As with just about everything else in our industry, these are just guides and there are far too many possible scenarios out there for us to be able to address everything that could possibly happen.


Most notably, the issues we have seen can be broken down into two categories.
1) DPM installation issues with SQL Reporting.
2) Reporting issues within DPM.

DPM installation issues with SQL Reporting
Most often if you run into an error with SQL Reporting while trying to install DPM, you would get a message stating:

Error 812

Verify that SQL Server Reporting Services is installed properly and that it is running.

There are several issues that may arise here, but the bottom line is the failure in this scenario is not the DPM installation but a problem with the installation of SQL (more specifically installation/configuration of the Reporting Services).

Most often this situation is encountered when we have a problem with port something using port 443. This is what IIS uses for SSL communications, so the first place to look is in the IIS admin pages for any web sites you have on this box. Check to see if 443 is listed for SSL. Of course it is not always that easy though. There are often other applications that for some reason have been set up to use that port as well. A really good way to determine if anything is listening on that port is to run the following at a command prompt:

netstat –anob

If you see something like this, then something is using 443:

TCP 0.0.0.0:443 0.0.0.0 Listening 4

If it does not list a specific application/process, then from the command prompt you can run:

net stop http

This will prompt you for other services that depend on HTTP. I have seen both RRAS and IAS listed here and they ended up being what caused the installation issues. Based on that, I feel that we really have to emphasize the importance of DPM being dedicated. DPM is designed to run on a dedicated, single-purpose server that cannot be either a domain controller or an application server. The DPM server must not serve as a management server for Microsoft Operations Manager (MOM) 2005 or Microsoft System Center Operations Manager 2007; you can, however, monitor the DPM server and the computers that it protects in MOM or Operations Manager (from DPM TechCenter).

If those do not resolve the issue there is one more thing we have seen (although considerably less often). We have seen cases where permissions on the %Windir%temp folder were not correct. Make sure that IIS_WPG group has Read/Write/Execute access to this directory.

In all of these situations, uninstall DPM with Add/Remove programs and launch the installation again after making the changes.

Reporting issues within DPM

Outside of the DPM installation process, we have seen issues where DPM installation was up and running fine, but administrators could not use the reporting tab within DPM.

As with everything else, there are many possible reasons for this, but here are the ones I have seen most prevalently.

If clicking on the Reporting tab in DPM and get the following error, “DPM could not connect to SQL Server Reporting Services server because of IIS connectivity issues.” we need to again look into IIS. This is usually accompanied by error 3036. You can often get more information by trying to access this outside of DPM. Through a web browser, navigate to http://localhost/reportserver$MS$DPM2007$

If this gives you CGI/Script errors, then you can follow some simple steps. In IIS 7, this article walks through opening up the correct rights, 942065.

Finally we have seen instances of updated SQL packages break the reporting services. These are usually manifested with a failure of the reporting services to start or connect to the report server database. The system event log may have Event ID: 107 from Report Server Windows Service (MS$DPM2007$). Removing the most recent SQL GDR in add/remove programs usually resolves these.

 

 

Authors:
Chris Butcher &
Keith Hill

Microsoft Corporation