We recently had a problem where one of our two main Windows Server 2008 file servers (usually the same one, but sometimes the other) would suddenly stop responding to network requests. Ping was fine, and you could RDP in (albeit very, very slowly), but file shares appeared to vanish as seen from client machines.
It was intermittent, and even when looking at Resource Monitor on the server, it wasn’t clear what was causing it. No specific process was hogging all the RAM or disk access time, but disk reads cumulatively were through the roof. If felt like a failing hard drive, but every drive on the RAID had been replaced (separately) fairly recently, and disk checks threw up nothing unusual. Indeed, for most of the time everything was perfectly OK and a restart or just waiting for a while returned it to normal.
The usual suspects were ruled out – virus scans, backups and so on, and we were at a bit of a loss as to what it might be. Then I found if I sorted disk usage in Resource Monitor by Image Name (I’d been sorting it by Read, to show the most disk-heavy process first) I realised that one process appeared many hundreds of times – dfsrs.exe. This process deals with DFS replication, keeping folders synced between servers, and it seemed this was the cause. Unfortunately, I couldn’t just turn it off as we need DFS replication to keep user home folders on the server synced between the two main file servers, but now I could see where the problem lay, I could find the root of the issue.
Which was, of course, Google Chrome.
We use roaming profiles for our users, and to speed up logging on and off, some of the Application Data folders are redirected back to a folder on the network. It has worked well, only now, when we have fairly recently moved to having users on DFS shares, we’ve hit this snag. You see, Google caches a lot of stuff and constantly creates and updates a multitude of files in the user’s Application Data folder. Every time this happens, DFS has to sync it. With a few hundred users all using Chrome (it launches on login!) that’s one hell of a lot files to keep in sync – even if they’re very small.
Obviously, most of this data is fleeting and temporary, but DFS doesn’t know that. Thankfully, there was a solution: exclude some of these folders from syncing. Sure, the cache won’t be the same between the two copies of the folder, but that isn’t important as it’s deleted when Chrome is closed anyway.
In the DFS Management console, find the Replicated Folder, right click, and choose Properties.
You’ll see this window, with the two fields “File filter” and “Subfolder filter”:
It’s here you put the names of all the files and folders you don’t want to sync between DFS servers for that specific replicated folder. Chrome specific folders that were hammering the sync and can be added include:
Application Cache, GPUCache, ChromeDWriteFontCache, Session Storage, Pepper Data, Cookies
While I was there, I took the liberty of adding some other, non-Chrome folders that also didn’t need to be there, like Flash Player and Distiller 10. I also put thumbs.db in as a file exception as that was coming up a lot too. Note that “~*., *.bak, *.tmp” is filled in as default.
Important: this system literally just matches based on the file and folder names. Yes, it’s stupid. If your users create a folder called “GPUCache” somewhere else in the replicated folder, it won’t get synced. So be careful what you do choose!
Everything is much better now, with the server barely being worried by disk reads, as it should be.
Hi deKay,
Thank you so much for this post. Chrome profiles on DFS-N which are also being synced with DFS-R is a pain in the a**
To excluded those folders helps enormously considering replication traffic will go down a LOT.
Keep up the good work with these posts!