When configuring Citrix provisioning services for HA (feature of Xendesktop) you first need to decide on the type of storage you will use to host your VHD images. PVS provides active-active HA meaning each server will need to have access to the same set of VHDs simultaneously. NTFS will not tolerate multiple servers accessing the same LUN in a read-write mode, even if you are not actively making changes from the other servers. This just happens to be a limitation of NTFS.
The way PVS is designed allows us to not only host the VHDs in a central store location but also in a distributed model where we can have locally attached storage on each server and a copy of that VHD located on each server. PVS HA White Paper
A lot of our customers have typically leaned toward the distributed model of local storage or LUN-per-server because of simplicity, cost and scalability. This model does not require a SAN or clustered file system and it works on virtual as well as physical pvs server farms. It does comes with some additional administrative overhead requiring the administrator to copy new VHDs to all pvs servers in the farm and also making sure not to do it in the middle of production hours. Getting to the point of this post … a while back one of our customers and now Citrix TRM Jeff Laughter let me in how he used Microsoft’s DFS-R (Distributed File System Replication) to reduce some of this administrative overhead and also reducing the network bandwidth required and thought I would share it.

Microsoft’s DFS-Replication (not DFS-namespace) is a replication engine with multiple features including replication scheduling, bandwidth throttling, and Cross File Remote Differential Compression (CF-RDC) which uses a heuristic to determine files that are similar to the file that needs to be replicated, and uses blocks of the similar files that are identical to the replicating file to minimize the amount of data transferred over the network.

If you are using a Local Store HA configuration you can manually copy new VHD updates to each server’s local store or create a script to automate this copy but as a nice alternative you can use DFS-R to efficiently replicate these updated VHDs. For example if I am sending out a updated version of my VHD image and I make 100 MB worth of changes to my 20 GB VHD image instead of copying the full 20 GB file it would just replicate the differences in the file. It compares identical blocks at the file level.
We then can combine this with the pvs automatic update feature which will detect the new VHD image version and reassign your endpoints with the new VHD.
This is great for local HA configurations but can also be used for centrally distributing VHD updates for branch or remote servers.

I have also recorded a video of setting up a 2008 R2 DFS-R replication group. Click here
These instructions are for 2008 R2-
1. Under Server Manager>Roles>File Services Click Add Role Services and choose DFS Replication. You do not want to choose DFS namespace just DFS Replication. (this step needs to be done on each PVS server in the farm)
2. Under Server Manager>File Services>DFS Management> Right Click on the Replication node and choose New Replication Group Wizard
3. Select Multipurpose replication group>Next
4. Provide Name of Replication Group and the Domain information>Next
5. Add each PVS server into the group>Next
6. Choose the “Hub and Spoke” topology>Next
7. Select your HUB server>Next this will be the PVS server that you will use for image creation and updates.
8. Optional hub member>Leave defaults>Next
9. You can choose to Replicate continuously with specified bandwidth or specify days and times that it is allowed. I have set it to continuous because I will not be moving the updated VHDs into the HUB directory until I am ready for them to replicate but you could use the scheduling so it doesn’t replicate until after hours. >Next
10. Choose Primary member(in our case the HUB server)>Next
11. Select your primary replication folder>Next this will be your main HUB directory that will be Read/Write.
12. Select Edit for each member spoke server and choose a local directory path (select the Read-only checkbox)>Next>Create this will be the path you have defined in PVS for your “local store”.
13. You will now need to increase the quota size for each member server. The default is 4 GB.

Now that you have configured DFS-r you can test it out by moving a VHD image into the HUB directory and let it replicate(you can force replication with Dfsrdiag SyncNow) then make a copy of that same VHD make some changes then move it into the HUB directory. You should see a major decrease in the time it takes for the second replication to complete.
If you are not using the PVS Automatic Updates feature (page 123) you will want to enable this on each of your PVS servers so you will not have to manually add new VHDs into the console and assign to endpoints.