First published on TechNet on Jan 22, 2008
here. If you’re a regular reader of the
, you’ve probably already read about all the new features for
DFS Replication (DFSR)
added in Windows Server 2008. If not, trot on over
and drink your fill. Just to summarize some of these cool new features:
Windows Server 2003 R2
Windows Server 2008
SYSVOL replicated with FRS service
SYSVOL replicated with DFSR (via migration or by creating your domain in 2008 functional mode)
RPC synchronous pipes
RPC asynchronous pipes (when replicating between 2008 servers)
Synchronous inputs/outputs (I/Os)
Normal Priority I/Os
Low Priority I/Os (this reduces the load on the system as a result of replication)
4 concurrent file downloads
16 concurrent file downloads
Database recovery mechanism
Improved Dirty Shutdown Recovery
Algorithmic Enhancements for the scheduler
Number of Replication Groups * number of Replicated Folders * number of simultaneously replicating Connections must be less than 1024
Limited only by your hardware, network connections, and frequency of data change.
But there’s something missing. There’s a little history here, so walk with me down technical memory lane.
When DFSR was released on Windows Server 2003 R2 in February 2006, it had a list of file extensions that were non-compressible. These were:
When you added a file to a DFSR content set and it was at least 64KB in size, the DFSR service placed a copy of the file in the Staging folder. The file had an alternate data stream added that held the computed
Remote Differential Compression
(RDC) signatures. RDC is what allows DFSR to only replicate the parts of the file that have changed. But files were
compressed with a standard compression algorithm called XPRESS, which is similar to ZIP or RAR compression. Any files that ended up in staging were compressed with XPRESS
they had an extension that was on this list. Since there was no point in trying to shrink files that were already compressed (like ZIP or JPG), we simply didn’t bother; it wasted disk and CPU resources after all.
After digging around in the product design request database here, looking at the source code, and pinging the developers, I came up short: the list was hardcoded. Rats. I wrote up a short internal article and promptly forgot about it.
Fast forward to Windows Server 2008.
You guessed it – we can do this now and here are the steps:
1. Your Active Directory forest schema must have been extended with
to Windows Server 2008 (or you have installed a new Win2008 forest). If this is not done you won’t have the new attribute necessary for this to work.
2. Setup DFSR on a few Win2008 machines (add the role through
to configure, and let the servers pick up the new settings).
3. On one of your domain controllers run
as a Domain Administrator.
4. Navigate to your content set that you want to modify. So for example:
5. Right-click the replicated folder (cn=public) and choose properties.
6. Scroll down a ways and edit the attribute
Any extensions we add in here will become the new rule for compression. So if we just add FOO then all files that are *.foo will no longer be compressed. We need to make sure we comma separate a list of files, and there must not be any spaces. Also, this list is destructive – if we put anything in here, then the default list of extensions like ZIP or JPG is ignored going forward unless we add them back. Finally, if the attribute is set to “<Not Set>” it will use the default extension list from above.
7. So let’s add our new extension. We have an application that creates drawing files called *.NED. These NED files are already compressed so we don’t want DFSR to waste time trying to compress them more. In the
field of our
attribute we all of the below:
8. We click ok and exit out of
. We wait for AD replication to complete. We wait for the DFSR servers to pick up the change through their polling process (or run
files are created or modified, they will no longer be compressed in the staging directory. Sweet! If for some reason you wanted to turn off
file compression, you can set the
attribute to contain just an asterisk. This would have the minor upside of saving some CPU and disk time when staging, but could have a
downside in bandwidth consumption and replication time for larger files – so this is not recommended and you shouldn’t do this without significant testing in your lab environment. You cannot tailor RDC to only affect certain file types – it is limited to off/on/minimum size, just like in R2.
And yes, we have a KB article for this in the works. The beauty of blogging means you don’t have to wait for it. :)