none
DPM cannot connect to drive after partition resizing changed the GUID RRS feed

  • Question

  • The C: drive on a server was running low on space and after all other attempts to free up space, I used a 3rd party (EASEUS) partition management software to shrink (and move) the E: drive so that the C: drive could be expanded.  That process went fine, but now DPM 2012 cannot connect to the E: drive since the GUID (the globally unique ID that never changes) has been changed.

    Is there a way to either change the GUID on the E: drive back to what it was, or change the GUID references within DPM 2012 to reference the new GUID.  If not, I'll have to add new protection for the E: drive and also setup the secondary protection (in a DR facility) as well.  Eventually I would want to remove all the old DPM data related to the "old" E: drive since it wastes a lot of disk space in both locations.

    The protected volume \\?\Volume{e6d1f33a-9131-11df-93d2-806e6f6e6963}\ on servername.ad.domain.com could not be accessed. The volume may have been removed or dismounted, or another process may be exclusively using it. (ID 55 Details: The system cannot find the path specified (0x80070003))

    Running mountvol now shows the following volumes on this server.  Note that the last item is the GUID listed above and is now tied to a non-existent partition with drive letter D:, which actually is the DVD drive.  The E: drive now has a different GUID than it did originally.

        \\?\Volume{b1133ee5-9d48-11e1-9a80-806e6f6e6963}\
            C:\

        \\?\Volume{3d88b957-bb1f-11e0-a29a-001ec958c40e}\
            F:\

        \\?\Volume{69372728-9d3f-11e1-a81b-806e6f6e6963}\
            E:\

        \\?\Volume{e6d1f33d-9131-11df-93d2-806e6f6e6963}\
            D:\

     

     

    Sunday, May 20, 2012 4:36 PM

All replies

  • Hi,

    So this must be a custom volume on a basic disk.  Yes, you can "swap" the volumeID in the registry, then reboot.

    Go to HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices key and rename the OLD GUID value to something different.

    IE: rename it from \\?\Volume{e6d1f33a-9131-11df-93d2-806e6f6e6963} to \\?\Volume{e6d1f33a-9131-11df-93d2-806e6f6e69FF}

    Now Rename the NEW GUID \\?\Volume{69372728-9d3f-11e1-a81b-806e6f6e6963} to be the OLD GUID \\?\Volume{e6d1f33a-9131-11df-93d2-806e6f6e6963} - then reboot the DPM server.   Afterwards, the original volume guid should show properly in the mountvol output and DPM should then see it properly.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Sunday, May 20, 2012 5:48 PM
    Moderator
  • I did successfully change the GUID back to the original value and rebooted, but DPM is still stuck and only gives me a much less useful message that so far isn't documented.

    DPM states "DPM cannot continue protection for Volume E: on server.ad.domain.com (ID: 30184)".  I've followed the provided link in DPM 2012 and done other searches, but this error ID isn't yet documented.  My guess is there is yet another internal pointer to something on this particular server that may have changed.  One guess is that maybe the "volume id" changed, this is the "xxxx-yyyy" volume ID.  Or maybe it is something else internally that changed due to the disk partitioning software rearranging partitions.

    The other clue that something else changed is that "shadow copies" was disabled (and therefore all prior shadow copies are gone).  I've re-enabled Shadow Copies on both drives (C: and E:) since they were both suddenly disabled.

    The odd/annoying thing is that you walk through the wizard to modify the protection group, it shows all the various E: paths in the list as if they are still valid, but when you browse through the resources, it doesn't show any check marks, AND if I select ANY folders on the E: drive it wants to allocate another huge section of disk space in order to backup the E: drive to a new volume since it no longer has any connection to the current/prior E: drive.

    So, unless there is some other method - SQL script or some other tweak to DPM to get it to actually use the same volume or drive letter instead of wanting to start competely over, i may have to do exactly that - wipe the existing DPM data for the E: drive (since I don't have a spare 1TB of disk space to allocate just since DPM is confused) and manually walk a replica to the DR site since I don't really want to re-replicate 1TB of data :)

    Tuesday, May 22, 2012 8:39 PM
  • It turned out that the GUID that appeared to have been swapped was actually a completely new GUID that was just very similar to old GUID for the E: drive.

    So, after changing the GUID again to \\?\Volume{e6d1f33a-9131-11df-93d2-806e6f6e6963}\ (note the e6d1f33a instead of e6d1f33d), DPM is able to run a consistency check and move forward.

    Thanks for the help.

    Wednesday, May 23, 2012 3:25 AM
  • The solution a.van.york proposes is for a different issue - changing the volume used by DPM for storing the replicas and recovery points.

    The OP was looking for a way to have DPM continue to protect a datasource whose volume identifier changed.  I've run into this same problem myself (RAID 5 lost 2 disks, rebuilt, new volume ID).  DPM won't let me continue to protect the volume using the existing setup, it treats it as a different volume.

    Wednesday, February 20, 2013 11:29 PM