DPM and Sharepoint Error 32008 RRS feed

  • Question

  • Hi,


    I’m having an issue with DPM 2010 backing up our sharepoint server. We recently rebuilt the DPM server from scratch after an issue with windows corruption. The server was a clean build with a new installation of DPM, no point did we import the old configuration.

    However I’m now unable to back up the Sharepoint server. When trying to add it to a protection group, I get this error;

    DPM cannot protect this SharePoint farm as it cannot detect the configuration of the dependent SQL databases (ID 32008)

    1)Ensure that the SharePoint VSS writer is reporting content databases on the front-end web server.

    2)Verify that the SQL Server VSS writer is enabled and running in a healthy state on all the back-end SQL servers machines.

    3)Verify if some of the databases that are part of this SharePoint farm are already being protected by DPM. To protect the Sharepoint Farm, remove these databases from protection and delete their existing recovery points.


    To ensure that the sharepoint server talked to DPM, I uninstalled the agent and combed the registry for any links to the old dpm machine and removed them. I then reinstalled the agent from the dpm server and now getting communication OK.

    I’ve ran vssadmin list writers on both SQL and sharepoint front end and all VSS writers are stable with no errors.

    I’ve gotten the sharepoint admin to run ConfigureSharepoint.exe –enableSharepointProtection and ConfigureSharepoint.exe –enableSPSearchProtection. To be on the safe side I registered the VSS writer again on the sharepoint front end with stsadm.exe –o registerwsswriter. I also checked that the Dcom WSSCmdletsWrapper is registered and have gotten the sharepoint guy to confirm that it has the right identity.

    However none of those fixes has gotten the server to work with dpm and I’m now a bit stumped.

    Our DPM version is 3.0.8158

    • Moved by MarcReynolds Thursday, January 12, 2012 1:31 PM (From:Data Protection Manager)
    Thursday, January 12, 2012 12:24 PM

All replies

  • Hi Mark,

    There's a couple of quick pointers here - most of them are terribly obvious, so I'm sure you've covered off on them:

    1. As indicated in the message, you're not also using DPM to back up the Sharepoint databases on the SQL Server itself, are you? (as indicated in point 3 of your errors message). If you are, you'll need to unmark them from the protected SQL Server so that they can be handled by the Sharepoint agent.
    2. Are you able to back up a directory - any directory, from the Sharepoint server? If not, perhaps check your firewall rules. Though if you installed the DPM agent on the server manually, then this won't be an issue (or shouldn't, unless something like group policy is actually blocking the port - port 135 is a common one for people to block).


    Thursday, January 12, 2012 12:59 PM
  • Hi Lain,

    Thanks for your response.

    We're not backing up the sharepoint database.

    I hadn't thought of trying to backup anything other than the sharepoint config so I tried your suggestion and I'm able to backup windows directories, bare metal and system state. However the sharepoint farm is still failing.




    Friday, January 13, 2012 8:47 AM
  • Hi Mark,

    I see that you re-run stsadm.exe –o registerwsswriter. On the SharePoint server, is the SharePoint VSS Writer set to run with the SharePoint Farm Admin user account?

    Are you using SQL alias from your SharePoint to connect to SQL server?


    Thanks, Wilson Souza - MSFT This posting is provided "AS IS" with no warranties, and confers no rights
    Friday, January 13, 2012 8:59 AM
  • Hi Mark,

    Okay, at least that result is positive. Have you taken a quick look at the SQL Server logs to see if any connection attempts are failing?

    Another way to check - and what I prefer to do since logging of logon failures may be turned off at the SQL Server level anyway, is kick off a SQL Server Profiler tracing session, filtering on Audit Logon Failures and the Sharepoint databases, just in case the DPM agent is trying to use the server's account to logon with. If you need step-by-step help setting up a trace, let me know.

    To catch any events, just try and add the SQL Server into the protection group again and see what Profiler has to say (if anything).

    While we're talking about service-related topics, another very quick check is to ensure the Sharepoint 2010 VSS Writer service is started and running under the Sharepoint farm administrator account you specified with -EnableSharepointProtection.

    I know these are all very basic things - I'm not meaning to waste your time. I'm just one of those people to tends to miss something basic then wander off looking for the arcane, so I guess I'm thinking how I'd try and figure it out.


    Friday, January 13, 2012 9:13 AM
  • Actually, one other thing to check while we're talking about VSS writers: make sure the SQL Server VSS Writer service is also running on the SQL Server hosting your Sharepoint databases.


    Friday, January 13, 2012 9:32 AM