none
Problem creating/renaming a folder on a network share with Win10 Anniversary Update (Error 0x8007003B)

    Question

  • I am reporting a problem that I can consistently reproduce with the early release of the Anniversary Update (1607) of Windows 10.

    I can duplicate the error with any type of Windows 10-1607 install (virtual machine or physical, with different motherboard/NIC manufacturers), joined to a Domain or not, with at least two different physical servers, each running Windows Server 2012 R2 Essentials in a virtualized environment.  The problem does *not* occur with Windows 10-1511 nor Windows 8.1 as the client OS.

    Nature of problem:  When I create a new folder on a share (e.g. \\contososerver\Company) that is hosted on Windows Server 2012 R2 running on a VM (in my situation hosted by Windows Server 2012 R2), File Explorer hangs for about 30 seconds then pops up a message that reads "An unexpected error is keeping you from renaming the folder [...] Error 0x8007003B: An unexpected network error occurred".  The error also occurs when I attempt to rename a folder.  After dismissing the error message, I am then able to rename the folder as desired.  Note that any network file transfer traffic (which happens be running in the background) is stalled until the operation times out (after 30 seconds or so).

    Please fix this issue.  Thank you.

    Saturday, August 06, 2016 1:38 AM

All replies

  • I can confirm this bug.

    Physical PC with Win 10 x64 joined to Domain.

    After Update from 1511 to 1607 the same behavior with Windows 2012 R2 Server and mapped network shares.

    When i rollback the Client to 1511 the bug disappear.

    Best regards

    Saturday, August 06, 2016 5:52 AM
  • Hello there!
    I've this issue too. :(

    If I create a folder on my Windows Server 2012 R2 Essentials and leave the
    default name "Neuer Ordner" it works probably...
    But if I try to rename the folder I get: Error 0x8007003B: An unexpected network error occurred

    The same happens if I try to rename the folder directly after I create them.

    A second error happen if I try to delete a Folder:
    Error 0x80004005: Unknown error

    After I retry this action it works fine...

    If I get these errors my Outlook stops to work too!
    My PST files are saved to a networkshare and I get the following messages:

    ID 139: {Fehler beim verzögerten Schreibvorgang} Nicht alle Daten für die Datei "\ToWa\Outlook\~xxxx.pst.tmp" konnten gespeichert werden. Daten gingen verloren. Mögliche Ursache könnten Netzwerkkonnektivitätsprobleme sein. Versuchen Sie, die Datei woanders zu speichern.

    ID 26: Anwendungspopup: Windows - Fehler beim verzögerten Schreibvorgang: Exception Processing Message 0xc000a080 Parameters 0x7ff9103b1d28 0x7ff9103b1d28 0x7ff9103b1d28 0x7ff9103b1d28

    Different systems with Realtek NIC and Intel NIC and the same happens with an Microsoft Surface 3 Pro. :(

    I can't confirm this bug if I try to rename folders on my Synology NAS!

    Saturday, August 06, 2016 7:23 PM
  • I do not get this from 14393 renaming files on Windows Server 2012 R2 Standard, is this related to Windows Server 2012 R2 Essentials?

    Also can rename files on a share on the Linux Mint 17.3 machine, so not sure what the differences here are.

    Saturday, August 06, 2016 9:19 PM
  • No, it is not related to 2012 R2 Essentials. 2012 R2 Standard is also affected.
    Sunday, August 07, 2016 6:31 AM
  • This does not appear to affect all Windows 10 1607 to all Server 2012R2 (as it does not affect me in the my test environment)

    So what other software is running? What Anti-Virus \ security software?

    What is the IP setup? IPv4 and IPv6?

    What does from an Admin PowerShell prompt 'Get-SmbConnection' show?

    Sunday, August 07, 2016 3:17 PM
  • Hey All,

    Am having same problem on two networks. Both networks all Win10-1607 PC's. The "fileserver" on network 1 is a simple Win10-1607 and the other is Win10-1511.

    I have tried everything I can think of that it might be - turned lots of things on and off - can't find the cause of the problem.

    I have a third network - everything on Win 10-1511 but not game to update because of this issue.

    Hardware is different on all the PC's and file servers - some generic, some dells, HP's compaq's.

    I have not tried a clean install of the anniversary update to see if prob still persists.

    All PC's have Office 365 loaded. Not the file server of course.

    Happens on IP or UNC. Mapped or unmapped. Is all IPv4.

    Hoping someone can help for sure.

    Thanks guys.

    Monday, August 08, 2016 7:12 AM
  • So what have the PC's got in common? I do not get this on a standard or upgraded 1607 with little other software.

    What software you turned off to try? What anti-virus is installed?

    Monday, August 08, 2016 7:08 PM
  • Hi Mr Happy,

    Thanks for getting back to me.

    No antivirus installed on the PC's. They actually don't have any software in common. I first mentioned they all have office 365 - but this is not true. Some of them don't.

    Also I mentioned I have 3 networks and have upgraded the PC's on two of them but have not tried the 3rd network. I just tried doing a fresh install on a test PC (A dell vostro) that had not been on the 3rd network with Windows 10-1607 + let it download all the updates. No other modifications at all. I browsed to a local share that all the other Win10-1511 machines browse to, created a folder - same issue.

    All the things I tried involve turning off different network protocols, firewalls on and off, windows defender on and off, many other minor settings but none of them worked.

    The only thing these three networks have in common is they go through a PF Sense linux box for the internet. And have all had been upgraded or fresh install using the same downloaded image from microsoft. Other than that, all the hardware is totally different.

    Thanks again.

    Tuesday, August 09, 2016 4:05 AM
  • I think something has changed between 1511 and 1607  regarding SMB 3 connections.

    I did following test. Setup a new VM with Win 10 Pro x64 (1607) and no further Software.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 3.0.2. Result: Issues like described

    Next, disable SMB 2/3 with (https://support.microsoft.com/en-us/kb/2696547):

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
    sc.exe config mrxsmb20 start= disabled

    and restart.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 1.5 Result: No issues

    I think, it's time for Microsoft to investigate the issues!

    • Proposed as answer by D.Mos Monday, September 05, 2016 9:36 AM
    Tuesday, August 09, 2016 6:55 AM
  • Just adding in that I see this issue as well. Win 10 1607 fails the same exact way and the other Win 10 machines on my network that are not 1607 can create the folder with no issue. Server is 2012R2 Essentials
    Tuesday, August 09, 2016 4:57 PM
  • Adding myself to the issue.  Upgraded and fresh installs of 1607 machines/VMs connecting to 2012R2 and even to a Win 8.1 network shares. EDIT: not sure if it matters, the Win 8.1 share is on a VM on a Hyper-V Server 2012 R2 server.

    Still present after the 14393.51 update today.


    • Edited by Pr0m3th3us Tuesday, August 09, 2016 6:02 PM
    Tuesday, August 09, 2016 5:58 PM
  • Still present after the 14393.51 update today.


    I can confirm this!

    Still present and only by renaming @2012 R2 with Windows 10 1607!
    Renaming on Server 2012 non R2 is working fine. :(

    Tuesday, August 09, 2016 6:05 PM
  • Hello Mr O 76,

    Thanks for the response. So setup a pfSense 2.3.2 and put my main DC, 2012R2 and 1607 Enterprise client on a LAN interface. Still can rename and create with new names folders on a share on the 2012R2 Standard server, hmm. For info they are all guests on Hyper-V, host is Server 2016 TP5 (Hyper-V Core), so the pfSense and servers and client all connected via a Hyper-V switch. It is a pure test environment, little config and extra software.

    So pfSense, firewalling the servers? or separating the servers and clients from the WAN like my test? or something else?

    If you see \ saw the reply from R.Rechner my dialect is 3.0.2, so still wondering what the difference is with my test setup and the many people seeing issues here.

    Regards

    -Mr Happy-


    • Edited by -Mr Happy- Tuesday, August 09, 2016 9:24 PM
    Tuesday, August 09, 2016 9:23 PM
  • Hi Mr Happy,

    Thanks for getting back to me and trying the pfsense.

    Yeah I don't think it has anything to do with the situation. The firewall is literally just providing DHCP and Internet Firewall - nothing else on these networks.

    R.Rechner - interesting indeed. I will try this today. Also I am currently creating a fresh USB install as well to see if any changes - probably not. I will also test just a straight crossover cable from a win10 to a win10 machine to bypass the network and see if any changes.

    The only other thing that I have done on each machine I have setup from the beginning is when installing a Win10 machine, I uncheck ALL of the things at the beginning - about privacy, location, feedback, updates etc etc. Other than that I let it download the updates on the initial install, reboot. That is it. I might try and leave all those options checked as well next time I install and see.

    Let you know soon.

    Tuesday, August 09, 2016 10:14 PM
  • Hi Mr Happy,

    Here is the latest of what I did:
    1. Downloaded the latest Media Creator for Win10 and installed on USB3.0 drive
    NOTE: Another common thing is downloading in English UK for both 32bit and 64bit. Install is English Australia 64bit.
    2. Installed on Dell PC - clean install HDD wiped prior
    3. This time I used express settings
    4. This time before doing updates, I browsed the to network share - same issue
    5. Performed updates and restart a couple of times - same issue when I browse
    6. I connected to another Win10-1607 with a network share (that I HAD NOT browsed to prior to the following) with a crossover cable and different IP range.
    7. This time when connecting to the network share - all is well
    8. Put network back the way it was - browse to the same network share that was working - all still works!
    9. Browse to the fileserver that I was having dramas with - still does not work. Browse to OTHER network shares on the same fileserver - some work properly and some do not.
    10. Try the post from R.Rechner and reset - does not work for me unfortunately.
    11. Restore the test PC back to factory fresh.
    12. Try setting IP to static and testing all shares - same results.
    13. Look at permissions and security on all the shares on all the networks - no correlation there.
    14. Remove the share all together and reapply- same issue.
    15. Create a new folder on fileserver and share as a test - this works ok
    16. Create a new folder, copy contents of folder of the share I am having dramas with, remove old folder, then share this with same name as problem child share name - same ongoing problem
    17. Copy the contents from the problem child share into the "test" folder then tried again - now instead of this folder working ok, is now not working ok
    18. Delete contents of folder and try creating more folder - still not ok
    19. Created another folder called "test2" and shared it. Was able to create 6 folder before it bombed out on the 7th.

    Am at an end now. I can't see any correlation between the machines and setup. All is pretty basic. Points 6 to 9 said it worked on this particular machine. This machine had Win10-1507 and had been upgraded to Win10-1607 the same as all my other machines. There is one difference - it has the RDPWrapper program installed. I tried to install this on one of my other problem machines - it helped out - i was able to create about 8 folders each time before it bombed out again. Interesting.

    Thanks guys.
    Wednesday, August 10, 2016 4:13 AM
  • Hello again Mr O 76,

    Well interesting reading you post, about as much sense as I am making of this.

    I cannot get this to a 2012R2 server I have.

    I can get this error, right click new folder as part of that rename it, hangs, errors, to a Windows 8.1 share.

    I have had Explorer Windows open to both shares, whilst failing on Windows 8.1 same client and user ok to 2012R2. Used switched user, 1st user error to 8.1, second user ok, back to 1st user now ok.

    Checked both using SMB 3.0.2.

    So are MS secretly aware of this issue? Are we awaiting a magical Windows update to put all this behind us?


    • Edited by -Mr Happy- Wednesday, August 10, 2016 8:46 PM
    Wednesday, August 10, 2016 8:45 PM
  • I am also getting this error.  I get it trying to create a folder on my Windows 2012 (non-R2) Server Essentials and also between to upgraded Windows 10 systems.  I also get the error from a Win 10 AU system while creating a folder on a Win 10 system that has not been upgraded.
    Thursday, August 11, 2016 12:49 PM
  • We are having the same issue, tested and replicated in the office as well as virtual test environment. Did anyone have any luck resolving it, other than disabiling SMBv2/3? Or is it the only workaround at the moment?
    Friday, August 12, 2016 10:45 AM
  • We are also having the same issue.  Server is 2012 Essentials (not R2).  We have 3 Dell workstations and an HP laptop connected to the server via domain.  We've upgraded the 3 workstations to 1607 but have not had time to do the laptop. 

    All 3 workstations have this issue, the laptop does not.  The Anniversary update was performed over the last 2 days.  Two of the workstations and the laptop were originally upgraded to Windows 10 from Windows 7 a week or two before the free upgrade deadline.  The 3rd WS was a fresh install of Windows 10 on the last day we could upgrade.  This computer has minimal programs installed (AutoCAD LT 2012, Office 2007 SB and a printer driver for a Brother label printer).  Virus protection is Windows Defender on this WS as well.  

    Looks like we will need to roll back until this is corrected.

    Friday, August 12, 2016 6:44 PM
  • We have been having this issue exactly (among MANY others) since updating to 1607 on our domain running 2012 R2 with Essentials Experience.

    One extra thing we noticed was this ONLY happens when trying to create a folder while doing a "save" or save as" from another program.  If you use Windows Explorer there is never a problem.  Saving from Microsoft Dynamics GP 2015 or from Outlook 2016 can always recreate the problem.  This is killing my users productivity (and also my reputation).  Help us MS you are our only hope!!!

    Friday, August 12, 2016 8:22 PM
  • Windows 10 build: version 1607 OS build 14393.51. single domain controller running windows server 2012 (all updates installed).

    on each network share if I create a new folder and then rename it everything freezes for about 20 seconds after which I am getting:

    An unexpected error is keeping you from renaming the folder. If you continue to receive this error, you can use the error code to search for help with this problem. Error 0x8007003B: An unexpected network error occurred.

    during the 30 second wait no programs open. if I open internet explorer nothing happens until the error appears after which all windows open.

    I need to right click refresh on the folder to check if the name has changed or not. After this I can rename the folder successfully.

    this only started happening after the update to 1607.

    kindly issue a hot fix or patch for this issue as soon as possible.


    Paul.

    Saturday, August 13, 2016 11:35 PM
  • Same issue here as well. Windows 10 Pro 1607 connecting to Windows Server 2012 R2 shares. Using a domain. Attempts to create folders often hang for about 30 sec with 0x8007003B errors and usually take another 30 sec on the retry after failure.

    I can't definitively tie this to the 1607 upgrade as I don't create folders every day, but the timeframe roughly aligns - it has only been happening for about a couple of weeks and I have no other network errors.

    I'm not using any firewalls or antivirus other than what's included in Windows, and haven't changed the configuration of these things recently.

    Both server and client are on physical PCs. No hardware or other major configuration changes prior to the problem occurring (other than upgrading the client to 1607).

    I've also just confirmed that the issue occurs on my laptop - also upgraded to 1607 and connected to the same domain.



    • Edited by mattbg Sunday, August 14, 2016 9:44 PM
    Sunday, August 14, 2016 9:33 PM
  • Well I do get this issue in my test environment to Windows 8, but not 2012R2 which is odd, and as my post above this I find odd as it does work at times if I rename when creating some folders, then after awhile it appear to work.

    Anyhow did look at a packet trace for this and interesting to me (but not helpful to us perhaps) that when this fails Windows 10 1607 seems not send the close response for the New folder where a working one does.

    Above is working, from a time for me when 1607 worked. After Win10 sends the SMB rename the WIN8 sends a SMB Response.

    Above 1607 fails to rename the New folder. WIN8 ACKnowleges the TCP packet but does not action it for 90 seconds approx. in my tests. The fail is missing the specific Close Request File: New folder.

    So anybody got a support ticket credit for Microsoft or $500 they want to gamble to log a support ticket with Microsoft about this?


    • Edited by -Mr Happy- Sunday, August 14, 2016 10:14 PM
    Sunday, August 14, 2016 10:01 PM
  • Well I do get this issue in my test environment to Windows 8, but not 2012R2 which is odd, and as my post above this I find odd as it does work at times if I rename when creating some folders, then after awhile it appear to work.

    I also see it work intermittently as well, but it usually doesn't. While I was trying to narrow down the cause earlier today, I had it work correctly about 2 out of 10 times.

    One of the things I tried was to reindex the affected folders on the server, as they were part of a library on my client PC (which requires the folders to be indexed on the server). The first try creating a new folder in each of two folders that have this issue after doing that seemed to work, but then subsequently didn't. Not sure it was related at all - could have been a coincidence.

    Sunday, August 14, 2016 10:30 PM
  • Hey all,

    Possible solution - maybe if you can give it a go.

    Just to recap - I have 3 networks. This is happening on all three. I have a Win10 Pro on each network that serves as a basic fileserver. I upgraded 2 of the Win10's to 1607.1 remains 1511. No AV and No Firewall. All the client machines map drives OR just straight to the shares. Shares are a combination of open to EVERYONE or some specific users.

    When I setup a fileserver I always turn off the "Windows Search" service - no need to have it on. However it looks like an update went through at some point and turned it back on. I am pretty sure that the Anniversary 1607 update turns it back on as well.

    So I turned the service off again - and all appears to be working ok at this stage. I have not touched the client machines - they all still have "Windows Search" service still on.

    It is almost like when you create a folder, the search on the server grabs that new folder straight away and starts indexing it or something. If you need "Windows Search" on the server - maybe there is a way to delay the indexing or something. I don't know how it works.

    Give it a go and see if works for you.

    If it works for you - you owe me a beer. :)

    Mr O 76

    • Proposed as answer by Mr O 76 Monday, August 15, 2016 5:58 AM
    Monday, August 15, 2016 12:11 AM
  • Hey Mr O 76,

    Turning off file indexing solved the problem. (5 pc network, Win 10 all running 1607)

    Thank you very much!

    Where can I send your beer? :)

    Monday, August 15, 2016 7:37 AM
  • Hey csabago,

    Great news! What a painful problem.

    Is odd - I have the 3 fileservers with a mixture of Win10 1511 and 1607 clients. It only affects the 1607 clients. It doesn't really make sense turning off the Windows Search function on the fileservers affects the 1607 clients.

    Maybe someone smart at microsoft can answer that one!

    Am interested to hear if this fixes issues on the 2012 server networks.

    Mr O 76

    Monday, August 15, 2016 8:21 AM
  • Is odd - I have the 3 fileservers with a mixture of Win10 1511 and 1607 clients. It only affects the 1607 clients. It doesn't really make sense turning off the Windows Search function on the fileservers affects the 1607 clients

    Also, if these shares are part of a library on the client then they need to be indexed on the server... so it's more of a workaround than a solution.
    Monday, August 15, 2016 10:12 AM
  • Mr O 76 - you nailed it!

    You definitely get my vote for at least a *temporary workaround/solution* - it did the trick on 2 unrelated servers!

    Monday, August 15, 2016 10:03 PM
  • Hey Mr O 76,

    Well you get a plus vote, I will drink a beer to you. But this has to be considered a work-around so if marked as the answer in the thread then it still awaits a fix from MS imho as a bug in Windows 10 1607. Also the Windows Search Service does turn itself back on for me in Windows 8 'server' test.

    Regards

    -Mr Happy-

    • Edited by -Mr Happy- Monday, August 15, 2016 10:38 PM
    Monday, August 15, 2016 10:37 PM
  • I can also confirm, that problem only exists on clients with 1607.
    Removing the shared folders from "Indexed locations" on server side also helps as workaround.

    But then I have to learn that Windows Mediastreaming runs only on indexed folders :(
    So hopefully Microsoft will offer a fix for this problem asap.

    Tuesday, August 16, 2016 3:32 PM
  • Same problem with a server after install win 10 anniversary update.

    4 client with the same win 10 anniversary update that use a shared folder on the server have the same problem error 0x8007003b, after 50 60 second i can rename the folder and then no problem.


    Thursday, August 18, 2016 10:24 AM
  • I'm also having this issue on 8 workstations (W10 - 14393.51) and Server 2012 R2 Essentials.   I removed the shared folders from being index locations as mentioned above and can report it worked.  Thanks Mr O 76 for that temporary workaround.

    -Robert

    Thursday, August 18, 2016 5:26 PM
  • This worked for me! Turned off Windows Search srv on the 2012R2Ess server, and issue is gone! nothing changed on the client. Funny thing is, only one (of 7) WIn10 had this issue, the only diff between that one and the others is that it is a brand new PC (Dell) came with w10 installed, while the other 6 PCs were upgraded from Win7 to Win10.

    TY!!!

    Friday, August 19, 2016 3:06 AM
  • Hey Mr O 76,

    Turning off file indexing solved the problem. (5 pc network, Win 10 all running 1607)

    Thank you very much!

    Where can I send your beer? :)

    Turning off indexing has not solved the problem here.

    Same as everyone else. We have 20+ server network, 288 clients. About 60 Win10 1511, about 8 are 1607. The 1607's all exhibit this issue. I've since discovered this happens regardless of how the machine is built (7,8,8.1 or 1511 to 1607 upgrade, as well as 1607 fresh install.)

    I've also tried the Windows Defender disable, The SMBv2/v3 disable (which of course stops all SMB connections to 2008/2012 servers due to authentication failures/encryption)

    So, every which I can manipulate 1607 so far fails to resolve this show-stopping bug.

    Incidentally, the bug continues with build 14901 & 14905 which I have running on various test VMs.

    I don't know how we missed this bug before a minor 1607 roll-out - but we did. Roll-back to 1511 resolves it everytime.

    Kudos++ to MS for excellent roll-back process. Kudos-- for missing such a glaring and critical issue!

    Friday, August 19, 2016 8:19 AM
  • I didn't solve the problem, but an easy workaround was to install a 3rd party file manager.  I used something called Free Commander.  I'm even starting to like it better than the Microsoft version.  But for sure it'll put you back in business, and allow you to comfortably fall in line with the tyranny of the MS upgrade structure.  I manage a small network of 9 computers, and even when MS fixes the bug, I may not look back!
    Saturday, August 20, 2016 12:41 AM
  • Same problem here (9 PCs, no domain) after upgrading to 1607 education. Disabling indexing service on server works - but is a bad solution since search gets really slow.
    • Edited by Stefan1610 Sunday, August 21, 2016 1:23 PM
    Sunday, August 21, 2016 1:22 PM
  • Add me to the list. Microsoft Surface Book which came with Win 10 out of the box. Updated through normal channels to 1511 and had no issues until yesterday after "upgrading" (and I use that term loosely) to 1607.

    Computer is joined to a Server 2012R2 Essentials Domain. As others have stated I am seeing this issue when using a "save as" dialog in a 3rd party program. I do not seem to be affected when simply using explorer. Right-Click in save as dialog box, select new folder, enter name for new folder, everything hangs for upwards of 30 seconds until I receive the 0x8007003B error message. Right click in the dialog box again and hit refresh and most (but not all) of the time the folder was actually renamed.

    Thank you to Mr O 76..... Stop the Windows Search Service on the 2012R2 box and the issue vanishes. Too early to tell if doing this affects anything else but I'm sure it does.

    Now ... wait for an official fix or rollback ... that is the question.

    Tuesday, August 23, 2016 1:00 AM
  • New cumulative update to .82 today!

    Network issue still continued... :/

    I think microsoft has no business partner or they all work with Windows XP and 7. ;D

    Tuesday, August 23, 2016 6:40 PM
  • "An engineer was able to reproduce the issue and a bug has been created to track it. Thanks for raising this to our attention, Susan!"

    Trying to get an eta of a fix, hang loose.

    Wednesday, August 24, 2016 6:30 AM
  • hi

    just for info , have installed the 14393.82 patch that is now generally available and the problem persists

    it also affects insider latest build  14905.1000

    thanks

    Wednesday, August 24, 2016 9:07 AM
  • Just jumping in to confirm this also is occurring for one of our clients.  Removing server volume from search indexing solved it for now.

    Any idea how we will get notified if a fix is released?

    Thanks to all who posted here.

    Friday, August 26, 2016 4:08 PM
  • You can add me to the list. I have a couple of machines on 1607 and some that are not. Only happens on the 1607 machines. Will use the "disable index" as workaround.
    Friday, August 26, 2016 5:48 PM
  • Windows 10 1607 is the most unstable Windows release I have ever seen. And I've been using Windows since the 3.1 days. This is far worse than Windows Vista when it first came out. Some of these bugs are so blatant and severe that this build feels like an Alpha release to me. I have nothing against the Windows insider program, in fact I think it's a great idea. But clearly Microsoft needs to be doing more of their own internal testing. If they are going to release major builds of Windows 10 every year like this, they had better clean up their act, otherwise Windows isn't going to around very much longer.
    Saturday, August 27, 2016 3:25 PM
  • Changelog to build 14393.103 (release preview ring) lists improvements for "file server" among many others:

    - Improved reliability of the Windows Ink Workspace, Microsoft Edge, File Server, Windows kernel, Microsoft Component Object Model (COM), Cluster Health Service, Hyper-V, Multi-Factor Authentication (MFA), NTFS file system, PowerShell, Internet Explorer, facial recognition, graphics, Microsoft Store and Windows Shell.

    Has anybody tested if this will solve our problem?

    Monday, August 29, 2016 7:42 AM
  • We are experiencing almost the same issues on those client computers that were updated to Anniversay Update. We are running Windows server 2012 Essentials. We are also having a huge delay when trying to create new folders on a server file share. Usually, one or 2 folders can be created normally. After that a delay of about 90+ seconds per new folder. However, there is no error message, just the delay, on one of the computers. The other computer qets both the delay and error message. 

    By turning off indexing, the delay goes away. But, we have 100 000+ files and business apps that rely and use the search index, so that is not an option. Finding a file with indexing turned off takes minutes.

    Please Microsoft, if you care about your business customers at all, fix this fast. If you need any more details I am more than happy to assist. I have  submitted the bug trough windows 10 feedback hub, is there someplace else I can create a support case or submit a real bug report? The feedback hub is bound to a specific region and not U.S., so I don't know if anyone actually reads the "feedback".

    Here is the link to the forum thread I initally created.


    • Edited by Fredrik70 Monday, August 29, 2016 12:09 PM
    Monday, August 29, 2016 12:06 PM
  • Has anybody tested if this will solve our problem?

    Yes!
    That's it...

    I've downloaded Build 103 from here:

    • x64: http://download.windowsupdate.com/d/msdownload/update/software/crup/2016/08/windows10.0-kb3176938-x64_ab965398b478cf127bcaa233eec090a34ec196f4.cab
    • x86: http://download.windowsupdate.com/d/msdownload/update/software/crup/2016/08/windows10.0-kb3176938-x86_fcce9f1cfc3c8a17af535796f49c44e66baaace8.cab

    Install from cab-file with:
    DISM.exe /Online /Add-Package /PackagePath:"path_to_file"

    Edit:
    hmm simply the same after the patch. :(
    But sometimes it work very well and a few seconds later I get the same network error again.
    ....Microsoft....

    • Edited by derToWa Monday, August 29, 2016 4:04 PM
    Monday, August 29, 2016 3:55 PM
  • Add me to the list, seeing this error as well. Server 2012 STRD R2, 250 clients, about 20 on 1607, all reporting the same issue, although intermittent in some cases.  What's the word MS ?
    • Edited by arsix Tuesday, August 30, 2016 5:46 PM
    Tuesday, August 30, 2016 5:44 PM
  • Put me on the list as well.  We have 3 Windows 10 clients, two 1511 and one 1607, and all have the problem with Windows Server 2012 standard.  We have around 40 clients total, mostly Win7 Pro.   Turning the Search service off on the server makes the problem go away, but then we are essentially dead for doing any quick searches on our network files.

    Has anyone found any patches for this yet?  Has it been reported to Microsoft??

    Tuesday, August 30, 2016 8:06 PM
  • Same issue here.  14 systems, 7 of them on 14393.82 and the rest on 10586.545.  Connected to Server 2012 Essentials.  No issue with version 1511.  Turning off indexing makes searching too slow so pretty much trading one problem for another. 

    Hoping 14393.105 addresses the issue.

    Wednesday, August 31, 2016 3:01 AM
  • just downloaded 14393.105 from release preview. Same issue, makes no difference. I have the same problem as everyone here when trying to rename a folder. 10586.x does not have the issue on our network.
    Wednesday, August 31, 2016 6:14 PM
  • Susan, have you got any response to your eta request yet? 
    Thursday, September 01, 2016 8:26 AM
  • We have a  very similar problem:

    Server
    Windows Server 2012 R2 with Windows Search Service (Indexing)

    Client:
    Windows 10 Pro x64 14393.105 (KB3176938)

    When Windows Search Service is running and i try to create a new folder on a network share or mounted network drive and give that folder a name other than "new folder" the explorer stops responding for about 30sec. After that the folder was created with the given name - no error message.

    Sometimes renaming a folder causes the same problem.

    No problems with 10586.xxx

    Turning Windows Search Service off solves the problem, but this is not an acceptable situation for our company.

    Microsoft please fix this asap!


    • Edited by DB2105 Thursday, September 01, 2016 10:06 AM
    Thursday, September 01, 2016 10:04 AM
  • I also have this problem with Windows Server 2012 R2 Essentials after I upgraded my Win 10 machine.

    I checked my Search Indexing settings but the share isn't in the indexing list. So the suggested workaround doesn't work for me.

    Friday, September 02, 2016 8:25 PM
  • Same problem here - upgraded my main PC to the anniversary update yesterday and I get the same error trying to rename folders on a Windows 2012 Standard server. Not good! Fortunately, I use Macrium Reflect to image my PC before any major installs so can roll back.
    Saturday, September 03, 2016 9:56 AM
  • Also very surprised something so basic got through the Insider program???
    Saturday, September 03, 2016 10:04 AM
  • Same problem here: workgroup of 1 2012R2 Standard Server and 3 Windows 10 Pro clients

    Dario Palermo

    Saturday, September 03, 2016 8:56 PM
  • Got the same problem here, is there any new solution out there?
    Monday, September 05, 2016 8:57 AM
  • I think something has changed between 1511 and 1607  regarding SMB 3 connections.

    I did following test. Setup a new VM with Win 10 Pro x64 (1607) and no further Software.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 3.0.2. Result: Issues like described

    Next, disable SMB 2/3 with

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
    sc.exe config mrxsmb20 start= disabled

    and restart.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 1.5 Result: No issues

    I think, it's time for Microsoft to investigate the issues!

    Thank´s that helps, now waiting for an MS-Update
    Monday, September 05, 2016 9:38 AM
  • Same issue here an all Win10 clients from 10.0.14393.0 -> 10.0.14393.103

    File server is Win Server 2012 R2

    Monday, September 05, 2016 9:52 AM
  • I think something has changed between 1511 and 1607  regarding SMB 3 connections.

    I did following test. Setup a new VM with Win 10 Pro x64 (1607) and no further Software.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 3.0.2. Result: Issues like described

    Next, disable SMB 2/3 with

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
    sc.exe config mrxsmb20 start= disabled

    and restart.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 1.5 Result: No issues

    I think, it's time for Microsoft to investigate the issues!

    Thank´s that helps, now waiting for an MS-Update
    I also used this solution but the situation is not very different, sometimes renaming new folder works sometimes not.
    Monday, September 05, 2016 10:49 AM
  • We do test it on tow Win 10 Pro (1607) with Win 2012R2 as Fileserver, it works after client restart. It´s not really a solution just an temporal workaround while waiting for an fix.

    To revert on SMB 2/3

    open Command as administrator

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
    sc.exe config mrxsmb20 start= auto

    Greeting

    Tuesday, September 06, 2016 6:53 AM
  • Susan,

    Have you heard anything back on the bug that was reported to Microsoft about the network folder creation error (Error 0x8007003B) for Windows 10 clients?

    I have about Googled this issue out with trying to find a solution.

    Thanks!

    Wednesday, September 07, 2016 4:59 PM
  • Add me in as well.  I have this issue in multiple locations.  Turning off indexing isn't an option.
    Wednesday, September 07, 2016 6:10 PM
  • this worked for me.  stop the windows search service on the server the share resides.

    https://networkdefend.blogspot.com/2016/09/fix-windows-10-error-0x8007003b-when.html

    Thursday, September 08, 2016 8:20 PM
  • I tried to add a rule to using Search API 3 to ignore folder "New folder"

    Add-Type -path "Microsoft.Search.Interop.dll"
    $sm = New-Object Microsoft.Search.Interop.CSearchManagerClass
    $catalog = $sm.GetCatalog("SystemIndex");
    $crawlman = $catalog.GetCrawlScopeManager();
    $url="file:///*\\New folder\\";
    echo $url
    #$crawlman.RemoveScopeRule($url);
    $res=$crawlman.AddUserScopeRule($url,$true,$true,$null);
    $crawlman.SaveAll();

    It is not running in Powershell.

    Somebody may correct this script.

    Friday, September 09, 2016 1:41 PM
  • I can also confirm this problem between Windows 10 Pro 1607 on the server and client side with fresh installs on both ends.

    Get-SMBConnection reports SMB dialect 3.1.1 on the connections. I also tried disabling SMB2/3 and reverting to SMB1 (1.5) but with mixed results (not fixed) explorer was still hanging. Analysing the wait chain on explorer gave me "...explorer is waiting for network I/O"

    Also tried disabling ALL explorer extensions using ShellExView. Still didn't work.

    Disabling the Windows Search Service on the Server side DID fix the issue for now until MS can release a patch...

    I can't believe MS is this far behind the ball on what is a critical component of Windows networking. WTF!!

    Well at least MS made sure I can play Candy Crush on my clients computers until they fix this issue(s)... :-(

    I was going crazy (and my clients were going crazy) trying to get this fixed. Thank to Mr O 76 for this temporary work-around.

    Sunday, September 11, 2016 7:03 AM
  • I suggested a Windows Search Scope change in my post, I am not that expert, but sure somebody can correct my script above. If you know somebody that can fix my script then please post the solution here.

    Add-Type -path "Microsoft.Search.Interop.dll"
    $sm = New-Object Microsoft.Search.Interop.CSearchManagerClass
    $catalog = $sm.GetCatalog("SystemIndex");
    $crawlman = $catalog.GetCrawlScopeManager();
    $url="file:///*\\New folder\\";
    echo $url
    #$crawlman.RemoveScopeRule($url);
    $res=$crawlman.AddUserScopeRule($url,$true,$true,$null);
    $crawlman.SaveAll();

    I suppose that When you create a folder on network share first a folder "New folder" is created and it is renamed to the chosen name. At the creation of the folder Windows Search catches it and do not release it for 90 seconds.

    This script add an scope rule to ignore folders with name "New folder"

    Monday, September 12, 2016 8:31 AM
  • check the feedback app

    search 

    0x8007003B

    it was reported 3 times  i upvoted on it also 

    was reported on build - 14295 

    my update said "still happening 14393.10"

    Monday, September 12, 2016 8:40 AM
  • We have this same problem in our medium sized business network. i hope they fix this quickly!!!
    Monday, September 12, 2016 9:43 AM
  • Hi!

    I solved this problem by excluding "Offline files" from the client's search index! I guess that the 1607 update adds the offline files to the local index, and that it conflicts with the index running on the server for the same files. So if you don't want to turn off the search service on the servers, do this fix on the clients instead.

    Just open indexing options from the control panel, click "change" (or what it's called in English), and uncheck Offline Files. I guess this can be done with som GPO setting also..


    • Edited by Comega-Johan Monday, September 12, 2016 9:27 PM
    • Proposed as answer by O Azzam Thursday, November 03, 2016 1:13 PM
    Monday, September 12, 2016 2:41 PM
  • Hi!

    I solved this problem by excluding "Offline files" from the client's search index! I guess that the 1607 update adds the offline files to the local index, and that it conflicts with the index running on the server for the same files. So if you don't want to turn off the search service on the servers, do this fix on the clients instead.

    Just open indexing options from the control panel, click "change" (or what it's called in English), and uncheck Offline Files. I guess this can be done with som GPO setting also..


    tanks for that alternative solution, maybe that's more close to the real problem..

    EDIT: after testing we can´t confirm that solution, still got 0x8007003B

    only temporal solution that works for us:

    disable SMB 2/3 with

    open Command as administrator

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
    sc.exe config mrxsmb20 start= disabled

    and restart.

    If an MS-Update comes (we all relay hope) undo it whit

    open Command as administrator

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
    sc.exe config mrxsmb20 start= auto

    after restart you'll be back on SMB 2/3


    Update KB3176938 does not fix that issue current version Win 10 Pro 14393.105
    • Edited by D.Mos Tuesday, September 13, 2016 6:55 AM
    • Proposed as answer by bertajanos Tuesday, September 13, 2016 8:43 AM
    Tuesday, September 13, 2016 5:30 AM
  • indexing options -     build 1511  has  offline files included in indexing  - and it works

    build 1607 (latest .105) has offline files included in indexing -  and error 0x8007003B

    smb -      build 1511   reports   smb  3.0.2   and works 

    build 1607 (latest .105) reports  smb  3.0.2   and error 0x8007003B

    Tuesday, September 13, 2016 7:29 AM
  • Build .187 with the same problem of SMB 3 :(

    8 weeks without any fix -.-

    Tuesday, September 13, 2016 5:57 PM
  • I am stunned that Microsoft continues to ignore this problem. There is no way they could have missed this bug before they released 1607 if they did even the most basic tests. A domain joined machine with indexing enabled on the file server is a standard configuration. How many cumulative updates have they released now for 1607? And yet they shorten the rollback period on the new build to only 10 days? I feel horrible for anyone out there who rolled this update out en masse.

    Tuesday, September 13, 2016 7:19 PM
  • Checking on an ETA. 
    Tuesday, September 13, 2016 11:49 PM
  • would be nice if there is a feedback :)

    problem is still alive in Win 10 Pro 14393.187

    after Update KB3189866 ..

    • Edited by D.Mos Wednesday, September 14, 2016 6:51 AM
    Wednesday, September 14, 2016 5:39 AM
  • anyone with a twitter account want to ask 

    https://twitter.com/donasarkar?lang=en

    seeing as its still not fixed in the insider builds 

    maybe she can give some feedback as to why the issue, that was reported via the insider program before the anniversary update was missed 

    this has got to be cheaper than opening a paid support ticket at MS............


    Wednesday, September 14, 2016 6:07 AM
  • just out of interest - 

    I tried setting up a fileshare on win 2016 tech preview 5 

    (version 1511 , 14300.1054)  , with indexing turned on

    the win 10 reports a newer smb version  3.1.1 to this share (with win 2012r2 its version 3.0.2) 

    the same problem is present  0x8007003b

     

    Wednesday, September 14, 2016 6:36 AM
  • Just to add myself (and the 100+ clients company I'm working for) in and bump this:

    Confirming all of the above said, esp. conditions to reproduce and workaround via downgrading SMB. This is what I did for now, because turning off index is not an option. All clients connecting on SMB2 now.

    Wednesday, September 14, 2016 2:46 PM
  • Adding our company to the list.

    Same issue with anniversary update.
    @Microsoft: Please fix it!

    Wednesday, September 14, 2016 4:48 PM
  • Add us to the list getting this error.

    All clients are 1511 except for 4 test machines that are 1607 (both physical & VM). All 1607 PCs have this issue. Server is 2012 R2 Standard.

    This seems to be the only outstanding issue left before we roll out 1607 to all client machines. Get on this Microsoft!!!

    • Proposed as answer by RenardPale Thursday, September 15, 2016 12:18 PM
    • Unproposed as answer by RenardPale Friday, September 16, 2016 11:37 AM
    Wednesday, September 14, 2016 7:30 PM
  • Add me also to the list, also 2 friends running the same conf. have the same Problem.

    Server: Windows Server 2012 R2 essentials

    Clients: all Windows 10 Anniversary Update ...

    MSFT: please are so kind to look closer to that and FIX IT!!


    • Edited by Mark_muc Thursday, September 15, 2016 7:50 AM
    Thursday, September 15, 2016 7:39 AM
  • So this is the bedtime story I told my 3yr old tonight:

    Since the dawn of the personal computer, and the times of MS DOS 1.0 we have been able to create folders and put files into those folders and all was good in the world. Then something happened and someone somewhere changed things and not for the better, mind you. No, the evil SearchIndexer.exe would not release it's powerful grip on our sacred New Folder. Sending it's data all over the internet where the hackers, some with white-hats and some with black-hats, had an absolute field-day with all the data. Now we are unable to organize files without crashing Explorer.exe or any other program that tries to create a New Folder in the Save dialog!!!?!! and then there was chaos! well until patch Tuesday. But many patch Tuesdays had passed and the moon became full and the stack overflowed with an illegal operation that killed the process and cause a kernel panic!

    MS please fix this so I can tell a happy(er-ish) ending.
    • Edited by DanTron Thursday, September 15, 2016 8:43 AM more fun
    Thursday, September 15, 2016 8:39 AM
  • We have a network with exactly the same configuration (Windows Server 2012 R2 Essentials plus a dozen Windows 10 Pro Vrs. 1607 / Build 14393.187). All of them absolutelly updated (the clients have been updated again today, by the way).

    And since the Windows 10th Anniversary Update we have been suffering with this very problem. Finally I've stumbled upon this thread and now I'm too oweing a beer to Mr O 76:

    Turning Windows Search Service off on the SERVER circumvented the problem!

    Hey, Microsoft! It's been more than a month, now! Isn't it a shame?

    Thursday, September 15, 2016 5:30 PM
  • We are also seeing this issue at several clients sites where Server 2012 R2 is used with Windows 10 Clients running the 1607 Anniversary Update Build.

    It seems that excluding the folders from Indexing on the Server does resolve the issue but as others have highlighted this slows down search results for the users.

    Please can someone from Microsoft acknowledge the issue exists and that they are investigating the cause.

    Friday, September 16, 2016 1:12 PM
  • I'm not from Microsoft but I am communicating with Microsoft.  The bug as been assigned to a team that is working on it.  At this time I can get no ETA for a fix.
    Friday, September 16, 2016 5:08 PM
  • P.S. there are two workarounds:

    1. turn off indexing (not good)

    2. rename using command line (not ideal either)

    Friday, September 16, 2016 5:09 PM
  • I'm not from Microsoft but I am communicating with Microsoft.  The bug as been assigned to a team that is working on it.  At this time I can get no ETA for a fix.

    Thanks Susan for the update.  You are one of the few people I have run across that have a communication channel with Microsoft about this issue, so any updates you can provide going forward are invaluable to those of us who are waiting for a fix. 

    I find it ridiculous (directed at Microsoft) that they have not released a patch yet.  This issue has been going on for a while and it seriously impairs Win10 users who work with network shares. I can't imagine the nightmare a large org, with a larger number of Win10 users, might be having right now, fortunately for me I only have 2 Win10 users.  One is myself and along with another user, we are the Windows 10 guinea pigs for our company.  I am glad I haven't transitioned my company over to Win10 yet due to issues like this.

    Thanks again for the update!

    Monday, September 19, 2016 5:35 PM
  • I can confirm that this bug also occurs when using Windows Server 2012, not only R2. This has occured on three different 2012 servers, all on 1607 clients.

    Tuesday, September 20, 2016 10:44 AM
  • I think something has changed between 1511 and 1607  regarding SMB 3 connections.

    I did following test. Setup a new VM with Win 10 Pro x64 (1607) and no further Software.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 3.0.2. Result: Issues like described

    Next, disable SMB 2/3 with (https://support.microsoft.com/en-us/kb/2696547):

    sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
    sc.exe config mrxsmb20 start= disabled

    and restart.

    Connect to Win 2012R2 Share. Connect-Dialect SMB 1.5 Result: No issues

    I think, it's time for Microsoft to investigate the issues!

    Thanks a lot for this Tip! The same here and this Workaround helps me (Server 2012 R2 Essentials and Client Windows 10 1607 with current updates)

    Please Microsoft Fix it soon, we want to roll out the 1607 Update...

    Wednesday, September 21, 2016 2:47 PM
  • Thanks Susan for the update.  You are one of the few people I have run across that have a communication channel with Microsoft about this issue...

    Anyone can open a support case with Microsoft.  If you don't have an existing support agreement, you provide a credit card.  When they determine it is a product bug, they waive the fee.  I have had a few support cases go through Microsoft this way. 

    Wednesday, September 21, 2016 5:58 PM
  • You are a damn god. I will happily provide you a carton of beers.
    One of my clients had this issue and have been troubleshooting for damn weeks! For me it only happens when they create a folder in a "Save as" dialog.

    Disabled Search on server - INSTANT resolution.

    I owe ya one.

    Thursday, September 22, 2016 12:25 AM
  • I want to say that this problem has been happening to my client's network for over 3 years now.  He has server 2012 Standard and has 2 windows 7 and 2 windows 8 client computers.  I have tried just about everything to no avail.  The problem happens sporadically and usually it is with creating or renaming folders.

    One thing that worked for a while until different problems surfaced was changing the speed from the client computers down to 10 MB.  This stopped all problems with server lockups while creating or renaming folders.

    The obvious problem was this change was working with their Auto cad drawing.  Ned less to say, I changed the speed back to Auto-detect and the problems came back again.

    I will probably open a case with Microsoft just to appease the customer, but I don't think this is going to be a fix Microsoft will provide anytime soon.

    Almost forgot to mention, when the lockup occurs to a person that is renaming or creating a folder, the lockup affects everyone on the network.  The server reaches 100% CPU utilization for several minutes.  Once the server generates the error 0x8007003B, CPU goes back to normal and the rest of the computers are able to continue to work.  Also Search is not enabled on the server.,

    Good luck



    • Edited by ams011214 Friday, September 23, 2016 5:36 AM
    Friday, September 23, 2016 5:29 AM
  • Hi ams011214,

    I'm pretty sure that your problem is not related to the circumstances described in this thread.

    That said, did you already open up an discussion thread about this somewhere - I think that it should be possible to determine the reason for your lockups, especially because you're having precise informations about reproducabilty and specific programs/operations that cause this lockups.

    Fast shot, but I don't want to distrack from the real thread here:

    1. You say search (and following from that: index) is turned off on server side. Did you verify this by looking at the services / testwise manually disabling these services? How is search and index configured on clients - do they try to index the server side by themselves?
    2. As a general advisement: If you didn't do yet, consider to disable generating of thumbs.db by the clients on network locations. This is doable by GPO and really (really) should be done in every environment where (esp. multiple) users are working on files with graphical programs like Adobe, Autocad.... This will not prevent clients from viewing those files in the preview pane anymore and has no negative real-word effects your clients would notice.

    RP

    • Edited by RenardPale Friday, September 23, 2016 10:19 AM
    Friday, September 23, 2016 10:16 AM
  • Hey csabago,

    Great news! What a painful problem.

    Is odd - I have the 3 fileservers with a mixture of Win10 1511 and 1607 clients. It only affects the 1607 clients. It doesn't really make sense turning off the Windows Search function on the fileservers affects the 1607 clients.

    Maybe someone smart at microsoft can answer that one!

    Am interested to hear if this fixes issues on the 2012 server networks.

    Mr O 76

    I have this same issue.  I am running server 2012R2 Essentials with the Windows 10 1607 clients.  The folders will eventually rename for us, but it takes a while and you get the error pop up. 

    I tried turning off search and everything worked great.  Sooo, then I turned windows search back on and everything still worked great.  Here is what I found.

    When you turn off Windows Search, it disables windows media player network sharing service.  When I restart the media player sharing, problem comes back.  turn off media player sharing, problem stops.  It seems the root issue is with the Windows Media Player Network Sharing Service.  If you disable that, you can leave the windows search functions alive for other uses I think.

    Friday, September 23, 2016 3:35 PM
  • My problem is exactly what is being described here.  The only difference is that you are running windows 10 clients and I am running windows 7 and 8 clients.  The issue being experienced here is not only isolated to windows 10.

    I am not trying to hijack this thread, it is just that the issue including the error code is exactly the same.

    The lock down for several minutes happens when creating or renaming folders on a server 2012 server with windows 7 or 8 clients.  

    Index is turned off on the server side but not on the client side.  Search is not installed on the server so that is not the concern.  This issue is no application specific as it happens when they are using Windows explorer and creating  or renaming folders.

    If I don't find a solution within the next few days, I will open a support call with Microsoft and post the results here.

    I know this is a very frustrating issue and hopefully a solution is within reach.

    Thank you


    Angel Sepulveda

    Friday, September 23, 2016 3:44 PM
  • Angel - Your symptoms may be the same, but the root causes are not. Everyone else on this thread is having the issue with Windows 10 version 14393.xx and up. Windows 10 verison 10586 is not affected and neither are other windows clients. The issue is with the server side indexing and the new SMB protocols introduced in Windows 10 version 14393 (the anniversary update). The subject of this thread is Windows 10 anniversary update. Your case is entirely different from what all the posts above have been experiencing. In fact it is the opposite. I suggest to start your own thread with your troubleshooting scenario, rather than muddying the waters here where we are focused on one scenario. Maybe there is a correlation somehow, but until you find something to that effect please keep your troubleshooting in a separate thread. 
    • Edited by ehclw Friday, September 23, 2016 7:33 PM
    Friday, September 23, 2016 6:49 PM
  • Hey csabago,

    Great news! What a painful problem.

    Is odd - I have the 3 fileservers with a mixture of Win10 1511 and 1607 clients. It only affects the 1607 clients. It doesn't really make sense turning off the Windows Search function on the fileservers affects the 1607 clients.

    Maybe someone smart at microsoft can answer that one!

    Am interested to hear if this fixes issues on the 2012 server networks.

    Mr O 76

    I have this same issue.  I am running server 2012R2 Essentials with the Windows 10 1607 clients.  The folders will eventually rename for us, but it takes a while and you get the error pop up. 

    I tried turning off search and everything worked great.  Sooo, then I turned windows search back on and everything still worked great.  Here is what I found.

    When you turn off Windows Search, it disables windows media player network sharing service.  When I restart the media player sharing, problem comes back.  turn off media player sharing, problem stops.  It seems the root issue is with the Windows Media Player Network Sharing Service.  If you disable that, you can leave the windows search functions alive for other uses I think.

    On Server 2012 R2 I disabled Windows Server Essentials Media Streaming Service and also disabled Windows Media Player Network Sharing Service on the Windows 10 ver 1607 build 14393.187 client and the issue persists when Windows Search is running on the server. Maybe there is something different about 2012 R2 Server Essentials that makes this work for you, but I am still stuck with this issue on my 1607 clients or I have to disable Search on the server. Pick your poison. Search service running on the server is valuable since it allows the file contents on the network shares to be searched. If it is disabled then we only get the file names searched.
    • Proposed as answer by MikiLeBar Friday, September 23, 2016 7:23 PM
    • Unproposed as answer by MikiLeBar Friday, September 23, 2016 7:23 PM
    Friday, September 23, 2016 7:04 PM
  • Hey csabago,

    Great news! What a painful problem.

    Is odd - I have the 3 fileservers with a mixture of Win10 1511 and 1607 clients. It only affects the 1607 clients. It doesn't really make sense turning off the Windows Search function on the fileservers affects the 1607 clients.

    Maybe someone smart at microsoft can answer that one!

    Am interested to hear if this fixes issues on the 2012 server networks.

    Mr O 76

    I have this same issue.  I am running server 2012R2 Essentials with the Windows 10 1607 clients.  The folders will eventually rename for us, but it takes a while and you get the error pop up. 

    I tried turning off search and everything worked great.  Sooo, then I turned windows search back on and everything still worked great.  Here is what I found.

    When you turn off Windows Search, it disables windows media player network sharing service.  When I restart the media player sharing, problem comes back.  turn off media player sharing, problem stops.  It seems the root issue is with the Windows Media Player Network Sharing Service.  If you disable that, you can leave the windows search functions alive for other uses I think.

    On Server 2012 R2 I disabled Windows Server Essentials Media Streaming Service and also disabled Windows Media Player Network Sharing Service on the Windows 10 ver 1607 build 14393.187 client and the issue persists when Windows Search is running on the server. Maybe there is something different about 2012 R2 Server Essentials that makes this work for you, but I am still stuck with this issue on my 1607 clients or I have to disable Search on the server. Pick your poison. Search service running on the server is valuable since it allows the file contents on the network shares to be searched. If it is disabled then we only get the file names searched.

    I have same issue.
    Friday, September 23, 2016 10:38 PM
  • Hello everyone,

    Thank you for reporting this issue.  We are investigating this issue and will keep this thread updated once we have details to share.

    In the meantime, these are the recommended workarounds:

    • Temporarily disable Windows Search on the server side

    • Use command line to rename the folder

    We do not recommend disabling SMB2 as a workaround, as this can have a greater impact on the system.

    Thank you for your patience while we look into the issue.

    Regards,
    Anthony


    Friday, September 23, 2016 10:43 PM
  • Am having same exact issue after installing Anniversary Update. Very frustrating. In our line of business search is used very often so disabling is not a great workaround. Hopefully a solution/update will be release quickly. User and bosses not happy.
    Friday, September 23, 2016 11:30 PM
  • Also... redirected folders (such as a user's Documents folder that gets redirected to a network share) goes offline, but only after attempting to create a new folder in the same manner as this thread describes. In a fresh session the folders are online up until a new folder creation is attempted (and errors out). Disappointingly... we have a network scanner that scans to each users redirected Documents folder on our file server. Unfortunately the scanned filed will seemingly appear missing until the folder's status is Online... which requires a reboot. However, once the user (forgettingly) tries to create a new folder as mentioned in this thread, the redirected folders go offline again and will not sync. What a freaking hassle.
    Saturday, September 24, 2016 12:27 AM
  • Is there an official KB article ID on this issue?
    Saturday, September 24, 2016 12:59 AM
  • Adding ourselves.  Exact same issue
    Sunday, September 25, 2016 2:32 PM
  • Thank you Mr O 76

    Turning off the search index on the share folder for me on a Home Group Network.

    Thank you 

    Monday, September 26, 2016 11:45 AM
  • Having the same issue on all our domain joined PCs. If you leave Explorer long enough it does finish the operation though it take a good minute or so.

    File server is WS 2012

    Monday, September 26, 2016 3:37 PM
  • We are in the same boat.  Plus 1607 killed the connection to the server.  Clients appear offline.  Folder and file renaming was slow with previous build too but has gotten much worse! 

    Many Thanks, JP

    Monday, September 26, 2016 4:41 PM
  • We also are impacted.
    Instructing my users to use the command line or deal with the delay.
    Turning off indexing would create even greater delays in our business.
    More so than waiting for the rename operation to eventually complete.
    The annoyance factor is the biggest problem I'm facing. And I have some very annoyed users.

    Fingers crossed for a speedy resolution.


    • Edited by G Ramsey Monday, September 26, 2016 5:45 PM
    Monday, September 26, 2016 5:44 PM
  • Thank you for responding  Anthony. We hope for a speedy resolution as the workarounds are not that great.
    Monday, September 26, 2016 9:55 PM
  • This seems to be resolved now. The Win 10 1607 clients haven't received a new update, they are still 14393.187. But the 2012 R2 Server installed KB3185280 on Sunday. The description for that KB doesn't list anything about the indexing service, but whatever.

    I cannot seem to reproduce the issue now, anyone else?


    Tuesday, September 27, 2016 6:33 PM
  • Interesting. The KB3185280 appears to be the September 2016 for Windows 2012 Server, not R2. The R2 update for September is KB3185279. I'm running R2 and my WSUS correctly installed KB3185279 and ignored KB3185280.

    https://support.microsoft.com/en-us/help/22811/windows-server-2012-update-history

    https://support.microsoft.com/en-us/help/24717/windows-8-1-windows-server-2012-r2-update-history

    Tuesday, September 27, 2016 8:21 PM
  • Interesting. The KB3185280 appears to be the September 2016 for Windows 2012 Server, not R2. The R2 update for September is KB3185279. I'm running R2 and my WSUS correctly installed KB3185279 and ignored KB3185280.

    https://support.microsoft.com/en-us/help/22811/windows-server-2012-update-history

    https://support.microsoft.com/en-us/help/24717/windows-8-1-windows-server-2012-r2-update-history

    I noticed that too. Did it fix the issue for you as it did for the previous poster? I will install it tonight I think.
    Tuesday, September 27, 2016 9:14 PM
  • Interesting. The KB3185280 appears to be the September 2016 for Windows 2012 Server, not R2. The R2 update for September is KB3185279. I'm running R2 and my WSUS correctly installed KB3185279 and ignored KB3185280.

    https://support.microsoft.com/en-us/help/22811/windows-server-2012-update-history

    https://support.microsoft.com/en-us/help/24717/windows-8-1-windows-server-2012-r2-update-history

    Yes, you are correct. I forgot our fileserver is the only non R2 of the bunch. Not that it matters, the New Folder issue was affecting both R2 and non R2 2012 installations. The KB3185280 appears to be the only change to our server/clients since last week when I could produce the problem, and as i stated above I cannot make this happen anymore. 

    Did KB3185279 fix the issue for those of you running R2?

    Tuesday, September 27, 2016 9:21 PM
  • I can confirm that it did not fix the issue on my side. I'm still experiencing it. KB3185279 installed on my system on September 22nd. I pushed the Windows 10 1607 upgrade and patches out on the 23rd. Unfortunately I didn't find out about this bug until after the upgrades/updates were installed. I guess we'll keep waiting for a fix.
    Tuesday, September 27, 2016 11:21 PM
  • Also can confirm KB3185280 on Server 2012 Essentials did not fix the issue with clients running 14393.187.

    Tuesday, September 27, 2016 11:45 PM
  • Same Problem here,

    I have seen this problem in two networks.

    On a new machine with 1607 fresh installed the recomended workaround with "disable search in offlinefolders" seams to have helped.

    In a second network all the updated win 1607 have this problem. Workaround did not do any good. It got worse, before it was 30 sec. timeout, now it's the known error-message and a refresh-problem of the server-directory. After the error message the new folder on the sever is renamed but the client stil shows "New Folder".

    So Microsoft please fix that, it's a show stopper for win1607 and a problem for customers who already updated their machines.

    BTW, I think best would be to use the feedback app on any affected machine with any affected os version.

    Maybe this helps .....


    PS ..... by now I got feedback from the cusotmer with 1607, fresh install, problem still persists and disable indexing of offlinefolders did not help.

    Found the bug in the next network, client has updated to 1607, Server is 2012R2 and I get the feedback from the clients ....
    Wednesday, September 28, 2016 6:10 PM
  • I started having this problem too, except I use Windows Server 2012.  Not R2.

    Sometimes when I get the error, if I press F5 to refresh, the folder is actually renamed correctly.  Other times, it still says New Folder, and I have to try over and over until it finally renames successfully.

    Wednesday, September 28, 2016 6:41 PM
  • As an IT Support company we too have a Customer with a Server 2012 Essentials and Windows 10 (with Anniversary Update) PCs in a Domain configuration with this problem.

    We have tried turning off the Search Service on the Server and Workstations but this does not seem to work.

    One solution (workaround) our customer has found is to create a new folder (and rename it as appropriate) on the local PC and then "drag" it to the Server Folder where you are struggeling to create / rename folders.

    Hope this helps until Microsoft provide a real solution.


    • Edited by AJW01 Thursday, September 29, 2016 10:45 AM
    Thursday, September 29, 2016 10:44 AM
  • I owe you a beer Mr O 76 it would seem.  I am waiting to see if the problem rears its ugly head again as it has been intermittent.  This is the 3rd time I was sure I found the solution.  Ha Ha

    Thank you

    Thursday, September 29, 2016 9:31 PM
  • We resolved!!

    3 servers, 1' Win2012r2 updated, 2' Win2012r2 updated, 3' win2012r2 not updated.

    1' with problem, the 2' and 3' without problem

    Disabled the service Windows Search the problem was resolved

    Friday, September 30, 2016 1:50 PM
  • Disabling Windows search is not a solution. It's a workaround at best.
    We constantly use Windows search in our office. So disabling it isn't an option.

    Friday, September 30, 2016 2:31 PM
  • Updated clients to 14393.222 this morning.  Problem still persists. (Server 2012 Essentials with September rollup).
    Friday, September 30, 2016 3:12 PM
  • Thanks Susan for the update.  You are one of the few people I have run across that have a communication channel with Microsoft about this issue...

    Anyone can open a support case with Microsoft.  If you don't have an existing support agreement, you provide a credit card.  When they determine it is a product bug, they waive the fee.  I have had a few support cases go through Microsoft this way. 


    Understood, but I prefer not going through that process if someone else has already started a case on the subject.  I've gone that route before and they are not always forthcoming on giving you a refund on your support fee unless you press them.
    Friday, September 30, 2016 3:20 PM
  • Now that we are getting ready to move into October, this issue has been going on for a couple of months now.  It astonishes me that Microsoft has not issued a patch to fix this.  I agree with some of the others that disabling Windows Search is not an option in our office.  We have a couple of TB of data on our servers and the ability to search it quickly is essential. 

    Has anyone heard anything on the status of a patch?

    Friday, September 30, 2016 4:12 PM
  • disconnecting/deleting the mapped network drive on the affected computer and recreating it fixed the issue for me.

    BullerTech

    Friday, September 30, 2016 4:16 PM
  • FINALLY fixed with KB3194496 released yesterday. Better late than never I guess.
    Friday, September 30, 2016 8:55 PM
  • Did not work for me.
    Friday, September 30, 2016 11:20 PM
  • I am having same issue even after installing KB3194496. Problem didn't get fixed.
    Friday, September 30, 2016 11:27 PM
  • still happening here as well. Just updated to latest 10 AU build and installed all 2012 r2 updates. at first I thought it was fixed since it wasn't happening in one folder that it was before. Then I tried several other folders and they had the problem. I found at least one other that did not have the problem. It seems like something happened now that it works sometimes. An improvement maybe? 
    Saturday, October 01, 2016 6:33 AM
  • ehclw, did the exact same thing as you and same situation, not fixed.  


    BullerTech

    Monday, October 03, 2016 4:48 PM
  • ehclw, make sure you are disabling windows search on the server and not on the workstation.  I just realized i only tried it on the workstation and when i just tried it on my server, it fixed the issue!

    BullerTech

    Monday, October 03, 2016 4:56 PM
  • ehclw, make sure you are disabling windows search on the server and not on the workstation.  I just realized i only tried it on the workstation and when i just tried it on my server, it fixed the issue!

    BullerTech

    Thanks, but I know about that "fix" or workaround actually. That fixes one problem by creating another, which is limited searching on the file server and is not an acceptable solution for our office.
    Monday, October 03, 2016 6:33 PM
  • "FINALLY fixed with KB3194496"

    I would like to revise this: For me, the patch has reduced the frequency of the problem, but it definitely still occurs. I still do not feel comfortable rolling the anniversary update out to the end users.

    Monday, October 03, 2016 7:01 PM
  • gotcha, i have never had much success with acceptable speeds for searching files on the server anyway.

    BullerTech

    Tuesday, October 04, 2016 3:56 AM
  • The problem is still present for me, even after installing KB3194496.
    Tuesday, October 04, 2016 8:02 AM
  • I have the same problem with Windows Server 2012R2. I have about 15 Windows 10 PC's - combination of physical and virtual. Some of these are vanilla installs with no software other than windows.

    The problem exists for all domain joined and non domain joined workstations alike....

    I have rolled back now to previous version of windows 10 and don't have the problem anymore

    Tuesday, October 04, 2016 8:54 AM
  • I came across this issue at a customer today.  It seems that the combination of Server 2012 R2 and Windows 10 1607 is where you can replicate.

    I got round the issue by stopping and disabling the Windows Search service on the server only.

    Hope this helps someone and also hope MS get a fix out soon.


    • Edited by Dorian Woolger Tuesday, October 04, 2016 10:48 PM
    • Proposed as answer by trav159 Thursday, October 06, 2016 4:07 AM
    Tuesday, October 04, 2016 10:39 PM
  • gotcha, i have never had much success with acceptable speeds for searching files on the server anyway.

    BullerTech

    Hmmm...I have over a million items indexed on the server and it provides search results in seconds from any client using explorer. Maybe you are way over that. I think it has some limitations. I've had to tweak the index a bit to include only file types that were necessary to search to deal with a few bugs. For the most part it does what we need it to and does it well. Until this stupid bug.
    Tuesday, October 04, 2016 10:52 PM
  • I came across this issue at a customer today.  It seems that the combination of Server 2012 R2 and Windows 10 1607 is where you can replicate.

    I got round the issue by stopping and disabling the Windows Search service on the server only.

    Hope this helps someone and also hope MS get a fix out soon.



    It happens if your "server" is a windows 10 machine as well. I have a windows 10 based file server and all clients on my network experience the same issue after updating to Windows 10 1607.
    Wednesday, October 05, 2016 4:57 AM
  • Same issue here. I found another workaround by creating folders/subfolders to the local PC drive and then cut/paste to the required location on the network drive. No need to turn off search on the server. Could work for renaming folders but only by copying folder contents
    Wednesday, October 05, 2016 8:34 AM
  • You are right, i have been dealing with  this issue all day and came across your solution, as  soon as i disabled the search feature on server 2012 r2 bingo i can save to the network again, thank you very much.
    Thursday, October 06, 2016 4:07 AM
  • " investigation is still happening"

    Just so you know, this is still being investigated. 

    Friday, October 07, 2016 12:53 AM
  • Hi All,

    In my case "Windows Search Service" is not installed in that server. Other users are able to rename the folders successfully and myself only getting this error. Indexing service also not available in that server. I've ran the check disk and no NTFS errors on the volume.

    Please provide the cause for this issue and solution.

    Server: Windows Server 2012 R2


    vicky

    Friday, October 07, 2016 11:56 AM
  • Hi,

    I came across it today, server: W2k12 R2 with indexing enabled and Windows Search Server running.

    My laptop since about 4 weeks with 1607 (now Build 14393.222), another laptop also. On my laptop I noticed today after updates that I cannot rename folders on a share, the other laptop can rename folders,  all clients with older os versions anyway. I don´t remember when I created the last folder on the share, but would pretty stong asume it was after the anniversary upgrade. Disabling SMBv2/3 on the client does help, but another solution would be very appreciated. It´s quite unbelievable that such a problem persists so long.




    • Edited by BerndRa Friday, October 07, 2016 1:11 PM
    Friday, October 07, 2016 12:26 PM
  • Confirmed.

    Windows 10 Enterprise 10.0.14393

    When I create folder on Server (2012R2....6.3.9600 Build 9600)

    The creation of the folder times out.

    If I stop indexing service on service then the task completes.  When I restart it the bug returns.

    Friday, October 07, 2016 3:04 PM
  • " investigation is still happening"

    Just so you know, this is still being investigated. 


    Thanks Susan for the update.  Hopefully they will have a solution soon.
    Friday, October 07, 2016 9:49 PM
  • This bug actually prevents Adobe Lightroom from importing pictures to a shared folder on the server.  I had to disable Windows Search Service and reboot the server before I could complete an import.

    Sunday, October 09, 2016 12:33 AM
  • Windows fast ring build,   14942 , problem still exists 

    neil donaldson

    Monday, October 10, 2016 8:27 AM
  • Hi,

    In my case "Windows Search Service" is not installed in that server. Other users are able to rename the folders successfully and myself only getting this error. Indexing service also not available in that server. I've ran the check disk and no NTFS errors on the volume.

    Please provide the cause for this issue and solution.

    Server: Windows Server 2012 R2    Version 6.3 Build 9600





    • Edited by - vicky Monday, October 10, 2016 11:27 AM
    Monday, October 10, 2016 10:32 AM
  • Microsoft! Pleaseeeee! Fix this soon! It's such a huge hassle for our company not using search (as the workaround).
    Monday, October 10, 2016 4:59 PM
  • Thanks for that!

    Scott

    Monday, October 10, 2016 7:09 PM
  • build 14393.223   and win 2012 r2 fileserver  problem still exists

    as a test

    build 14393.223  against win server 2016 (also 14393.223)  same problem 


    neil donaldson

    Tuesday, October 11, 2016 11:47 AM
  • Same problem here with multiple customers

    Turning off Windows Search is not an option.

    MS please do something!

    Tuesday, October 11, 2016 1:21 PM
  • This is getting ugly.

    I have a few customers questioning my judgment because I suggested they go ahead with the Windows 10 upgrades in July.  I warned them that the forced updates would be a pain but this is much more than just a pain.

    It's time for Microsoft to correct this ridiculous problem and to give admins control of the update process. 

    Tuesday, October 11, 2016 4:21 PM
  • Problem still present after 14393.321 update.
    Tuesday, October 11, 2016 7:31 PM
  • Not only does the problem persist after the 14393.321 update released today, but my network transfer speeds have plummeted. Down to 18-20 KBps using file explorer from 20-30 MBps prior to the update.

    Every update just seems to take us another step in the wrong direction.

    Tuesday, October 11, 2016 9:53 PM
  • Not only does the problem persist after the 14393.321 update released today, but my network transfer speeds have plummeted. Down to 18-20 KBps using file explorer from 20-30 MBps prior to the update.

    Every update just seems to take us another step in the wrong direction.

    I just installed the 14393.321 and it seems to have fixed the issue on my PC and I don't have any transfer speed issues. It seems to transferring at full gigabit speed as always. I created over 10 new folders and it renamed immediately without any issues. I'll start installing this update on other computers and see if it fixes them too. I'll update later whether or not I see the issue on any computers.
    Tuesday, October 11, 2016 10:46 PM
  • Not only does the problem persist after the 14393.321 update released today, but my network transfer speeds have plummeted. Down to 18-20 KBps using file explorer from 20-30 MBps prior to the update.

    Every update just seems to take us another step in the wrong direction.

    I just installed the 14393.321 and it seems to have fixed the issue on my PC and I don't have any transfer speed issues. It seems to transferring at full gigabit speed as always. I created over 10 new folders and it renamed immediately without any issues. I'll start installing this update on other computers and see if it fixes them too. I'll update later whether or not I see the issue on any computers.

    Thanks for that.

    Seems something went horribly wrong with my network connection during the update. Removed/reinstalled the NIC, reinstalled the Intel Drivers, and my speeds are back where they should be.

    But alas, the folder creation/rename issue persists.


    Edit: I spoke too soon. Network bandwidth is right knackered.
    • Edited by G Ramsey Wednesday, October 12, 2016 12:07 AM
    Tuesday, October 11, 2016 11:17 PM
  • Not only does the problem persist after the 14393.321 update released today, but my network transfer speeds have plummeted. Down to 18-20 KBps using file explorer from 20-30 MBps prior to the update.

    Every update just seems to take us another step in the wrong direction.

    I just installed the 14393.321 and it seems to have fixed the issue on my PC and I don't have any transfer speed issues. It seems to transferring at full gigabit speed as always. I created over 10 new folders and it renamed immediately without any issues. I'll start installing this update on other computers and see if it fixes them too. I'll update later whether or not I see the issue on any computers.

    I installed 14393.321 on two more. On one it seems to be fixed on the other it is not. I have about 10 Windows 10 PCs to update and I'll post my final results. I have no clue yet why it is working on some and not others. They are all very similarly configured. The two I just updated in which one renaming folders works and one doesn't are the same dell optiplex model.

    So now I've installed it on a few more and it hasn't fixed the issue. I have only one computer that I know of on the same build which doesn't have the issue. I'm not sure if it ever had the issue though. One of them that I thought it fixed was only running SMB 1. I forgot that I had done that. Once I enabled SMB 2/3 the issue appeared again. On the one that doesn't have the issue I even enabled SMB 2/3 just to be sure I wasn't on SMB 1 and it still works.  Why it doesn't this affect this one computer, I don't know. I've been trying to figure it out, but none of my troubleshooting has pinpointed why it works on just this one on the same build. So don't get your hopes up with this build.



    • Edited by ehclw Thursday, October 13, 2016 12:19 AM
    Wednesday, October 12, 2016 12:32 AM
  • Same problem after the update 14393.321.

    One time works, one time not.

    Wednesday, October 12, 2016 9:24 AM
  • Thank you very much. Disabling Windows Search on server fixed immediately. Kudos.
    Wednesday, October 12, 2016 12:02 PM
  • i have been making and renaming folders on 2 affected machines all day today

    and it seems to be fixed in our environment following   14393.321

    some communication on here from MS engineer with an update on whether its supposed to have been fixed in this update would be appreciated.....


    neil donaldson

    Wednesday, October 12, 2016 2:02 PM
  • I have a few customers questioning my judgment because I suggested they go ahead with the Windows 10 upgrades in July.

    Agreed. Makes us look stupid.
    Wednesday, October 12, 2016 5:47 PM
  • Still not working as of build 14393.321.   Creating folder either locks up or will eventually work with an extremely long delay.  Amazing this has not been fixed yet.

    Wednesday, October 12, 2016 6:46 PM
  • Still broken on my network and a number of my clients networks. MS really need to get this sorted. Disabling search is not a fix, my clients use it extensively. MS's QA seems to be out the window at the moment, and they are taking ages to resolve a rather critical issue. If they don't believe it to be a nuisance, perhaps they would like to speak to my clients and take some of the flack that I get now for 'upgrading' to Windows 10. Clients now say they want Windows 7 back as it 'just works'. Another client has shelved plans for a Windows 10 rollout as they believe it to have to many bugs, and it's difficult to contradict that option when you have issue like this going on.
    Wednesday, October 12, 2016 9:35 PM
  • Yep, totally agree... STILL BROKEN

    Windows 10 (updated as of yesterday) on both server and client, still issues creating folders on shared drive.

    Please sort Microsoft, this with a few other problems introduced with the anniversary update really should have been spotted in pre-release testing.

    Good luck

    Thursday, October 13, 2016 8:35 AM
  • Just checked three computers updated to .321 and all three still have the same trouble.

    JBaker07- Right there with you.  I have a small law firm (About 40 Windows 10 machines) that told me yesterday they wanted to go back to Windows 7.  When I told them that would mean clean installs on each machine they decided to wait for 2 weeks to see if Microsoft wakes up.  The office admin said "If we're still in the same boat with this problem compounded by the ridiculous update process we'll do the clean installs to be done with it."

    Hard to argue with them.  How ridiculous is it that you can't create a folder?  And this has been going on for months!

    I also have a small Real Estate office (only 4 computers) that wants me to install a Mac so they can start moving to Macs just to avoid the forced updates screwing with their open applications...

    I believe it is time for someone to fix this - maybe kicking whomever is responsible for it to the curb?

    Please fix this!


    Thursday, October 13, 2016 3:49 PM
  • Our office is of a similar size. You might consider everything search as an interim solution. It was our search solution before I got server side indexing functional. It is much less intuitive than the search experience they are accustomed to in Explorer.

    Note that after disabling the Windows search service, initially we got 0 search results. However a few days later I am seeing that the searches are being completed but in a non-indexed fashion. Depending on how huge the customer's file server is and the speed of the server, this might also work as an interim solution.

    Thursday, October 13, 2016 8:45 PM
  • At first, this problem was just an annoyance. Now that months have gone by, I am starting to get really angry. How can I continue to stand behind and recommend Microsoft products when they are willing to let a problem like this go unaddressed? Is this our reward for putting up with Microsoft's telemetry? "Oh, sorry were not going to fix this any time soon: not enough people are having a problem, so we are working on enhancements to the Edge browser instead". Sickening...
    Friday, October 14, 2016 6:02 PM
  • Same here, build 14393.321 is still broken! :-(

    Ridiculous!!!

    Friday, October 14, 2016 10:31 PM
  • Same here! Windows server 2012 r2 essentials. We have a mixed environment, windows 7 computers have no problems creating folders on the server, windows 10 computers freeze when renaming or creating folders. Turning indexing off does not fix the problem, it seems those answers only apply to people using windows 10 as a server, not people using server 2012r2. Where is the fix?

    Friday, October 14, 2016 11:54 PM
  • Same here, build 14393.321 is still broken! :-(

    Ridiculous!!!

    Same here, tests in some networks confirm, still brocken .... :-(

    First thought it's fixed, but was in a testsetup, without load and without search service on the server.

    Some test in different client offices show: BROKEN!

    Please fix this asap, it's a show stopper for 1607 deployment!


    Saturday, October 15, 2016 3:42 PM
  • going back to 1511 would be enough ....;-)
    Saturday, October 15, 2016 3:45 PM
  • Just installed Windows Server 2016 Essentials an a Windows 10-1607 Notebook all from scratch, only OEM Drivers. Unfortunately even in this constellation the problem still exists. That's a real show-stopper. Disabeling Widnws Search on the Server is a relevant reduction of comfort.
    Saturday, October 15, 2016 8:53 PM
  • Just hooking on this thread, trying to find a solution for the folder creation problem:

    - Windows 10 Pro - 1607 - 14393.321

    - Windows Storage Server 2012 R2 Essentials - version 6.3 - build 9600

    I stopped the "Windows Search" service on the server - (side effect: this also stops "Windows Media Player Network Sharing Service"), and the folder creation problem disappeared.

    Sunday, October 16, 2016 6:10 PM
  • Will this problem ever be addressed?

    We have about 70 clients and roughly a fifty-fifty 7 and 10 environment with 2012 std servers. All machines with 10 1607 have this problem, none of the pre 1607 10's or the 7's have it. This is way beyond annoying!

    Monday, October 17, 2016 6:53 AM
  • I have the same issue. New Windows 2012 R2 environment. Fully up to date, bothe server as clients. Searching through 4,5 milion hits i found a solution.

    Stop the Windows Search service on the server. 

    Test it and you will see the error is gone and creating folders is up to par again.

    I have disabled the Windows Search service on the server for now, will check in a month if they fixed it.

    • Proposed as answer by jantje.vlaam Monday, October 17, 2016 7:06 AM
    Monday, October 17, 2016 7:06 AM
  • I have the same issue. New Windows 2012 R2 environment. Fully up to date, bothe server as clients. Searching through 4,5 milion hits i found a solution.

    Stop the Windows Search service on the server. 

    Test it and you will see the error is gone and creating folders is up to par again.

    I have disabled the Windows Search service on the server for now, will check in a month if they fixed it.

    That workaround, not solution, was found months ago in this thread.
    Monday, October 17, 2016 4:23 PM
  • I am seeing my windows.edb (the windows search indexing database) grow to over 300 GB. This has happened before the trouble with folder renaming, but I seemed to have fixed it then. Now it seems to be happening again whenever I test creating new folders on the affected machines. A possible side effect of the issue? Anyone else seeing windows.edb located in ProgramData\Microsoft\Search\Data\Applications\Windows explode?
    Monday, October 17, 2016 4:28 PM
  • I am seeing my windows.edb (the windows search indexing database) grow to over 300 GB. This has happened before the trouble with folder renaming, but I seemed to have fixed it then. Now it seems to be happening again whenever I test creating new folders on the affected machines. A possible side effect of the issue? Anyone else seeing windows.edb located in ProgramData\Microsoft\Search\Data\Applications\Windows explode?

    I have had that happen on us a few times before 1607 (easily resolved by rebuilding the index), but the indexing database seems consistent right now.
    Tuesday, October 18, 2016 2:20 PM
  • I am seeing my windows.edb (the windows search indexing database) grow to over 300 GB. This has happened before the trouble with folder renaming, but I seemed to have fixed it then. Now it seems to be happening again whenever I test creating new folders on the affected machines. A possible side effect of the issue? Anyone else seeing windows.edb located in ProgramData\Microsoft\Search\Data\Applications\Windows explode?


    I have had that happen on us a few times before 1607 (easily resolved by rebuilding the index), but the indexing database seems consistent right now.
    It seems to happening more now than ever. Might not be related, but I can't point to anything else at the moment. Only issue with re-indexing is that it can take several days to complete. Maybe it is time to start looking at search alternatives.
    Tuesday, October 18, 2016 7:16 PM
  • This is totally doing my head in!

    Disabling search is a ridiculous idea - We run a paperless office and everything is stored as searchable pdf's with the ifiltre installed on the server so we can search for example for supplier invoices based on text in the content of the file. Disabling search and indexing is absolutely not an option.

    So we rolled back all our client pcs and virtual machines to the previous version of windows.

    And a few days later without notification microsoft applies the update again.

    All our customers who are running windows 10 with server 2012 have the same issue.

    Whoever decided to provide the option to roll back to a previous version to avoid the issues caused by premature updates - sureley you must realise we dont just want to roll back for a few days we want to roll back until you develop your software properly! Please grow a brain!!

    Our customers are now beggining to ask for alternatives to windows.

    We have told them that if this is not resolved imminently we will look into implementing a Linux solution.

    I have tried disabling updates through gpedit (Edit group policy>Administrative Templates>Windows Components>Windows Update>Configure Automatic Updates>Disabled) Not sure if this will work - but it will of course disable all updates!

    Can we please have a comment or solution as to how to immunise our pc's against this dreadful update!

    Wednesday, October 19, 2016 11:46 AM
  • Hello skymole111

    Yes this group policy no longer works 

    What i have also found (anyone correct me if i am wrong) put with win 10 pro there is no way to stop standard users running windows update, the group policies that stopped that also dont work. 

    we dont use windows update, we have a 3rd party deploy tool , but imagine my surprise when i found 1 user had upgraded himself to 1607 just by visiting the windows update control panel.....

    anyway the good news is you can still block 1607 with group policy 

    what you need to do is  - set this computer policy 

    Computer configuration/Policies/administrative templates/Windows Components/Windows Update

    Defer Upgrades and Updates

    Upgrades  (1607 counts as an upgrade)  can be deferred for upto 8 months

    Updates (patches)  can be deferred for up to 4 weeks

    If you wack upgrades up to 8 months and run windows update you will not be offered  1607 

    incidentally

    the only other way i could find to stop standard users running windows update was to set a dummy url for WSUS server.... so if they try and connect they fail .....


    neil donaldson


    Wednesday, October 19, 2016 12:11 PM
  • Add me in as well 1x 2012R2 Essentials Server and 5x Win10 Client with update.

    Error: '0x8007003b'on creating a 'New Folder' and renaming it from Win10-Client on a UNC path to the server.

    I used the following PowerShell cmdlets on the server to (temporally) fix the problem until an update/Real-Fix will be available:

    Stop-Service -Name WSearch
    Get-Service -Name WSearch | Set-Service -StartupType Disabled

    Powershell cmdlet To restore Search when the fix/update is available:

    Get-Service -Name WSearch | Set-Service -StartupType Automatic
    Start-Service -Name WSearch



    Julien Zweverink




    Wednesday, October 19, 2016 6:27 PM
  • I am also facing the same problem running on Windows 10 LATEST updates as of Oct 19, 2016 on WServer 2012

    Disabling search is the most pathetic work around, Microsoft needs to fix this asap! 

    Thursday, October 20, 2016 5:48 AM
  • Hello skymole111

    Yes this group policy no longer works 

    What i have also found (anyone correct me if i am wrong) put with win 10 pro there is no way to stop standard users running windows update, the group policies that stopped that also dont work. 

    we dont use windows update, we have a 3rd party deploy tool , but imagine my surprise when i found 1 user had upgraded himself to 1607 just by visiting the windows update control panel.....

    anyway the good news is you can still block 1607 with group policy 

    what you need to do is  - set this computer policy 

    Computer configuration/Policies/administrative templates/Windows Components/Windows Update

    Defer Upgrades and Updates

    Upgrades  (1607 counts as an upgrade)  can be deferred for upto 8 months

    Updates (patches)  can be deferred for up to 4 weeks

    If you wack upgrades up to 8 months and run windows update you will not be offered  1607 

    incidentally

    the only other way i could find to stop standard users running windows update was to set a dummy url for WSUS server.... so if they try and connect they fail .....


    neil donaldson


    Hi Neil

    I thought that would be the case with not being able to disable updates... but didnt realise you could defer upgrades for so long. So thanks very much for the info. This will solve our problem for now - lets hope 8 months is enough for MS to fix this.

    Thursday, October 20, 2016 7:21 AM
  • Hello skymole111

    Yes this group policy no longer works 

    What i have also found (anyone correct me if i am wrong) put with win 10 pro there is no way to stop standard users running windows update, the group policies that stopped that also dont work. 

    we dont use windows update, we have a 3rd party deploy tool , but imagine my surprise when i found 1 user had upgraded himself to 1607 just by visiting the windows update control panel.....

    anyway the good news is you can still block 1607 with group policy 

    what you need to do is  - set this computer policy 

    Computer configuration/Policies/administrative templates/Windows Components/Windows Update

    Defer Upgrades and Updates

    Upgrades  (1607 counts as an upgrade)  can be deferred for upto 8 months

    Updates (patches)  can be deferred for up to 4 weeks

    If you wack upgrades up to 8 months and run windows update you will not be offered  1607 

    incidentally

    the only other way i could find to stop standard users running windows update was to set a dummy url for WSUS server.... so if they try and connect they fail .....


    neil donaldson


    You can disable the "Check online for windows updates" in Windows 10. However, we found that the setting we used to do this also cause the Store to Error and never download any Apps (that may be a plus feature for some). What group policies do what to Windows Update and the Store have been a bit 'fluid' since the original Windows 10 release.

    I think the GP Setting was/is:

    User Configuration -> Admin Templates -> Windows Components -> Windows Update -> "Remove Access to use All Windows Update Features"

    Thursday, October 20, 2016 8:03 AM
  • Same problem here with Windows 10 Version 1607 (Build 14393.321). When I try to create and rename a folder on a network share (UNC path), it hangs for ~1 minute (or even more) before the operation succeeds. If I leave the default folder name ("Neuer Ordner" in my case) it works instantly.

    Is there really no definite solution yet?

    Thursday, October 20, 2016 8:29 AM
  • Same problem here with Windows 10 Version 1607 (Build 14393.321). When I try to create and rename a folder on a network share (UNC path), it hangs for ~1 minute (or even more) before the operation succeeds. If I leave the default folder name ("Neuer Ordner" in my case) it works instantly.

    Is there really no definite solution yet?


    I have the same problem, Windows 10 Version 1607 (Build 14393.321). The only workaround is to disable Windows Search... but I need it. Please MS, fix this!
    Thursday, October 20, 2016 11:50 AM
  • Same here. If the client with Windows 10.1607 try to create a new folder on Windows 2011 SBS with Windows Search service enabled, there isn't any kind of problem. The same Client on Windows 2012R2 shared folder, hangs for about 30 sec/1 min.

    The Windows Search's workaround do the trick but... after months, I think that this issue can't be tolerate anymore.

    Hurry up Ms! Don't sleep on this problem. A lot of customers are still waiting. I know that you usually care about feedback. But now, isn't the case, for sure.

    Thursday, October 20, 2016 3:41 PM
  • Anthony,

    Where are we at on this?

    Thanks,

    James

    Thursday, October 20, 2016 9:31 PM
  • Not yet fixed.
    Thursday, October 20, 2016 9:50 PM
  • And me.

    Running the new Server 2016 and same problem with Windows 10 clients.

    Unbelievable this is still not fixed.

    Typical Microsoft.

    Its like the political situation in America at the moment, Microsoft is Trump and Apple is Clinton.
    Apple just has to keep quite and let Microsoft beat itself!!

    Friday, October 21, 2016 2:34 AM
  • Just had customer call, 3 users affected out of about 20 due to the update, now past the 10 days so can't remove update. Ridiculous, when are Microsoft going to fix this, come on! 

    What sort of impact will disabling the search service one the server have on the users, they have loads of data? 

    • Edited by Rodney_C Friday, October 21, 2016 11:06 AM
    Friday, October 21, 2016 11:04 AM
  • Same problem here, disabling windows search service fixes it for now.....!
    Friday, October 21, 2016 2:24 PM
  • I have also confirmed this problem and the workaround of disabling the service "WSearch" / "Windows Search" on the server.

    Also, I have found that:

    1. The problem does not occur when using Explorer and a UNC path containing the IP address of the server.
    2. The problem does not occur when using Command Prompt and a UNC path containing the hostname / FQDN of the server.
    Friday, October 21, 2016 2:55 PM
  • Bump to the thread, still happening. Waiting for a fix. Disabling search as a workaround.
    Friday, October 21, 2016 9:12 PM
  • Bump to the thread, still happening. Waiting for a fix. Disabling search as a workaround.

    Would be nice to see a Microsoft Support Post to confirm that this issue is urgently being addressed...

    I expect in many commercial office environments this is a serious issue !!!

    As already mentioned, The disabling/stopping of search service on the server workaround is unworkable for many, but mitigates the issue for some.

    Cheers

    Saturday, October 22, 2016 9:32 AM
  • Hey all,

    Possible solution - maybe if you can give it a go...

    Oh my goodness, you're my hero. I've been trying to fix this for about two months now and had more or less given up until it got patched eventually. I didn't find this thread until now because Windows suddenly started giving me an error code today for some reason.

    MS tech support has been completely useless with this whole ordeal. I spent about four hours troubleshooting it with someone and the "solution" they settled on was that at least I could make new folders after Explorer froze the first time.

    Anyway, thanks again, this was driving me crazy.

    Saturday, October 22, 2016 3:45 PM
  • Bump. Still an issue for me.

    I disabled search to temporarily fix it.

    However, our server is used primarily for storing scanned documents for future reference, and now my employees cannot utilize the Windows Search to find their past documents easily.

    Is there a bug site to report bugs that we can all pile on? Or is this forum the unofficial place? 

    Saturday, October 22, 2016 5:16 PM
  • Updated to Windows Server 2016. Seems to work here so far.
    Sunday, October 23, 2016 8:19 AM
  • OK, sooooo this thread was started in August... it'e almost November and guess what just happened to me today.

    This cannot be for real? My end users have been bugging me to turn on Indexing for a few weerks now. I finally do as my PC's (all 40 of them) slowly start getting the Anniversary update... and guess what?

    Yep.... Error 0x8007003B

    I have been a big defender of MS and Windows 10. I really like it even with its flaws. This is my last straw. I seriously wish now that I would have just kept my office on Windows 7. I hate to say that... I hear people say that and I go on to extol the virtues of 10... but now I have to turn off Indexing? If I wasn't beyond my 30 days, I'd roll every damn one back.

    Not worth the extra work it is constantly creating for me...

    Monday, October 24, 2016 4:44 PM
  • OK, sooooo this thread was started in August... it'e almost November and guess what just happened to me today.

    This cannot be for real? My end users have been bugging me to turn on Indexing for a few weerks now. I finally do as my PC's (all 40 of them) slowly start getting the Anniversary update... and guess what?

    Yep.... Error 0x8007003B

    I have been a big defender of MS and Windows 10. I really like it even with its flaws. This is my last straw. I seriously wish now that I would have just kept my office on Windows 7. I hate to say that... I hear people say that and I go on to extol the virtues of 10... but now I have to turn off Indexing? If I wasn't beyond my 30 days, I'd roll every damn one back.

    Not worth the extra work it is constantly creating for me...

    Don't feel too bad Tony as I agree with you that the benefits of Windows 10 outweigh its flaws.  Every new OS goes through these growing pains, some more than others, but all do none the less. 

    I would probably be in the same boat as you if one of our LOB applications was supported on Win10, but its not so I had to keep everyone on Windows 7.  Its stable, but my staff is missing out on the new features of Windows 10 especially with touch screen devices.  Myself and one other person in our office are on Windows 10 as guinea pigs so I am dealing with the same error you saw on a daily basis as I create network folders all the time.  Turning off indexing for us is not worth the headache it creates either as we have 3TB of files we need to be able to search efficiently.  Hopefully MS gets this fixed soon!!!!!!!!!!!!!!!!!! 

    Monday, October 24, 2016 6:14 PM
  • Same problem, disabling the search service helps but greatly impacts our fast searching.
    Monday, October 24, 2016 10:00 PM
  • Just another law firm client with the same problems.  I feel pretty bad that I recommended moving to Windows 10 before the "Free" upgrade expired... Its been a very, VERY expensive "Free upgrade"....  

    The only thing they would find more frustrating than hanging when they try to create and name a folder would be to try to get through a day without their search functions.  When they have problems with that service (which happens with some reguarity) I hear about it by 8:15am...

    Monday, October 24, 2016 11:56 PM
  • Has anyone anywhere heard a response from Microsoft on this issue? Do they know about it? (more accurately, 'are they willing to acknowledge it?').


    • Edited by LTTB Tuesday, October 25, 2016 12:04 AM
    Tuesday, October 25, 2016 12:04 AM
  • This is what Microsoft says (article is dated on 10/22/2016):

    https://support.microsoft.com/en-us/kb/3198614

    3 months after the problem is detected, I think it's not acceptable.

    Tuesday, October 25, 2016 7:39 AM
  • the cause ??

    The problem occurs if an administrator marked the folder for indexing by the Windows Search service on the server.

    the cause ? - using your fileserver as expected

    the article doesnt even say whats going to be done about it, or the fact everything works fine pre 1607 build


    neil donaldson

    Tuesday, October 25, 2016 8:18 AM