The protected computer prerequisites document lists some of the things you need to have in place before you can protect a SharePoint farm with DPM. I soon learnt that the list was not, lets say, exhaustive – and I learnt it the hard way…
So here I present some things that I learnt along the way:
- The SQL instance name on the production SharePoint farm and the recovery SharePoint farm should be EXACTLY the same.
- The Windows, SharePoint and SQL Server patch levels should be same between recovery and production farms. When I say EXACT, I mean EXACT, right down to the last hotfix you applied.
- The latest version for the DPM remote agent should be downloaded and applied to recovery and production servers concerned.
- If you enabled SharePoint Enterprise features in the production farm, make sure it’s enabled on the recovery farm as well
- Use the same system account that you used on the production farm on the recovery farm as well.
- On the recovery server, run DComCnfg and navigate to Component Services > Computer > My Computer >DCOM Config. Check the Properties > Identity of WssCmdletsWrapper. It should be configured to run with the same farm admin account that you used on production.
- On the recovery server, the farm admin account should be a member of the following local groups on the server:
All groups starting with WSS_
- Make sure network connectivity is perfect between DPM, recovery farm and production farm servers. Near perfect wont do.
- Run ConfigureSharepoint.exe on the recovery server and make sure you save the farm admin password there.
- All features, language packs and templates that exist on the production farm should exist on recovery farm as well.
- On recovery farm, all Sharepoint services, Application pool on IIS, SQL VSS service, etc should be using the farm admin account.
It took me two long cases with PSS to get mine working. Good luck!