Knowledge Center

Support for updating from Distributed File System shares
Technical Articles ID:   KB53420
Last Modified:  7/5/2018


McAfee VirusScan Enterprise (VSE) 8.x
McAfee ePolicy Orchestrator (ePO) 5.x, 4.x
Microsoft Distributed File System (DFS)

For details of VSE 8.x supported environments, see KB51111.


The use of Microsoft DFS for updating is not recommended unless you have a good understanding of the architecture and procedure involved.

DFS is a file storage architecture where multiple physical locations can be made to appear as the same logical host, therefore increasing availability of files (multiple locations means more redundancy) as well as minimizing the network distance users must travel to access this data.

Data from each of the DFS shares is automatically replicated among the other DFS shares using the Microsoft Distributed File System Replication (DFSR) service, to maintain a consistent and accurate collection of files and their contents.

The listed McAfee products supports the use of DFS shares in the following scenarios:
  • Updating point products that use McAfee Agent
  • Replicating to DFS shares using ePolicy Orchestrator (ePO) to make anti-virus updates available to clients
However, DFS does have limitations, so remember the following points to ensure that your clients always find a consistent set of update files in the distributed repository when they have to update:

All DFS managed shares will go offline at the same time
When ePO uses its own mechanism to replicate to normal distributed repositories, it replicates to several repositories at a time in parallel. During replication these repositories are marked as disabled in the SiteStat.xml. When these repositories have completed replication, they are enabled in the SiteStat.xml and replication commences to another batch of distributed repositories. This way, there will only be a small number of distributed repositories offline at any one time.

Any agents that try to update from a disabled repository fail to connect (because of the disabled flag in the SiteStat.xml), and choose the next available repository from the Sitelist.xml file (this is dependent on the user configuration in the agent policy, which chooses repositories by Ping Time, Subnet Mask, or User Defined List).

DFS replicates each file modified by the ePO replication task to each of the DFS-managed Virtual Shares using the File Replication Service (FRS). The first file that is modified is the SiteStat.xml file. When the status flag is set to disabled, this change is replicated to all DFS-managed shares. At this point, no products that use the common framework to update will be able to use that share; this prevents agents from obtaining mismatched files that are in the middle of replication.

What this means is that all DFS shares replicated with FRS become unavailable (disabled) almost simultaneously, and are not re-enabled until replication has completed (which is different from ePO replication, where the number of repositories replicated to in parallel is 'number of CPUs x 6').

Consider the availability of the shares created, their geographical locations, and minimize what actually needs replicating
  • If your DFS links are weak or slow, consider changing the always on replication schedule of DFS to a schedule that does not occur during peak times. This must work in synchronization with the ePO Repository Pull tasks. If you are running Repository Pull tasks more frequently, the DFS must be enabled to distribute the new updates.
  • Do not have more products or patches in your Master Repository than you need. For example, if you never use ePO to deploy a certain product, do not add the installation package into the Master Repository.
  • Where possible, use Multiple DFS links to each DFS share to increase the redundancy and share availability.
  • During the initial roll-out and testing of this mechanism, keep non-DFS managed shares available, so that in the event of a failure, there are other ePO managed distributed repositories available.
Consider the necessary user access to the DFS update share
The principle of least access always applies to shares. Clients require only read access to update from a DFS share, but the ePO server requires full access to the share to replicate to it. This principle is even more important when using DFS, as any changes made to the contents of a repository share will be replicated to all other DFS shares.

Share content integrity
DFS determines the files that should be replicated by monitoring the file modification - no integrity checking is performed. ePO verifies the Checksum for each replicated file to ensure that it has not been modified. Because DFS does not check the file content, share access security is very important. Consider creating a dedicated ePO replication account with sole write access to the DFS shares.

Rate this document


This article is available in the following languages:

English United States

Glossary of Technical Terms

 Highlight Glossary Terms

Please take a moment to browse our Glossary of Technical Terms.