Fix: Windows 10 Error 0x8007003B When Creating or Renaming Folders on a Network Share (Very Slow Folder Creation)

Problem:  Users on client machines running Windows 10 Pro Version 1607 Build 14393.x (the August 2016 Anniversary Edition) on a network with Windows Server 2012 R2 providing file shares ran into a frequent problem when copying, creating or renaming folders on any share residing on the server. Folder creation or folder renaming would take several minutes, would hang File Explorer, would often produce a popup error stating "Error 0x8007003B: An unexpected network error occurred" and - while this error was ongoing (several minutes) that file share would be unavailable to other processes running on the same client machine (which often led to other programs such as AutoCAD crashing.)

This error began shortly after one of our client machines was updated to Version 1607.  The previous version of Windows 10 did not exhibit the problem.  We were able to reliably reproduce the problem on other client workstations by simply upgrading them to the Anniversary Edition of Windows 10.

UPDATE 5 - March 15, 2017 - Fixed and being delivered this week via Automatic Updates.  You should verify that your workstations have installed the "Cumulative Update for Windows 10 Version 1607 for x64-based Systems (KB4013429)" released by Microsoft on Tuesday, March 14 2017.


UPDATE 4 - January 26, 2017 - TL:DR Might be fixed with a new official patch! (Testing today looks very good.)

Not yet available via automatic updates, a new preview update has been posted to the Microsoft Update Catalog. Look for KB3216755 for Windows 10 Version 1607.

This update appears to completely fix the problem on both my test system and on one of my clients networks.  The patch is for the Windows 10 Anniversary Edition workstations, no patch needed on the file server.  After applying the patch, and rebooting the workstations, you should turn search back on at the file server by setting the Windows Search service to Automatic in the Services MMC.

In my case, because Windows Search (on the 2012 R2 server) had been off for so long, indexing seemed to be taking too long - so I dumped the old index and forced the server to rebuild the search index from scratch. 


UPDATE 3 -Deprecated - advice no longer relevant at all.



UPDATE 2 - January 9, 2017 - NOT fixed yet. But a patch may be coming "soon."
Per a new post from MSFT employee Chris on the main MS thread posted January 6, 2017:

The backport of the fix for this is still in process.  It has not released in an update yet and will not be in the update releasing next week.
The Windows Insiders Release Preview ring gets a preview of the patches a couple of weeks before the release goes out to the public.
I will post back when it goes out to the Release Preview ring for Insiders as this will give you some notice before it goes public and a chance to try it out if you have a machine enrolled in it.  Hang in there.

UPDATE 1 - November 30, 2016 - TL:DR: It's NOT fixed yet.

• Microsoft announced yesterday that Windows 10 build 1607 version 14393.447 is being set as the Current Branch for Business (CBB) release.  I got a little excited on reading this news because I thought to myself "surely they'll have fixed this issue before pushing this out on WSUS for businesses that set their upgrade policies to the CBB."  Alas . . .  our companies testing on this build (with Server 2012 R2 fully patched to the very latest updates as of today, and Windows Search service on that server enabled and fully indexed) shows that the problem still exists.  And it's still somewhat random - as in the error and extreme lag when creating a folder on a share does not occur every time, but it occurs often enough to be be a show stopper.  I expect to see more dismay on the TechNet forum post linked below. That thread is already getting close to a new record in length for Microsoft's support site.

We now return you to the original post with the painful workaround below.


Finding the Issue:
After running through a massive troubleshooting session, in which we checked for buggy shell handlers, anti-virus conflicts, firewall conflicts, making sure the server and client were completely up to date and even swapping out a network switch, we finally found a single reference to this problem on the Microsoft Technet forums where someone had stumbled on the same problem.  Unlikely as we felt their solution was, it did solve the problem - at a cost.

For those interested, here is the post:
Problem creating/renaming a folder on a network share with Win10 Anniversary Update (Error 0x8007003B)

If you read that thread, the solution is to disable the Windows Search Service on the file server.

This is where things get painful for some of my clients - we use that service to allow fast searching on large file repositories.  In some cases there are dependencies on the server side search service where turning it off (or uninstalling it) may break other services such as Exchange Search or SharePoint Workspace.  So before you decide to follow the directions below - think and research your specific deployment needs carefully. In our case, we had to divorce certain functions onto separate VM's or physical servers before "fixing" file shares.


Solutions:

Note: Rebuilding the Index on the server did not help.  The only solution for now is to not run Windows Search on a file server.


Option 1: Simply disable Windows Search (but leave it installed in case this gets fixed soon and you want to turn it back on.) Then wait for Microsoft to fix this on Server 2012 R2 (and probably older servers running Windows Search 4.0).  This is also the best way to make sure you're not going to break other stuff as it's very easy to restore in short order.


Note: no reboot is required for this method.  Also be advised that if you perform steps 3 and 4 out of order, Windows will continuously restart the Windows Search service until you disable it.  I find it more graceful to disable first, then stop the service.

1. Open "Services"
2. Scroll down and find Windows Search > right click to select Properties.
3. Change "Startup type" to Disabled and click Apply
4. Stop the Windows Search service
5. That's it!

Option 2: Remove the Windows Search feature entirely on the file server.  This may require you to reposition your file servers to separate VM's or machines from your other servers.  Could be complicated - test and research first!

Note: this method requires a reboot of the file server.

1. Open "Server Manager"
2. From the Dashboard, click "Add roles and Features"
3. On the first page of the wizard, click the link "Start the Remove Roles and Features Wizard"
4. Select your server > Next
5. Skip the Server Roles (no changes) and click > Next
6. On the Remove Features page, scroll down and Un-check "Windows Search Service" then click > Next.
7. On completion, you need to restart your file server.

When or if Microsoft fixes this problem I will try to update this post.


UPDATE: I am hearing that this is a problem for pretty much all combinations of Windows 10 v1607 when using any windows server or client as a file sharing target on a LAN . . .    It's likely the above first option will work in those cases to solve the problem.