Sunday, September 4, 2016

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 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 better possible workaround has been discovered that may be more palatable than the original method. Thanks to SoCal Church IT Guy in this comment below for reporting this!

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.

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.
(Bold added to the FQDN samples for emphasis)

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.


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.


58 comments:

  1. You don't have to completely stop the service. You can just exclude the folder location(s) that are being used as shared folders.

    ReplyDelete
    Replies
    1. That works nicely too, although I was trying to keep things simple. But then the question becomes, if you exclude all the shares on the server from Windows Search (Indexing) service, for what purpose are we running the service on a server? :D

      Delete
  2. Disabling windows search also stops the Windows Media Player Network Sharing Service. I found that if you disable the media player sharing service, you can leave windows search running.

    ReplyDelete
    Replies
    1. Interesting. On our servers this is generally not an option (no media sharing service by default) but on our client workstations we always disable that service to prevent network congestion on large LAN's.

      Delete
  3. I just had this issue on a clients network. Stopping the indexing service is an immediate and quick fix. Server 2012 R2 PDC with latest updates & desktop clients on windows 10 anniversary. No errors in the event logs which blew my mind... Thanks for the post Rob!

    ReplyDelete
    Replies
    1. Thanks for the confirmation! Your scenario is much like the one we ran into. (Windows Server 2012 R2 as a PDC with Win 10 1607 anniversary clients.) In our case we also had some Windows 7 and Windows 10 Pr-anniversary clients mixed in that were not impacted by this problem at all . . .

      Delete
  4. Wow... works.. Thank you so much

    ReplyDelete
  5. I also just ran into this issue with clients on the network. Turning off the indexing service fixes the problem but this is as huge cost as we need to search the network file. I really hope microsoft fixes this soon!

    ReplyDelete
    Replies
    1. As do we! Not being able to conduct a fast search on network shares from Windows 10 1607 is proving painful for my clients too.

      Delete
    2. Is there some sort of thread we can bump up so microsoft knows this is an issue can provide a fix?

      Delete
    3. The best MS forum thread I've found so far is the one linked in the main post above:
      https://social.technet.microsoft.com/Forums/windows/en-US/b72c763e-d029-4e65-a2dc-885a5aabf643/problem-creatingrenaming-a-folder-on-a-network-share-with-win10-anniversary-update-error?forum=win10itpronetworking

      Feel free to go light their candle!

      Delete
  6. We too are experiencing this issue with a couple of our small clients. I can't believe this issue never came up in their internal testing!

    ReplyDelete
  7. It was driving our accountant crazy when creating new files on the server. Thanks for the post!

    ReplyDelete
  8. Great fix, it has been a headache for our office for the past month or two. Thanks

    ReplyDelete
  9. Thanks Rob and Steve. Like the others this has really been irritating recently, so much that I was remoting onto the server itself whenever I needed to do any heavy folder changes (home network, not work related), either via RDP or via PowerShell command.

    ReplyDelete
  10. Cannot begin to tell you how much this saved me! On my own tiny little network, I couldn't move my files to my personal cloud because of this error. I followed your directions and it worked immediately. Thank you so very much! (A photographer who needs to archive!)

    ReplyDelete
  11. sorry to ask... So just need to disable on the server(share folder) side?

    ReplyDelete
    Replies
    1. That is correct. You can leave the search service running on the client side, just disable it on the server itself.

      Delete
  12. Wow - just had a client reporting this today, I just had to try and create a new folder on one of their network shares (any others worked) and it would do it at least 9 out of 19 tries and disabling the service fixed it immediately - They are Windows 10 1607 with Server 2012R2 Essentials. Interestingly I have quite a few sites running 2012R2 with Win 10 clients so either none of them yet have 1607 (Which I doubt) or there is some other specific combination that triggers this issue. Its possibly that MS have been slow to push 1607 out to domain members preferring standlones and home users to be the guinea pigs and as a result not many of my clients with this combo have 1607 yet???

    ReplyDelete
  13. Cheers Rob! This issue was frustrating me & my users so much! All good now.

    ReplyDelete
  14. I found that if you refresh the explorer window after creating it you can rename it no problems and still leave indexing rnuning.

    ReplyDelete
  15. Super, will try this. Please post in this thread again when MS has fixed it.

    ReplyDelete
    Replies
    1. I will update when this get's fixed and we've had a chance to verify the patch works. So far I've not seen any updates from Microsoft on this issue at all.

      Delete
  16. Great fix... with another downside. This has been driving the office crazy for the last couple of months. Your fix worked great, but we can no longer search through our Contacts list in Outlook. Seems to be isolated to the Contact list, email searching works fine.

    ReplyDelete
    Replies
    1. Just to make sure I am on the same page as you, the recommendation is to disable Windows Search on Server 2012 R2, not on the client workstations. Are you saying that doing so also disabled search in Outlook Contacts? If so, then that is a very odd side effect indeed and should be reported to Microsoft. Might be worth placing a comment with this information on the active thread at technet (linked above in main post).

      Delete
  17. One of my users discovered another workaround. Create the folder on the client desktop and drag it into the file server. Doesn't fix renaming issue. Our search function is heavily used so we decided to keep it on (though I can confirm it worked creating and renaming when it was off).

    ReplyDelete
  18. I have the same issue but do not have a server as such. I have 2 desktops networked to each other via ethernet. Do I disable Windows search on the main desktop, that has the files or the other desktop, that connects to it? Also, does it mean that I will not be able to search any Documents files?

    ReplyDelete
    Replies
    1. I've not tested this scenario, but if it's the same bug, you would disable search on the file sharing computer - i.e. the main desktop that has the files.

      Would be very interested in the results in your case!

      The really bad part, disabling search on any workstation severely limits some core functionality on that desktop: Cortana, Start menu search etc are all likely going to be broken. Libraries might break too, since they require search indexing to be enabled. Really wish Microsoft would fix this bug once and for all.

      Delete
  19. The fix worked for a small business network (about 20 users) using a dedicated Windows 10 Pro box as a file server. This one was driving me nuts - thanks for the post!

    ReplyDelete
  20. Thank you so much for posting this! Here's another instance for you: Most of those updated to 1607 have had this issue, but one person has not - me. I'm on the same network but I have not had these issues. We also have 3 servers here, running 2012R2 but only the one with HyperV employed has this issue along with the 2 network drives from that server. The other 2 do not. I've almost given up on making sense of this whole thing!

    ReplyDelete
  21. Running into the same issue with a fresh W10 1607 install. Central search is a major Windows server selling point. Hope they figure this out soon.

    ReplyDelete
  22. Thank you! Not only does it seem to fix my issue, but transfer speeds also feel better. btw I'm sharing files between two win10pro machines via a homegroup...

    ReplyDelete
  23. Thank you! This fixed the above symptoms for sharing files between two win10pro computers via homegroup... feels quicker as well not randomly freezing...

    ReplyDelete
  24. Yeah, it looks like the main culprit is Win10 1607, no matter what it's a server or client... I have a VMWare client running Win10 1607 and the main host is also Win10 1607. Got this error and tried to search on Google and found your blog and the thread on TechNet...

    ReplyDelete
  25. Thank you for the workaround! This problem is again showing that Microsoft has completely lost control of their OS. They don't seem to be testing even most important OS functions and they don't even feel the need to comment on well known problems. Everything is a big mess and this OS is definitely not suitable for any kind of business anymore...

    ReplyDelete
  26. I've noticed this error on my windows 10 machine. However, I don't have any "network" drives but only local drives that are mapped locations. So, for example "w:" refers to a location on my machine that is c:\users\jason\downloads.
    If I'm in windows explorer and then I add a folder in w: it can error.
    However, I'm in windows explorer and then I add a folder in c:\users\jason\downloads it does not error.

    Also, if I use FreeCommander instead of windows explorer, there's no error.

    So, to me, this seems like a bug in windows explorer.

    ReplyDelete
  27. Thanks for the Jan 9, 2017 update. I am eagerly awaiting this update. I hope that they identify whether the problem lies in Windows client access issues or in the Windows Search running on the server. Happy New Year!

    ReplyDelete
  28. Not sure if it's relevant or not, but I did not have this issue before the anniversary update although most of my office mates were experiencing problems. The main difference that I know of is that I disabled Cortana immediately after updating to Win10, whereas nearly everyone else left it running.

    Now that I'm forced to leave Cortana alone, it's a 10-15 minute process to try and rename a folder. I rename a file and hit enter, then everything freezes. When the error message finally pops up after about 5 minutes I lose access to server files (except for 1 specific folder ??? ) for anywhere from 5-10 minutes on average (I've tried timing it and it is very inconsistent, with 4 minutes being the fastest and 18 being the slowest).

    Whenever I regain access to the server file system, the file shows the new name... so it works, but it's a major PITA. Hopefully they fix this soon.

    ReplyDelete
    Replies
    1. We found the same thing, but with the current 1607 builds it's become very difficult to disable Cortana unless you use the Enterprise license versus the Pro license for small businesses.

      Delete
  29. 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.

    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.

    ReplyDelete
    Replies
    1. Now this is very interesting! I'm going to test this out this week. Thanks for the insight!

      Delete
  30. SoCal Church IT Guy fix did not work in my situation. Does anyone else have any ideas on how to correct Microsoft's big issue?

    ReplyDelete
    Replies
    1. I was able to get it to work on my small test bed, but this morning I tried it on a production network and the result was disappointing. Same pause and error. Now trying to analyze the differences to see if I can find more clues.

      Delete
  31. The 3rd solution works only up to the second level subfolder. Anything deeper is coming with the same issue.

    ReplyDelete
  32. I saw this on a few systems. A fix that worked for me on the Windows 10 systems was to click Start, Settings, Apps and Features, find the App Connector app, click it, then go into advance, then click reset. This fixed two Win 10 laptops that were taking 1-2 mins when trying to create a folder on a Windows Server 2012 R2 Essentials server.

    ReplyDelete
  33. Definitely came in handy today. A brand new W10 fully patched could create a folder on a network share with no issue. But when I would try to delete the folder, it took upwards of 60-90 seconds. On a Windows 7 PC on the same network using the same account, the folder is deleted instantly. Disabling and stopping the service fixed the issue.

    ReplyDelete
  34. I'm curious why it is taking so long to fix this on a technical level. I'm curious as to what things the fix might break that has Microsoft taking so long, or is it simply that it's not as important to focus on this as it is other aspects of windows.

    ReplyDelete
  35. I have this problem copying over large files from my NAS (local networked drive). In your example, I don't know what you mean by "FQDN". And it's not hooked up to a "domain.org". May you please clarify what to do there? Thanks for your time!

    ReplyDelete
    Replies
    1. We were discussing the scenario where the client workstation is joined to a Domain Controller. FQDN is an abbreviation for "Fully Qualified Domain Name" which is a "long" or "full" name of the local network name that includes the local domain name plus the machine name. It's all wrapped into a system we call Active Directory. In your case none of that applies since you are using a peer to peer network topology instead of one where you have a central network authority.

      Delete
    2. Ah. Thanks for clarifying! Continuing to wait on Microsoft then. :-/

      Delete
  36. I have had this same issue on Server 2016, just installed the latest update and now renaming of folders takes around 2 - 3 seconds no mention in the write up that it should have fixed it mind.
    https://support.microsoft.com/en-gb/help/4009938/january-10-2017-kb3213986-os-build-14393-693
    Regards,
    Dave

    ReplyDelete
  37. Awesome! I've suffered this issue with Win10 at a couple of sites and your solution using the cumulative update has resolved them!

    ReplyDelete

Comments are welcome but moderated to prevent spam links. I usually check them at least once a day in the evenings - so please be patient with me if your comment does not appear quickly.

Thank you.