Microsoft's official enterprise support blog for AD DS and more
Ned here again. The cat is out of the bag now and we're a little more free to talk about DFSR features that are planned (not guaranteed - planned) to release with Windows Server 2008 R2. Our friends at the File Cabinet blog have posted an excellent writeup - definitely worth a look:
DFS Replication: What’s new in Windows Server™ 2008 R2
Here's the short and sweet list of areas that were added or improved:
You can try all these out in a test environment right now - hurry up and grab the ISO's before it's too late.
- Ned 'The Short Simpson' Pyle
So. What about file locking.
When are Microsoft planning to do this? In Windows Server 2030? How long do we have to wait?
I cannot speak to future product decisions. DFSR is multi-master replication, so the lack of distributed locking is a conscious decision. Those systems that do locking have to sacrifice redundancy though, as they use a single-point-of failure 'broker' server that must be kept up to handle locks.
If you are interested in a locking system, there are a variety of products out there that will do this:
Hey Ned! Can you post an article on the recommended Patches to install that would not be installed with windows update for DFSR on Server 2008 (non R2)? I've seen an Article that lists several patches for Server 2003 R2 that apparently work with Server 2008 but a list specific to Server 2008 would be fantastic. Thank you!
We have a KB, but it is not yet public (booo!). The only hotfix available right now is actually an NTFS update that fixes a DFSR symptom on 2008:
956123 Files that are copied into replicated file shares may not be replicated for an unexpectedly long time when antivirus software is installed on the originating server
So could you possibly post a "non MS supported" list of "Ned's Server 2008 DFSR patches" or would this KB 956123 be the only one that you recommend at this point in time? Thanks allot Ned!
Right now there is only one other hotfix released for 2008, but it's for a *very* specific DFSR migration scenario with read-only DC's.
967326 Data loss occurs after you use the Dfsrmig.exe tool to migrate the SYSVOL share from the FRS to the DFSR service in a Windows Server 2008-based domain
Otherwise, that one I have above is the only one we recommend currently.
Woah, holy s**t. This will be amazing.
I read over and over from all sorts of sites that you can use robocopy to pre-stage a DFS-R replica on another server. That's FALSE. Maybe you could do it with FRS, but not with DFSR.
DFSR requires a local database of hashes in order for it to not re-replicate everything from the source server. The only way to get that database is by replicating the data. It's a chicken or egg situation. With Server 2003 R2 and Server 2008, I've use all sorts of work-arounds like a Virtual machine on a USB drive, which will recieve a full replica of the data. Then I bring the Virtual machine to the target server, and replicate everything back to the new server. It's a slow and painful operation, but it's better than replicating a Terabyte or more over a VPN connection.
So, a tool to allow you to pre-stage by copying the files in and then running a hash-check to build the database is desperately needed. It's only too bad that you need to get 2008 R2 to do it, which sucks, but at least there's light at the end of the tunnel.
I really like DFSR a lot. It's the only multiple-master replication system out there, in fact (except FRS, but that's so broken it's barely mentionable.) It works on very large replica sets and it's fairly efficient. But, the problem with no pre-staging has always been a big problem for me.
Is there any way of setting up a DFSR Hub and Spoke topology such that I don't have any spokes at the moment, only 3 hubs. I will want to add spokes in the future, but not yet? I would prefer not to have a Full Mesh now, only to change it when spokes become available.
You can always use a custom topology where you configure it however you like - the huba and spoke versus mesh versus whatever are just made up terms in the admin console. Make sure that the topology is compelte though (no one-way connections).