Data Centers

Avoiding excessive file replication in Windows 2000 due to antivirus software

Your virus scanner is supposed to protect your network from virus outbreaks. Unfortunately, it may also be killing network performance as well. We'll show you how to avoid antivirus-related performance hits without compromising security.

Nearly every network worthy of the name has antivirus protection. But because of the way some virus scanners perform their duties, network performance can suffer due to excessive file replication on systems using Distributed File System (DFS) and on other files that are regularly replicated between domain controllers. Here’s how you can avoid these slowdowns while still maintaining security.

Distributed File System
For more information about DFS, see the Daily Drill Down “Working with Windows 2000's Distributed File System.”

The devil is in the details
What could cause excessive replication as a result of simply scanning for viruses? Before I get into the answer, it’s important to understand some of the events that can trigger a file replication event in the first place. File replication can be triggered by:
  • Any modification to a file, including file attributes.
  • Modification of permissions to a file or directory in the replication scope.
  • Adding a new file to a replication-enabled directory.
  • Removing a file from a replication-enabled directory.

In short, any modification to any file, file attribute, or directory attribute in a replication scope can trigger a replication event.

A virus scanner has the potential to make modifications to the attributes of the files that it scans. Some virus scanners can change the last access time on a file during the scan, which will trigger replication. Good virus scanners don’t do this—they are able to put the access time and date attributes back to what they were before the scan took place. You may be asking, “Then what’s the problem?”

Even though the attributes are put back to their original values, the API call that is used to reset the file security information, SetFileSecurity, triggers a replication event. This can result in most of the contents of DFS shares and the SysVol directory being replicated following a virus scan. On small networks, this may not be a problem; but in environments with complex replication schemes and large numbers of files, this can result in a flood of network traffic, which can affect both system and network performance.

The symptoms
Depending on the amount of traffic that’s being replicated, the impact of this problem can range from mild to severe, and it can show a number of symptoms. Some of these symptoms include the replication of files that don’t show any changes, an unusual increase in network traffic between replication partners, and file replication taking place at odd hours when there should be no changes being made to files.

Nailing down the real culprit
Even though these symptoms are often due to an antivirus-related replication problem, before you decide that’s the case, it’s important to be sure you’ve found the real culprit. How do you know, for example, that someone hasn’t been working odd hours on a number of files or even an entire directory? Use the File Replication Service (FRS) logs to check this out before you proceed.

There are two registry keys that you must add to control how much information is logged by the FRS in Windows 2000. Using Regedit as shown in Figure A, browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters, and add the following two DWORD decimal values:
  • Debug Maximum Log Messages = 20000
  • Debug Log Files = 20

Figure A
Registry changes allow for more detailed logging.

Restart FRS in order to make these changes effective. After waiting for a period of time in which you think that erroneous replication may have taken place, you can look through the log file that is generated by FRS to see what the source of the problem may be. In a default Windows 2000 installation, the location of the log file is C:\winnt\debug, and the files are named NtFrs_####.log (where #### is incremented as needed). Look for entries in the log files with the string “ContentCmd” and that list security as one of the change reasons. It should look something like this:
 ContentCmd:  00008800  Flags  [Info Security ]

This is a sign that an antivirus program may be a culprit in file replication storms. The “info” flag indicates that there was a change to the basic file information, such as the date or time, while the security flag means that a change was made to the file’s security attributes.

Preventing a calamity
If you suspect your antivirus software is causing the replication problem, there are some things you can do, but only one real thing you should do. Some of the advice I’ve seen suggests taking replicated directories, including the sysvol directory, out of the virus scanner’s list of files. In my opinion, this is bad advice. What happens if an infected file ends up in one of these areas? Simply put, the virus-laden file is then replicated around your network to all of the server’s replication partners. This isn’t the best way to handle a virus outbreak.

The best course of action is to get an updated version of the virus scanner that is causing the problems. If your particular virus scanner doesn’t have an updated version available, you may want to seriously consider changing vendors.

Editor's Picks