Search code examples
windowsnetwork-programmingdriver

File operations not going through Network Redirector driver when computer is joined to Active Directory

On our servers there is a 3rd party network redirector driver installed (from Avid Technology, Nexis filesystem).

When the computer with the driver installed is not joined to the AD everything works as expected, but as soon as the computer is joined to the AD, then it seems that the file operations don't hit Avid's redirector driver, possibly because the client wants to involve the DC and DFS.

Looking at what happens when doing (nexis is Avid's shared storage using the redirector driver and nxzajem is a "workspace" on nexis. All of this should be handled by the driver): echo 2 > \nexis\nxzajem\test.txt in processmonitor reveals this:

enter image description here

If I disconnect the DC from the network (since I can do that) the operation takes whole lot longer and fails in the end, suggesting that the client computer wanted to query the DNS and the DC for the operation, while it should be handled by Avid's redirector.

Looking in the registry to check the order of redirectors, I can see that Avid's redirector is listed first.

Does anyone familiar with inner workings of redirector drivers have any ideas why this might be happening? Of course I don't have Avid's source code for their Nexis client :)

Solution

  • Cause of the problem was that the domain's NetBIOS name was same as the name of the prefix which was handled by Avid's redirector driver.

    By design the DFS client, which is turned on by default takes precedence over all other network redirectors specified in the registry. MSDN article describing MUP and DFS interaction

    When the machine was not in the domain, DFS client did not have much to do, so it just passed the prefix resolution to other redirectors. But when the machine joined the domain, DFS client took over due to NetBIOS name clash. Since no DFS was configured the "shares" of Avid's redirector could not be found.

    This also explains the behavior observed in ProcessMonitor.