Guest Blogger – DFS is a beautiful thing!

Simon Collier (Edmonton, Alberta, IT Pro)

Windows Server 2003 R2 and DFS

During the Edmonton stop of the Vista/Office/MOSS 2007 launch tour I met Simon Collier.  Simon wanted to share some learnings he aquired with his implementation of Windows Server 2003 R2 using DFS.  Got a similar story to share, get in contact with one of the IT Pro's (hint: there is a contact button to the left) and let us know.  We would love to post it!


We have three file servers: One in Edmonton, one in Calgary, and one in Vancouver. They are all Windows 2003 R2 and use DFS in a full-mesh topology with Active Directory-integrated namespaces. This technology replicates all of the files to each of the servers and allows our roaming users to access their files from whichever server is physically closest to them, according to the site they are currently in. This, basically, rocks; however we did notice some teething problems about a week after we set it up though.


The link to/from Calgary was horrible, while I could ping Vancouver’s server with a (fairly) consistent response time of 25ms or so, I pinged Calgary’s server and got a response time of more like 600ms. This was awful, and appeared to be a result of the Calgary server sending/receiving a tonne of data, all the time. The traffic appeared to be causing issues for some of the users at that location when trying to use the internet to connect to other Edmonton servers. There just wasn’t enough bandwidth.


If I restarted the server, the traffic stopped for a while, then picked up again – so I KNEW it was the server rather than a client that had gone haywire. I restarted the DFS Replication service and the traffic stopped for a while, then picked up again. So now I KNEW it was DFS, rather than some random network glitch or a broken NIC.  Both Vancouver and Calgary have a near-identical setup in terms of hardware and software (both bought and installed at the same time). Same version of Windows, same type of server, same firewalls even.  They did have Symantec AV installed and up to date, so it wasn’t a virus. It’s version 10 of SAV, and this had been disabled incase that was the issue (there was a problem with v7/7.5 and DFS, according to a Microsoft KB article). I was stumped.


Eventually I decided to use a Microsoft Support call. It took a couple of hours on the phone, and then the support guys worked on their own for about a day. The next morning they called back with an answer.


We use three Intel(R) PRO/1000 MT Server Adapters in each of our remote servers, teamed together. Each of these adapters (the physical, not the virtual team) was setup with the default “advanced” settings. This is what needed to be changed on the problem server:


Local Area Connection 1/2/3 > Properties > Configure > Advanced:

Offload Receive IP Checksum: Default=On, Changed To=Off
Offload Receive TCP Checksum: Default=On, Changed To=Off
Offload Transmit IP Checksum: Default=On, Changed To=Off
Offload Transmit TCP Checksum: Default=On, Changed To=Off
Offload TCP Segmentation: Default=On, Leave At=On


This seems to have done it.  There is no explanation of why it caused a problem on one server and not the other (identical) Vancouver server.  We have been using DFS for about 4 months now and have had no other problems. Over this period we have a 92% reduction in network traffic compared to if I was copying the files manually (e.g. using robocopy). In real terms, 12.8GB of traffic has flowed over the WAN instead of the 157GB it would have taken if DFS was not being used. The full-mesh implementation also means that any site can be down without affecting any other site.


DFS is a beautiful thing!


Simon Collier is a Network Administrator for a department at the University of Alberta, with a focus on Microsoft servers. His current favourite time-saving technologies are Windows Mobile 5, Desktop Search, greylisting and Office 2007.

Comments (0)

Skip to main content