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 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 - January 17, 2017 - NOT fixed yet, but a
SoCal Church IT Guy -- Posted January 17, 2017 at 9:56 AM
I had a bit of a breakthrough in this long running issue... entirely by accident.
The issue is repeatable if we use \\server\sharename\(and then any depth of folder tree) from any Windows 10 machine.
Today, I accidentally discovered that if we use \\FQDN\sharename(and then any depth of folder tree) the behavior goes away every time. And this holds true if we map a drive using FQDN as well.
So, for example:
BAD: \\fileserver\users\bob --> create any folder and try and rename it during 'creation' or rename it later... will fail, give errors, etc. after significant delay.(Bold added to the FQDN samples for emphasis)
GOOD: \\fileserver.ourdomain.org\users\bob --> can rename it however you like, at point of creation or later.
Also GOOD: MAP Z: to \\fileserver.ourdomain.org\users ... then use z: to create and or rename folders - no issues.
Indexed searches remain enabled and all searching is MUCH faster than the official workaround of disabling indexing.
His method returns full networked search functionality, appears to fix the long pause when creating folders from Win 10 - 1607. I've tested this on a small domain with Windows Server 2012 R2 (fully patched through Jan 2017) with Windows 10 Pro 1607 (also fully patched through Jan 2017) and it appears to work beautifully. I turned Windows Search back on at the server and let the Indexing process finish catching up. You need to make a slight change to remap shared folders to drive letters on the client using the FQDN recommendation as shown in SoCal Church IT Guy's example above. I used GP to push out an update to all mapped drives, rebooted the clients to pickup the new GPO, and testing so far looks very good.
EDIT re: Update 3: This method worked yesterday (and still works) on my small test bed, but did not work when applied to a clients production system. Trying to find out what differences might exist to see if I can narrow down the problem.
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.
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.
- Open "Services"
- Scroll down and find Windows Search > right click to select Properties.
- Change "Startup type" to Disabled and click Apply
- Stop the Windows Search service
- 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.
- Open "Server Manager"
- From the Dashboard, click "Add roles and Features"
- On the first page of the wizard, click the link "Start the Remove Roles and Features Wizard"
- Select your server > Next
- Skip the Server Roles (no changes) and click > Next
- On the Remove Features page, scroll down and Un-check "Windows Search Service" then click > Next.
- 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.