Known Issues using DFS on EFT

THE INFORMATION IN THIS ARTICLE APPLIES TO:

• All EFT Server versions using High Availability (HA) mode or shared configuration environments

SYMPTOM

When DFS (Distributed File System) is used for EFT shared configuration, you may observe:

• You can access the admin console on both nodes at the same time

• EFT mastership issues

• Event rule load balancing issues

• File locking issues when processing files in event rules

• Upload and download inconsistencies

• Inconsistent permission behavior

• Configuration synchronization anomalies between nodes

Procmon and EFT logs are the primary tools that can help demonstrate file locking inconsistencies and redirection behavior when DFS is in use.

DFS is not a supported platform for EFT shared configuration. EFT relies heavily on persistent file locking to maintain mastership, configuration integrity, and proper HA operation. DFS (including DFS Namespaces and DFS Replication) does not guarantee the file locking consistency required for EFT shared environments.

CAUSE

The main issue with DFS implementations is the lack of guaranteed file locking persistence across namespace targets.

In a DFS implementation, if EFT navigates to the namespace \\domain\folder, it can be redirected to one of multiple file servers configured as targets behind the scenes. As a result:

• Node 1 may be connected to File Server A

• Node 2 may be connected to File Server B

Although both nodes are accessing the same namespace path, they may actually be interacting with different backend storage locations. This behavior breaks the file locking assumptions required by EFT for HA mastership and shared configuration consistency.

DFS uses its own referral ordering and priority logic to determine which file server a client connects to.

Refer to the following Microsoft documents for details:

• Set the Ordering Method for Targets in Referrals
• Set target priority to override referral ordering

RESOLUTION

DFS must not be used for EFT shared configuration, site root paths in HA, or any storage location that requires consistent file locking across nodes.

Change DFS storage to one of the following supported options:

• For production mission-critical deployments, use an enterprise NAS or SAN solution that provides true shared storage with proper file locking support.

• For non-mission-critical deployments, use a standard Windows file share hosted on a single file server (not backed by DFS).

All EFT HA nodes must reference the same physical storage location without DFS namespace redirection.

MORE INFORMATION

• DFS Namespaces is a role service in Windows Server that enables you to group shared folders located on different servers into one or more logically structured namespaces. This makes it possible to give users a virtual view of shared folders, where a single path leads to files located on multiple servers.

• DFS Replication is a role service in Windows Server that enables you to efficiently replicate folders across multiple servers and sites. DFS Replication can be used to keep folders synchronized between servers across limited bandwidth network connections. https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview

• How does DFS interact with EFT? EFT sees the DFS namespace as a simple file share, as in \domain-name\folder\EFTconfig, for example. DFS can also be used for the config and site root, and also house the targets of event rules. To identify if DFS is in use, simply navigate to the shared path via Windows File Explorer and right-click -> Properties. If DFS is in use, you will see a tab called DFS on which you can also confirm which file server this EFT node is connected to by looking at the “Active” status.