none
End User Recovery empty on some directories RRS feed

  • Question

  • We've just finished upgrading from DPM 2K7 to 2011. A new Server platform with a new install of 2K8R2.Uninstalled and reinstalled agents. We protect 2 file servers, SQL, Exchange and a few workstations. File server Directories are protected as specific volumes.  Everything is working correctly except EUR. When a client attempts EUR, some shares report no previous versions while others work OK. It appears that small folders work correctly, some of the large folders work, some don’t. If I map to the DPM EUR share, I can see all the previous files. This is the general configuration of a file server shares:

     

    Server 1

    D:\DATA\FORMS  shared as \\server1\forms  14GB, 5200files, 57folders,  No previous versions

    D:\DATA\PROJECT_FILES shared as  \\server1\project_files   56GB, 47000files,  11000folders, EUR OK

    D:\DATA\PUBLIC shared as \\server1\public 32BG, 36000files, 3388folders, EUR OK

     

    Server 2

    D:\CAD shared as \\server2\CAD 288GB, 389918files, 25253folders, No previous versions

    D:\DRAWINGS shared as \\server2\drawings 50GB, 29862files, 297folders, EUR OK

    D:\SPECS shared as \\server2\specs 497MB, 188files, 2 folders, No previous versions

    Thursday, January 12, 2012 11:48 PM

Answers

  • If there is nothing broken, DPM should update the entry in AD. IF I am not mistaken this happens on every sync or recovery point
    Thanks, Wilson Souza - MSFT This posting is provided "AS IS" with no warranties, and confers no rights
    • Marked as answer by David_V Friday, January 13, 2012 8:22 PM
    Friday, January 13, 2012 5:44 PM

All replies

  • Check if the command below return all shares above

    dsquery * cn=ms-sharemapconfiguration,cn=system,dc=<domain>,dc=<domain> -attr ms-backupSrvShare ms-productionSrvShare

     

    If the FQDN for the domain in question is xxx.yyy.zzz, the command would be like:

     

    dsquery * cn=ms-sharemapconfiguration,cn=system,dc=xxx,dc=yyy,dc=zzz -attr ms-backupSrvShare ms-productionSrvShare

     

     

     


    Thanks, Wilson Souza - MSFT This posting is provided "AS IS" with no warranties, and confers no rights
    Friday, January 13, 2012 12:15 AM
  • In the case of server2, there are several entries that are artifacts from the last two retired DMS servers that do not reflect the correct new server. For example:

     

    \\MSDPM.domain.com\....

    \\MSDPM2.domain.com\..

     

    The current server is:

     

    \\MSDPM3.domain.com\..

     

    How do I correct this?

     

    In the case of server1, the shares look correct, including FORMS that is missing EUR.

    Friday, January 13, 2012 2:21 AM
  • You can delete the old entries via ADSIEdit.

    If you access these shares directly from the DPM server (from the mapping shares created on the DPM server), can you see previous versions (for FORMS for instance)?


    Thanks, Wilson Souza - MSFT This posting is provided "AS IS" with no warranties, and confers no rights
    Friday, January 13, 2012 8:40 AM
  • Yes, a mapped DPM share has previous versions for FORMS available.

    Should I attempt to manually edit the bogus entries, or delete them? If deleted, how will they get re-made?

    Friday, January 13, 2012 3:53 PM
  • If there is nothing broken, DPM should update the entry in AD. IF I am not mistaken this happens on every sync or recovery point
    Thanks, Wilson Souza - MSFT This posting is provided "AS IS" with no warranties, and confers no rights
    • Marked as answer by David_V Friday, January 13, 2012 8:22 PM
    Friday, January 13, 2012 5:44 PM
  • I manually deleted each DPM share that referenced the old servers and now Prior Versions is avialable for all the shares on both file servers.

    I think all these faulty old entries were shares that were being DPM protected and moved to a new server or folder structure while still protected and then the protection groups modified. Apparently they should have been removed from protection first, then moved and re-protected.

    Thank you for your help.

    Friday, January 13, 2012 8:22 PM