So there’s a neat little section in DFSR I never really paid much attention to the other day, until a customer was looking for a way to accomplish something that tied into this.
Subfolder filters in DFSR. So, just like a file filter (like *.mp3) where you can keep a file type from being replicated across a replication group (RG) you can actually filter subfolders that match criteria.
In this case the customer needed a single unified namespace for all their projects, but several of the folders in the root of the share didn’t need to be replicated as they were for the home office only (accounting and project management stuff).
So they were creating multiple RG’s per project, per dicipline. This was about to put them up against the DFSR 1024 rule (see http://technet.microsoft.com/en-us/library/cc779936(WS.10).aspx), and all the staging and conflict/deleted directories were killing their diskspace.
So, I suggested using a folder filter to keep the home office subfolders at the home office, while allowing all the others to replicate across the various offices around the world.
But it didn’t work. OR so I thought… as it turns out the technology is solid, I was just being impatient. Here’s why.
After setting up the RG and the subfolder filter, I created a subfolder and it immediately appeared on the replication partners. I deleted it and tried again and much to my dismay, there it was again.
After much head scratching I figured it out.
DFSR reads its configuration from AD and, well… I’m a pretty impatient person so I didn’t give the changes time to pick up on the new config. Now, the config showed up on all the partners, so I figured it knew about them but this isn’t the entire configuration – so, rather than waiting for changes to go I found a handy little command, “dfsrdiag pollad”
I ran that on the replication partners, then tried recreating the subfolder again and… viola – it stayed put.