Here is the configuration. Private network and domain (foo.bar). 2 file servers running 2K8R2 (file1.foo.bar and file2.foo.bar). Created a share on each server (\\file1\share and \\file2\share). Setup DFS on the domain and created a namespace (\\foo.bar). Created a folder (dfsshare) in DFS with 2 targets (\\file1\share and \\file2\share). Created the replication group and everything works except...

During testing (Win 7 SP1 x64 client) if I copy a large file (230MB) to the DFS share (\\foo.bar\dfsshare) I get the following error:

Error 0x8007003B: An unexpected network error occured.

If I copy the same file directly to one of the file servers (\\file1\share) I don't get the error and the file replicates to the other file server and shows up in the DFS share. No error when copying small files to the DFS share.

I found hotfix 983620 http://support.microsoft.com/kb/983620 but that hotfix was included in SP1 for Windows 7.

UPDATE: Narrowed it down to ~41MB file size. Above that and I get the error. Below that and it works fine. Also, network is a LAN (no routers between me and the servers) running 1000Base T.

UPDATE2: Also verified that Windows XP SP3 machines work fine so this is limited to the Windows 7 SP1 boxes.

UPDATE3: Configured the same way on our dev network and it works. Move the workstation to an OU that blocks all the DISA GPOs and it was still broke. Turned off DFS replication and it works. Turned DFS replication back on and it continued to work (very confused at this point). Put the workstation back in the proper OU and it broke again. This means it must be one of the DISA settings being applied by the GPOs. Moved the workstation back to the blocking OU and it remains broke until I turn off replication.

UPDATE4: Going through all the GPOs and we found out which one it was. It's a GPO that sets up 802.1x which seams very strange. We started googling DFS replication and 802.1x and found the real culprit. Not sure how the interaction of the 802.1x and the real culprit causes the problem (maybe someone can answer that). Anyway, if someone else answers with the correct culprit, or better yet, can explain why the interaction to the 802.1x GPO would cause the problem, I'll award the rep. After the bounty is expired I'll put the answer in here.

SOLUTION: It turns out the problem was McAfee on the workstation. We had do disable "scan network drives". Once we did this everything worked. This error only occurs when you have 802.1x configured and the DFS share is set to replicate. We now have an exception from security since the network shares are being scanned on the server. There were no errors in the windows logs or on the ePO server.

  • 1
    Can you please clarify if you are able to always copy files of any size to both direct server name based paths \\file1\share and \\file2\share but fail when copying the same file to the DFS based path \\foo.bar\foo.bar\dfsshare?
    – maweeras
    Jul 21, 2011 at 22:48
  • Yes, that is correct. When copying the large file to the dfs share it fails. When copying the same file to the file server share (file1\share or file2\share) it works fine. hmmmm....wait. After thinking about it I only copied the file to file1. I'll verify tomorrow that it also works to file2. Not sure if that matters but I'll verify.
    – murisonc
    Jul 21, 2011 at 22:56
  • 1
    Please check if these fixes make a difference support.microsoft.com/kb/968429 . Else please report if you already have them. Off to sleep so will check your response later.
    – maweeras
    Jul 21, 2011 at 22:59
  • Yes check file2 because we dont know where the DFS referral was pointing to yet based on what you reported so far.
    – maweeras
    Jul 21, 2011 at 23:06
  • 1
    Don't know how much to thank you for this. I was struggling with this problem for months. McAfee was the problem (McAfee gateway AV). Once I put the exclusion in place, I can copy files over VPN, between Linux and Server 2008, back and forth.
    – user152399
    Jan 7, 2013 at 18:16

1 Answer 1


Answering my own question in the hopes it will help others. It turns out that the combination of having 802.1x configured (through GPO) and having McAfee ePO configured to scan network drives when uploading large files to a DFS share that is also being replicated will cause this error. Not sure if McAfee knows but we are trying to open a ticket with them. We got around this by disabling the scan network drives setting in ePO and this was ok with security because we have McAfee on the file servers.

  • 1
    Running Windows 10 with Bitdefender Total Security 2015 Firewall enabled will cause this error code 0x8007003B for large files transferred to a mapped drive, on my ReadyNAS, a 3GB will do it. Solution: Turn off Bitdefender Total Security 2015 use Windows Firewall. Aug 18, 2015 at 2:23
  • I ran into the same issue using a Windows 10 1903 without any additional security installed.Disabling the default real time protection did not solve it. Checking the windows event log, I could find a System warning Intel(R) 82579LM Gigabit Network Connection Network link is disconnected.. Possibly a network related problem or driver.
    – szab.kel
    Aug 14, 2019 at 12:15
  • Ended up being my network driver. Windows 10 update loves to break it. (Just uninstall it in device manager and search for devices, will reinstall)
    – szab.kel
    Aug 14, 2019 at 12:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .