Hi
I'm having issues with successfully changing some VM servers which are in a clustered Hyper V 2012 R2 environment from a DPM 2012 R2 server located in one site to the other.
The VMs themselves were recently migrated over from one site to the other in Hyper-V and are working fine. This required the Protection Group in DPM which was backing up successfully from the original site to be stopped (ORIGINALSITEDPM). I kept the restore points. Then I set it up again on the DPM server on the other site for DR.
Two of the VM servers are now backing up on DPM just fine, but 7 out of the 9 have not. I get the following errors on the failing servers Unable to configure protection :-
Details:-
Affected area: \Online\SERVERNAMEOccurred since: 09/09/2015 10:59:43
Description: DPM could not start a recovery, consistency check, or initial replica creation job for Microsoft Hyper-V \Online\SERVERNAME on ORIGINALSITEDPM for following reason:
(ID 3170)
The operation failed for Microsoft Hyper-V \Online\SERVERNAME on ORIGINALSITEDPM because the data source is not available. (ID 30169 Details: VssError:The specified object was not found.
(0x80042308))
More information
Recommended action: To troubleshoot this issue, verify the following:
1) The data source is online.
2) The data source is not in a restoring state.
3) The application VSS writer is running.
4) The data source is accessible.
5) The data source is not missing.
6) If the data source is a member of a SharePoint farm, verify it still exists in the SharePoint farm configuration.
For more information on this error, go to http://go.microsoft.com/fwlink/?LinkId=132612.
Run configure protection job again...
Resolution: To dismiss the alert, click below
Inactivate
The bit that puzzles me is why it is using the ORIGINALSITEDPM reference at all, since these devices are located on the production cluster and are now in the Inactive Protection on the ORIGINALSITEDPM server, just like the other ones which did work fine. So far I have tried rebooting both DPM servers in both sites. The only thing I have not tried is rebooting the actual VMs as they are 24/7 production boxes and I don't wish to do that unless I'm fairly sure it will fix the issue.
Thanks in advance
Other recent topics
