I’ve been running into issues with DFSR and VSS which causes Shadow Copy Components backups to fail because one of the VSS writers had disappeared:

The Environment:
2 x Windows 2008 Enterprise x64 Servers
Hardware: Blades
Memory: 16GB
Disk Space: C: 40Gb, D: 100GB
Services: DFSR, Citrix XenApp 5.0, Netbackup, Terminal Server.

The Issue: Netbackup had been failing with ERROR 71 (Path not found) when we tried to backup Shadow Copy Component and we also noticed EventID: 8192 errors in the applications log from VSS. It appeared that the Shadow Copy Optimization Writer had disappeared from the list of VSS writers and this is netbackup’s API dependency.  In this case I opened a case with a Microsoft to troubleshoot further.

EVENTID: 8193

Netbackup Error: 71

Resolution: We were replicating with DFSR the local profiles for the Citrix Xenapp environment so that documents saved would appear in both location on Server A and Server B. The trouble with this method is that DFSR leaves open handles and as a result temporary profiles are created. In some cases the profile ID is locked and another one created, which in return renames the original profile id with a .bak extension in the system registry. When these backup profile IDs are created the Shadow Copy Optimization writer disappears from the writer list. I’m still asking the question to Microsoft how the profilelist and VSS “Shadow Copy Optimization” are dependant on each other.

It is NOT recommend to use DFSR to replication local user profiles i.e. C:\users and I have since removed this replication group. You will need to delete the .bak profile IDs from the following path in the registry:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

an example would be:  S-1-5-21-106000298-1275210071-1417001363-12345.bak

As with all system changes I would highly recommend exporting the keys or backing up the registry.

I’ve now decided to user Terminal Server user profiles with a path set to server A and this path is replicated to Server B using DFSR, with no further issues. For DR reasons the TS path  is actually a CNAME which I can change depending on server status and this was tested to work fine during fail-over.