SQL Installation and Reporting Issues with Data Protection Manager

SQL Installation and Reporting Issues with Data Protection Manager

  • Comments 6
  • Likes

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I'm getting error 812 on installing DPM with a remote x64 SQL install where the SQL server is dedicated to SQL and reporting services. Reporting services is working and deliving reports for Operations Manager (I remember there was something about the permissions changing with SCOM). Is this leading to my install issue? Is there an easy fix for this issue?

  • Oddly Enough, I am stuck on the installation with the same exact error: Error 812. I've tried "net stop http" even though I did not see :443 listed as in use (nor do i detect it with a scan on the host). The SQL server reporting services URL is available on port 80, and I see the newly created "DPMReports" container listed there as well.

    Is it possible that some condition triggers the install to register the reporting web service on port 80; and that DPM expects it on port 443? In any case, if all of this occurs during the install, I don't see how I can intervene to prevent it from happening.

    I was suprised to see no "application server" or other "role" prereqs or standard .net reconfigurations that i'm accustomed to when installing for Microsoft Enterprise Applications. However I don't see a hefty list of prereqs in the documentation. -just three required patches.

    Any additional help here would be greatly appreciated.

  • Hey folks, I also encountered this Error while installing DPM2010. In my case TeamViewer Host was using port 80 & 443.

    Entering TeamViewer Host Options -> Advanced -> "Don not use port 80 & 443" solved the problem.

    Thanks for giving the right hint! ;-)

  • Thanks, pointed me in the right direction!

    For me, it turns out, reporting services was running, but a Database hadn't been created.

    Once a "native" database was provisioned (through the reporting services interface - SQL server), the DPM installation completed successfully.

    Kurt.

  • Great post, definitely informative, for me it turned out to be two things

    1. After installing Reporting Services, I needed to create the reporting services database (obvious step)

    2. Within Reporting Services, under the web services URL tab, I had to select "ConfigMgr SQL Server Identification Certificate" within the SSL Certificate field. This automatically set the port to 443

    Doing step two, also created the Reports Virtual Directory.

    My config for DPM was, SQL Server 2012 with DPM 2012 SP1.

    I was then able to successfully install DPM 2012 SP1

    Hope this helps.

  • same here as AndreyP101 stated.

    Decided to configure SQL Reporting later, after installing SQL 2012, so I had to do this before installing DPM Server.