0x8007003B

Sign in to vote

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 6, 2016 9:19 PM

Sign in to vote

No, it is not related to 2012 R2 Essentials. 2012 R2 Standard is also affected.

Sunday, August 7, 2016 6:31 AM

Sign in to vote

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 7, 2016 3:17 PM

Sign in to vote

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 8, 2016 7:12 AM

Sign in to vote

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 8, 2016 7:08 PM

Sign in to vote

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 9, 2016 4:05 AM

10

Sign in to vote

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 5, 2016 9:36 AM

Tuesday, August 9, 2016 6:55 AM

Sign in to vote

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 9, 2016 4:57 PM

Sign in to vote

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 9, 2016 6:02 PM

Tuesday, August 9, 2016 5:58 PM

Sign in to vote

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 9, 2016 6:05 PM

Sign in to vote

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 9, 2016 9:24 PM

Tuesday, August 9, 2016 9:23 PM

Sign in to vote

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 9, 2016 10:14 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

39

Sign in to vote

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

Sign in to vote

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

4

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

"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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Susan, have you got any response to your eta request yet?

Thursday, September 1, 2016 8:26 AM

Sign in to vote

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 1, 2016 10:06 AM

Thursday, September 1, 2016 10:04 AM

Sign in to vote

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 2, 2016 8:25 PM

Sign in to vote

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 3, 2016 9:56 AM

Sign in to vote

Also very surprised something so basic got through the Insider program???

Saturday, September 3, 2016 10:04 AM

Sign in to vote

Same problem here: workgroup of 1 2012R2 Standard Server and 3 Windows 10 Pro clients

Dario Palermo

Saturday, September 3, 2016 8:56 PM

Sign in to vote

Got the same problem here, is there any new solution out there?

Monday, September 5, 2016 8:57 AM

Sign in to vote

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 5, 2016 9:38 AM

Sign in to vote

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 5, 2016 9:52 AM

Sign in to vote

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 5, 2016 10:49 AM

Sign in to vote

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 6, 2016 6:53 AM

Sign in to vote

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 7, 2016 4:59 PM

Sign in to vote

Add me in as well. I have this issue in multiple locations. Turning off indexing isn't an option.

Wednesday, September 7, 2016 6:10 PM

Sign in to vote

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 8, 2016 8:20 PM

Sign in to vote

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 9, 2016 1:41 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

We have this same problem in our medium sized business network. i hope they fix this quickly!!!

Monday, September 12, 2016 9:43 AM

Sign in to vote

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 3, 2016 1:13 PM

Monday, September 12, 2016 2:41 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Build .187 with the same problem of SMB 3 :(

8 weeks without any fix -.-

Tuesday, September 13, 2016 5:57 PM

Sign in to vote

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

Sign in to vote

Checking on an ETA.

Tuesday, September 13, 2016 11:49 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Adding our company to the list.

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

Wednesday, September 14, 2016 4:48 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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:

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?
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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Is there an official KB article ID on this issue?

Saturday, September 24, 2016 12:59 AM

Sign in to vote

Adding ourselves. Exact same issue

Sunday, September 25, 2016 2:32 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Edited by Christoph_Huber Friday, September 30, 2016 7:28 AM

Wednesday, September 28, 2016 6:10 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Updated clients to 14393.222 this morning. Problem still persists. (Server 2012 Essentials with September rollup).

Friday, September 30, 2016 3:12 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

FINALLY fixed with KB3194496 released yesterday. Better late than never I guess.

Friday, September 30, 2016 8:55 PM

Sign in to vote

Did not work for me.

Friday, September 30, 2016 11:20 PM

Sign in to vote

I am having same issue even after installing KB3194496. Problem didn't get fixed.

Friday, September 30, 2016 11:27 PM

Sign in to vote

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 1, 2016 6:33 AM

Sign in to vote

ehclw, did the exact same thing as you and same situation, not fixed.

BullerTech

Monday, October 3, 2016 4:48 PM

Sign in to vote

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 3, 2016 4:56 PM

Sign in to vote

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 3, 2016 6:33 PM

Sign in to vote

"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 3, 2016 7:01 PM

Sign in to vote

gotcha, i have never had much success with acceptable speeds for searching files on the server anyway.

BullerTech

Tuesday, October 4, 2016 3:56 AM

Sign in to vote

The problem is still present for me, even after installing KB3194496.

Tuesday, October 4, 2016 8:02 AM

Sign in to vote

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 4, 2016 8:54 AM

Sign in to vote

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 4, 2016 10:48 PM
Proposed as answer by trav159 Thursday, October 6, 2016 4:07 AM

Tuesday, October 4, 2016 10:39 PM

Sign in to vote

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 4, 2016 10:52 PM

Sign in to vote

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 5, 2016 4:57 AM

Sign in to vote

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 5, 2016 8:34 AM

Sign in to vote

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 6, 2016 4:07 AM

Sign in to vote

" investigation is still happening"

Just so you know, this is still being investigated.

Friday, October 7, 2016 12:53 AM

Sign in to vote

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 7, 2016 11:56 AM

Sign in to vote

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 7, 2016 1:11 PM

Friday, October 7, 2016 12:26 PM

Sign in to vote

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 7, 2016 3:04 PM

Sign in to vote

" 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 7, 2016 9:49 PM

Sign in to vote

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 9, 2016 12:33 AM

Sign in to vote

Windows fast ring build, 14942 , problem still exists

neil donaldson

Monday, October 10, 2016 8:27 AM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Thanks for that!

Scott

Monday, October 10, 2016 7:09 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Problem still present after 14393.321 update.

Tuesday, October 11, 2016 7:31 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Same problem after the update 14393.321.

One time works, one time not.

Wednesday, October 12, 2016 9:24 AM

Sign in to vote

Thank you very much. Disabling Windows Search on server fixed immediately. Kudos.

Wednesday, October 12, 2016 12:02 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

4

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Same here, build 14393.321 is still broken! :-(

Ridiculous!!!

Friday, October 14, 2016 10:31 PM

Sign in to vote

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?

Edited by Adam von Gaertner Friday, October 14, 2016 11:55 PM

Friday, October 14, 2016 11:54 PM

Sign in to vote

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!

Edited by Christoph_Huber Saturday, October 15, 2016 3:43 PM typos

Saturday, October 15, 2016 3:42 PM

Sign in to vote

going back to 1511 would be enough ....;-)

Saturday, October 15, 2016 3:45 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Edited by neil_donaldson Wednesday, October 19, 2016 12:12 PM

Wednesday, October 19, 2016 12:11 PM

Sign in to vote

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

Edited by Julien Zweverink Wednesday, October 19, 2016 6:47 PM

Wednesday, October 19, 2016 6:27 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Anthony,

Where are we at on this?

Thanks,

James

Thursday, October 20, 2016 9:31 PM

Sign in to vote

Not yet fixed.

Thursday, October 20, 2016 9:50 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Same problem here, disabling windows search service fixes it for now.....!

Friday, October 21, 2016 2:24 PM

Sign in to vote

I have also confirmed this problem and the workaround of disabling the service "WSearch" / "Windows Search" on the server.

Also, I have found that:

The problem does not occur when using Explorer and a UNC path containing the IP address of the server.
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

Sign in to vote

Bump to the thread, still happening. Waiting for a fix. Disabling search as a workaround.

Friday, October 21, 2016 9:12 PM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Updated to Windows Server 2016. Seems to work here so far.

Sunday, October 23, 2016 8:19 AM

Sign in to vote

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

Sign in to vote

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

Sign in to vote

Same problem, disabling the search service helps but greatly impacts our fast searching.

Monday, October 24, 2016 10:00 PM

Sign in to vote

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

Sign in to vote

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

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

Sign in to vote

This is what Microsoft says (article is dated on 10/22/2016):

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

Tuesday, October 25, 2016 7:39 AM

Sign in to vote

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

Sign in to vote

are they saying that

You specified the no-cache option on the share.

if you do allow caching the problem goes away? i seem to remember trying this

a while ago and it didnt make any difference... but i might be mistaken.....

neil donaldson

Tuesday, October 25, 2016 8:26 AM

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

Sign in to vote

Wow - looks like I have at least 35 Windows 7 installs to do this weekend. I guess Microsoft's goal is to make as many people as possible regret ever installing Windows 10?

From the ridiculous way the updates are now handled to this problem I have many clients looking for something other than Windows 10. I suspect most will go back to Windows 7 until they can migrate to something else.

Way to go Microsoft.

Edited by MikeGreer1999 Tuesday, October 25, 2016 1:52 PM

Tuesday, October 25, 2016 1:51 PM

Sign in to vote

So Microsoft is now saying, if you made the mistake of putting your files on a Windows Server in your business, you are no longer allowed to index them for searching? What?!

Also, the 30 second delay is not correct. When creating a folder, it can take more than 120 seconds before the Explorer unfreezes.

What is Microsoft exactly proposing? That we no longer use Windows Server for storing our business documents (it is not possible to find a documents from tens or hundreds of thousends of files without indexing enabled unless you want to wait a looong looong time for each search to complete).

Is Microsoft saying we must pay for Microsoft cloud storage and store everything in the cloud, and search everything from the cloud? Or that we should store every file on every computer locally as offline folders/files, duplicating a massive amount of files to a huge number of computers? That is just ridiculous.

This is simply, totally unacceptable and just unforgivable.

Edited by Fredrik70 Tuesday, October 25, 2016 2:28 PM

Tuesday, October 25, 2016 2:26 PM

Sign in to vote

Wow. This is some major BS. Someone mentioned server 2016 does not have this issue. The KB states that the issue is present on server 2012 R2 and later. I'll have to test 2016 on my network then.

Tuesday, October 25, 2016 4:46 PM

Sign in to vote

ehclw the problem IS PRESENT in 2016 in the tests i conducted its exactly the same behaviour

so is it maybe that this is a feature now not a bug? has it been done by design to kill off windows search

the kb article makes no suggestion that a fix is being worked on

neil donaldson

Wednesday, October 26, 2016 9:28 AM

Sign in to vote

You specified the no-cache option on the share.

tried turning on allow caching - problem is still there, so this info is incorrect

also problem is still present in build 14955

neil donaldson

Wednesday, October 26, 2016 9:39 AM

Sign in to vote

Arrgghhh, I was hoping Server 2016 would solve this problem, and if so I would have done an inplace upgrade on our mail fileserver so that we can continue testing Windows 10 in our environment, but I see by previous comments that the issue still exists in 2016... As it is now, we have to stop testing Windows 10 as this is a pretty major issue and disabling the search service on our file servers is not an option (would take absolutely forever to search for files if they are not indexed).

Microsoft please get your act together!

Edited by trafsta2 Wednesday, October 26, 2016 1:19 PM

Wednesday, October 26, 2016 1:19 PM

Sign in to vote

The Microsoft Development team can verify this Problem on Windows 10 version 1607

Your welcome Microsoft...
This is what we told you very soon after you release RS1!

when the following conditions are true:

The server is running Windows Server 2012 R2 or later.
You specified the no-cache option on the share.
You configured the Windows Search indexer to index the local path on the server.
On the RS1 client, you use File Explorer to create, rename, or delete a Folder.

Everything are default settings by an Microsoft file Server with 2012 R2 or later...

Can someone confirm this issue with an Server 2012 non R2?
I think there was no index function on Default so you had to configure the feature
"Windows Search" by your own.
But is the issue there too?

If my theory is correct this is a client issue and so there is no fix for Microsoft Server,
they have to fix the client exactly Windows 10 Build 1607.

I hope we get a new build as soon as possible... with this issue we have to stay on 1511
for the next time.

Edited by R F S G Wednesday, October 26, 2016 1:29 PM

Wednesday, October 26, 2016 1:25 PM

Sign in to vote

Can someone confirm this issue with an Server 2012 non R2?
I think there was no index function on Default so you had to configure the feature
"Windows Search" by your own.
But is the issue there too?

We're running Server 2012 Datacenter (not R2) and we have the problem.

I believe that we configured Windows Search on our own (but I don't really remember). It still works fine on 1511 clients, but on 1607 Explorer freezes. Renaming via cmd or Total Commander works fine.

One thing I didn't notice earlier is this:

If use a W7 machine to create a folder on a network share, then W10 1607 can rename it without problems.

If use a W10 1511 machine to create a folder on a network share, then W10 1607 can rename it without problems.

If use a W10 1607 machine to create a folder on a network share, then W10 1607 freezes when renaming it.

So, it seems like the folder has to be created by 1607 for the problem to occur.

Edited by guranno Wednesday, October 26, 2016 1:53 PM

Wednesday, October 26, 2016 1:52 PM

Sign in to vote

I'm starting to think that Microsoft is deliberately allowing this bug to persist, in an attempt to punish customers who still use on-premises networks. Either that, or they want to punish customers who still use traditional file shares instead of SharePoint. What are we supposed to do if they don't patch this bug? They will eventually stop releasing security updates for 1511. I will NOT be strong-armed into changing my network topology. We will move away from Windows 10 (or from Microsoft) entirely before we do that.

Wednesday, October 26, 2016 2:27 PM

Sign in to vote

If use a W7 machine to create a folder on a network share, then W10 1607 can rename it without problems.

If use a W10 1511 machine to create a folder on a network share, then W10 1607 can rename it without problems.

If use a W10 1607 machine to create a folder on a network share, then W10 1607 freezes when renaming it.

So, it seems like the folder has to be created by 1607 for the problem to occur.

Yes, the problem occures only when using W10 1607 aka Windows 10 Anniversary Update. It affects folder creation, folder deletion and folder rename, in Windows Explorer on the client and File Save dialogue at least in Word, Excel from the client. After rebooting the client or server, it might work for a while, but a little later the delay will be back.

When Windows 10 was released, they killed the ability to search from the start menu if you keep your files on the server (worked perfectly in Windows 7). Now with anniversary update, they have effectively killed the feature to search files using indexing on a server (unless you are willing to wait 60-150 seconds per folder created/deleted). They want to be a business company but at the same time kill one of the most important features regarding file search on the Windows client. Why?!

Wednesday, October 26, 2016 2:31 PM

Sign in to vote

Also, that KB someone else linked actually has the gall to list the "cause" of this problem as the network admin turning on indexing on the server and enabling indexing of the share. That's kind of like blaming the victim, isn't it? The cause of this problem is Microsoft's faulty code.

Wednesday, October 26, 2016 2:44 PM

Sign in to vote

Anyone have any connections with someone at Microsoft that can give us the official word on this?

I have a law office client that would like something at least somewhat 'official' to cover his rear on moving back to Windows 7 until they can move forward with 'other' solutions. I have given him a link to this thread but he'd like a little more.

It sure sounds like Microsoft just isn't going to do anything to correct this screw-up. Hard to believe but that's what it looks like.

I have another office that has already informed all the users in the office that the office will be closed over the weekend to move back to Windows 7.... Just what I wanted to do after it was my recommendation that they go to Windows 10 back in July. I guess I've learned my lesson - thanks Microsoft.

Wednesday, October 26, 2016 4:01 PM

Sign in to vote

I'm seriously considering going back to 7.

I rolled back 9 of my users to pre-1607. The rest have already had it 10 days. (Really, MS...ONLY a 10 day Window???). 2 of those users did a reboot before going home. Can you guess what they came into again today???

"We've made some changes...."

OMG OMG OMG

I am really getting sick of MS lately. They make it so hard to be a fan. 2 steps forward... 3 back...

Wednesday, October 26, 2016 4:21 PM

Sign in to vote

OK, I'm finished griping. Has anyone on here worked with or looked into Windows 10 Long Term Servicing Branch? I'm fairly certain we wouldn't have ridiculous issues like this one under LTSB. However, if Microsoft follows their usual formula, the licensing costs are probably a deal breaker. Can anyone confirm how the LTSB licensing works? Is there an upgrade to LTSB, or do you have to buy all new licenses?

Wednesday, October 26, 2016 5:04 PM

Sign in to vote

I actually just had a thought after reading MS's "workaround".

From the very first line of the article:

"when they try to create or rename shared folders that they access through a UNC path"

My PC has been rolled back from 1607 so I cannot test this atm. Can someone try this:
Map your drive to

\\192.###.###.###\MappedDrive

and see if that works?!?!?

Edited by Tony Argh Wednesday, October 26, 2016 5:50 PM

Wednesday, October 26, 2016 5:50 PM

Sign in to vote

It absolutely happens on mapped drives.

Wednesday, October 26, 2016 6:46 PM

Sign in to vote

Still don't work for me with \\192.###.###.###\MappedDrive ... About 1min with "not responding"...Good job MS...

Wednesday, October 26, 2016 6:50 PM

Sign in to vote

Maybe when the Windows 10 creator's edition that was just announced today is released it will be able to create a new folder.

Wednesday, October 26, 2016 9:56 PM

Sign in to vote

Hello ehclw - I too am on 14393.321, and have seen the issues here (error 3b, hangs when creating new or renaming folders, and the very slow speeds that you mention). Interestingly, I find that by rebooting both systems on my Home network, AND rebooting the router, fixes the local network transfer speed issue for a while, but NOT the folder creation/rename issue. It is possible that arp/mac/dns refreshes that happen when all network devices get rebooted, will improve things for a while. I noticed the interesting Powershell command quoted in a previous post cycle: Get-smbconnection and that shows I am running Dialect 3.1.1 - so I assume that is what you get with one of the updates between the base 1607 and 14393.321.

This sort of network issue, plus the frequent hijacking of my "app defaults" after some rollup updates, just adds to the frustrations for WIN10 users, and certainly does not help the high "user experience" that Microsoft marketing would like us to have...

Thursday, October 27, 2016 2:35 AM

Sign in to vote

Just upgraded a win 10 pro client from 14393.321 to .351 and the issue is still occurring. I am testing on a file servers with 2012 R2 and 2016 standard ver. 14393.321.

Thursday, October 27, 2016 1:55 PM

Sign in to vote

It would be nice to get an official response form MS. Other then "Turn off Indexing".

Is "Indexing on Servers" officially no longer supported moving forward? ANyone have na idea how to get an answer?

I am Tweeting MS. lol Any other ideas?

Thursday, October 27, 2016 3:17 PM

Sign in to vote

I can also confirm this is STILL happening. Our company is running Windows Server 2012 R1 Standard. PLEASE FIX MICROSOFT!! Have disabled indexing for now, but this is NOT a good fix.

Thursday, October 27, 2016 4:44 PM

Sign in to vote

I think I have found what could be an acceptable workaround for me. If you open Indexing Options and click Pause Indexing, the problem goes away and you still have full search capability. The downside is that no new items will be indexed until indexing resumes. For me that is an acceptable trade off as long as it indexes new items nightly. However, the Pause button only stops indexing for 15 minutes at a time. So it's not quite a feasible solution yet without some sort of scripting and/or adjustment of the time period. I'm going to try this product out and see if it can help: https://www.autoitscript.com/site/autoit/

Thursday, October 27, 2016 5:58 PM

Sign in to vote

If that really works, someone could probably throw together a powershell script to pause indexing, then use task scheduler to fire it off at regular intervals.

I have not been able to reproduce your fix though.

Edited by AWBINDY Thursday, October 27, 2016 7:40 PM

Thursday, October 27, 2016 6:36 PM

Sign in to vote

If that really works, someone could probably throw together a powershell script to pause indexing, then use task scheduler to fire it off at regular intervals.

I have not been able to reproduce your fix though.

I have tested it several times on 2012 R2 and 2016 and Pausing Indexing always seems to fix the new folder issue while retaining full search capabilities. I have only tested it on one PC running 14393.351. I'll try it on a few more to confirm. The only info I found about controlling pausing the indexing, other than just manually clicking the button, is here http://stackoverflow.com/questions/1621736/how-to-start-stop-pause-the-windows-search-indexer

One of the suggested answers is to us an AutoIT script to open Indexing Options and click the Pause button. I guess this could be set to run every 15 minutes or so. I downloaded the AutoIT program but I have to learn how to do this.

Thursday, October 27, 2016 8:09 PM

Sign in to vote

Perhaps I'm misunderstanding things, but indexing can only be paused when an index job is running. If the server is in an 'indexing complete' status, then the pause button is grayed out. In this scenario, my clients still crash.

So, if you are right and the clients did work with indexing on the server paused, you would have to enable indexing at night so the server could get the index caught up, but somehow stop it again before it completely finished. If this process failed and the index finished building, your clients would start crashing again and the only thing you could do would be dump the whole index and start rebuilding it again which kind of defeats the purpose.

Also, could it be that with indexing paused, the server is simply not servicing index requests and the clients are reverting to a direct search, same as disabling the service?

Edited by AWBINDY Thursday, October 27, 2016 8:40 PM

Thursday, October 27, 2016 8:28 PM

Sign in to vote

Perhaps I'm misunderstanding things, but indexing can only be paused when an index job is running. If the server is in an 'indexing complete' status, then the pause button is grayed out. In this scenario, my clients still crash.

So, if you are right and the clients did work with indexing on the server paused, you would have to enable indexing at night so the server could get the index caught up, but somehow stop it again before it completely finished. If this process failed and the index finished building, your clients would start crashing again and the only thing you could do would be dump the whole index and start rebuilding it again which kind of defeats the purpose.
Also, could it be that with indexing paused, the server is simply not servicing index requests and the clients are reverting to a direct search, same as disabling the service?

You are right about the index button sometimes being grayed out. I am running into that issue now. It may be a hit and miss thing. I'll test some and see how it works out.

I am certain that even when indexing is paused, searching via the index is enabled. If I pause indexing on the server, folder creation works and search works as normal (fast and with file content searching). If I stop the windows search service entirely, and search with file content searching in non-indexed locations enabled on the client, it is very slow to show results as it then defaults to searching via direct non indexed search. Pausing Indexing does not pause the search service. Since this folder creation issue seems to be tied to the indexing somehow getting in the way when a new folder is created and renamed, it makes sense that pausing indexing would fix it.

Thursday, October 27, 2016 8:58 PM

Sign in to vote

hi

a bit off topic but we touched on it earlier

this is in the release notes for .351

Improved support for IT administrators using Group Policy to block users updating the operating system from Windows Update.

this probably should read "reinstated ", not improved, as it was totally broken

as i said earlier 1 user managed to update pc to 1607 build just by visiting windows update, even though all group policies were set to block it

looking now for details on what they have changed.....

neil donaldson

Friday, October 28, 2016 7:17 AM

Sign in to vote

This is getting a bit much now, 3 months down the line and MS still haven’t fixed the issue. I think we all realise that the development process is a time consuming one, and that they need to QA the fix to avoid exactly the same situation occurring, but with a key feature like this failing, you really would have thought it would be a priority. Starting to think that this ‘cloud first, mobile first’ attitude is coming at the expense of everything else. MS’ silence on the issue is just as bad. So it took a month and a half to acknowledge it with a KB article, which advises me to disable a key feature on my client’s networks, a feature that is in constant use. That’s not a work around, hell, that’s not even a bodge job… One of my client has in excess of 500,000 files, for which they constantly use search to find the file they are after. Perhaps MS would be so kind as to tell them they can’t use search, as I’m getting tired of taking so much flack for this (another bunch of phone calls today, ‘is it going to be fixed soon?’). I think MS don’t realise how fragile things are getting with some clients. A number of my clients were rather uncertain of upgrading to Windows 10, as 7 ‘just worked’, and clients crave stability, not ‘latest features’ above all else. So eventually the clients agree to upgrade to 10, then MS blows the trust out the water with this mess – and to compound the issue, I can’t even give my clients a vague approximation of when a fix may be available. Come on MS, COMMUNICATE!!!

Friday, October 28, 2016 5:54 PM

Sign in to vote

Add me to the list. I thought I was going crazy until I saw these posts.

Same thing. Wondows 10 1607 --> Windows Server Essentials R2.

Saturday, October 29, 2016 5:19 AM

Sign in to vote

As for my setup the problem seems to be solved. KB3197954 did it on Windows Server 2016 und Windows 10 1607. Both are setup with build 14393.351 now.

The above Statement was on error. I testet it on a clean System without having any offline filles activated. Now I noticed the error again even on this setup.

Now I have testet this with Windows Server 2012R2. It still does not work!

I do have now my client Windows 10.1607 Build 14393.351 and my Server 2012R2 Build 6.3.9600 with KB31292404 installed and have still this issue.

(But I'm happy for the setup with Windows server 2016 an latest build) No longer.

Edited by Andreas Hilmer Monday, October 31, 2016 8:07 PM

Saturday, October 29, 2016 3:05 PM

Sign in to vote

ABINDY and ehclw - this an interesting observation about the indexing. It occurs to me that a creation or rename of a folder would definatley trigger some sort of indexing update. Now I don't know the internals of this complex beast, but I suspect it would be more complex over a network, but in any event, would need some sort of "mutex" lock on the index blocks, so that it could update them in a safe and sane manner, without interrupts so it does not index a moving target. Relational databases have to be very careful about this sort of stuff, to preserve the data integrity in case of programmed or error triggered rollbacks, so choose to present active "selects" of data by using undo or redo blocks as conditions dictate. I don't think this basic search indexer needs the complexity of an RDBMS, but it should at least allow the user action to complete properly (create or rename a folder), without the SI taking over and stalling the completion. All they need is some sort of "dirty index block" flag somewhere, so that the index entry update for the new or renamed folder gets done when the item is not in active use. I get the impression that this SI "thing" was designed by a committee of disparate dev/prog teams, that did not really have a cohesive idea of what it should do, and what its possible weaknesses were, particularly in a dynamic, and mixed corporate environment, with different levels of server and client. This gives rise to environments that the test groups have not really tested properly, to iron out the inevitable bugs with this, especially with the fast-moving WIN10 updates altering function calls, and not realising the implications of larger server based indexing requirements. I hope this gets fixed soon, as even my small home network is affected by this.

Monday, October 31, 2016 1:05 PM

Sign in to vote

Hilmeran - interesting, thanks for the heads-up on KB3197954. That went into my WIN10 home systems a few days ago, so I will test this again in a day or so.

Monday, October 31, 2016 1:09 PM

Sign in to vote

I'll report back that 2016/10 appears to be working but 2012R2 is still broken.

(and yes tweeting to Microsoft will at least make you feel better)

Monday, October 31, 2016 7:20 PM

Sign in to vote

As for my setup the problem seems to be solved. KB3197954 did it on Windows Server 2016 und Windows 10 1607. Both are setup with build 14393.351 now.

Now I have testet this with Windows Server 2012R2. It still does not work!

I do have now my client Windows 10.1607 Build 14393.351 and my Server 2012R2 Build 6.3.9600 with KB31292404 installed and have still this issue.

But I'm happy for the setup with Windows server 2016 an latest build.

I just installed .351 on server 2016 and the issue is still occurring with a .351 client. Upon rebooting it didn't happen for a few new folder renames and I got optimistic, only to be let down once again as the problem started occurring again. Still not fixed here on 2012 R2 or 2016. Pausing Indexing still fixes it, but I have yet to find a way to keep the indexing paused. Trying some crazy stuff with an auto mouse click to try and keep it paused. Ridiculousness. I have found the fix and now Microsoft needs to implement it.

Monday, October 31, 2016 7:35 PM

Sign in to vote

ABINDY and ehclw - this an interesting observation about the indexing. It occurs to me that a creation or rename of a folder would definatley trigger some sort of indexing update. Now I don't know the internals of this complex beast, but I suspect it would be more complex over a network, but in any event, would need some sort of "mutex" lock on the index blocks, so that it could update them in a safe and sane manner, without interrupts so it does not index a moving target. Relational databases have to be very careful about this sort of stuff, to preserve the data integrity in case of programmed or error triggered rollbacks, so choose to present active "selects" of data by using undo or redo blocks as conditions dictate. I don't think this basic search indexer needs the complexity of an RDBMS, but it should at least allow the user action to complete properly (create or rename a folder), without the SI taking over and stalling the completion. All they need is some sort of "dirty index block" flag somewhere, so that the index entry update for the new or renamed folder gets done when the item is not in active use. I get the impression that this SI "thing" was designed by a committee of disparate dev/prog teams, that did not really have a cohesive idea of what it should do, and what its possible weaknesses were, particularly in a dynamic, and mixed corporate environment, with different levels of server and client. This gives rise to environments that the test groups have not really tested properly, to iron out the inevitable bugs with this, especially with the fast-moving WIN10 updates altering function calls, and not realising the implications of larger server based indexing requirements. I hope this gets fixed soon, as even my small home network is affected by this.

To translate - Microsoft is incompetent and can't fix their own product. Pausing fixes it. I have found the fix and now they just need a way to implement keeping the indexing paused for a greater length time. That would be an acceptable compromise to a terrible coding problem, but ideally MS should fix the root cause. Windows 10 Creators Update - You can now create folders without your computer not responding for a few minutes. And the crowd goes wild!

Monday, October 31, 2016 7:40 PM

Sign in to vote

In fact my test-installation was not that right. I had no Offline Files activated. I noticed this in real world.

So the error still is present even in my setup with Windows 10 1607 and Windows Server 2016 both latest Build. :(

Monday, October 31, 2016 8:03 PM

Sign in to vote

Very odd bug. I'm only managing a small network, but the issue appears on about 75% of the machines.

If disabling "Windows Search" didn't fix the issue for you (or that route isn't an option), what has worked for me on some machines is disabling certain context menu items. Getting rid of things from the Adobe product family, Google, WinRAR/7zip, etc.. Basically just disable anything you can live without. Trial and error netted positive results when disabling Windows Search wasn't enough to "correct" the issue.

I used ShellExView, but I'm sure whatever you have/can find will work just as well.

EDIT: This only temporarily fixed the issue on one workstation. I could create folders easily for either a short time, or only while the current Explorer window was open. Disabling the context menu items AND disabling the Search service was the only way to get this working smoothly on another workstation, however.

Edited by wil freeman Tuesday, November 1, 2016 5:12 PM

Tuesday, November 1, 2016 4:54 AM

Sign in to vote

I just installed .351 on server 2016 and the issue is still occurring with a .351 client. Upon rebooting it didn't happen for a few new folder renames and I got optimistic, only to be let down once again as the problem started occurring again. Still not fixed here on 2012 R2 or 2016. Pausing Indexing still fixes it, but I have yet to find a way to keep the indexing paused. Trying some crazy stuff with an auto mouse click to try and keep it paused. Ridiculousness. I have found the fix and now Microsoft needs to implement it.

It takes a long time for the indexing service to start, so after rebooting/reinstallation, you can create new folders normally for a while, until all the services have started on the server. So, nothing has been fixed and both Windows Server 2012 and Windows Server 2016 are broken. But I'm starting to think they just don't care, there as been zero communication from Microsoft about any kind of intention to fix it. Their solution is for businesses to turn off the file indexing according to their KB article.

Edited by Fredrik70 Tuesday, November 1, 2016 5:13 AM

Tuesday, November 1, 2016 5:12 AM

Sign in to vote

The root problem here is that Microsoft's brave new philosophy of rushing out major builds twice a year is fundamentally flawed. As someone else pointed out, when you make major changes to code, you need extensive testing to identify all the problems that will result from those changes and lots more time to correct those issues and then extensively test again. Microsoft thinks it can skip most of that testing overhead by relying on the user community ("insiders") to identify the issues, and then use their built in telemetry (spying) to prioritize only those issues that they think affect lots of people. Obviously this approach doesn't work. Windows is just too complex with too much legacy code to be handled like this. Heck, even Apple can't do it anymore: The last three major versions of IOS, although rich in new features, have been bug-riddled train wrecks at release. This flawed approach to software development HAS to stop.

Tuesday, November 1, 2016 1:24 PM

Sign in to vote

If you leave the Indexing Options window open, you can keep pressing pause. Setup a dedicated computer with an mouse click program https://www.murgee.com/auto-mouse-click/ and you are good to go. Or pay someone to click Pause every 15 minutes. Add that to your KB article Microsoft.

Edited by ehclw Tuesday, November 1, 2016 7:26 PM

Tuesday, November 1, 2016 7:24 PM

Sign in to vote

If you leave the Indexing Options window open, you can keep pressing pause. Setup a dedicated computer with an mouse click program https://www.murgee.com/auto-mouse-click/ and you are good to go. Or pay someone to click Pause every 15 minutes. Add that to your KB article Microsoft.

Pausing indexing vs disabling indexing both achieve the same results. No indexing occurs. Why pause indexing when you can just disable the service? And then turn the service back on once Microsoft fixes the bug?

Proposed as answer by BCT PRO Tuesday, November 1, 2016 10:43 PM
Unproposed as answer by BCT PRO Tuesday, November 1, 2016 10:43 PM

Tuesday, November 1, 2016 9:45 PM

Sign in to vote

Thinking about workarounds (not solutions):

Has anyone tried setting the priority on SeachIndexer.exe or SearchFilterHost.exe or SearchProtocolHost.exe.

Thinking out loud: if you increase its priority, it should complete faster. If you decrease priority to low, maybe it will stay out of the way?

Tuesday, November 1, 2016 10:47 PM

Sign in to vote

If you leave the Indexing Options window open, you can keep pressing pause. Setup a dedicated computer with an mouse click program https://www.murgee.com/auto-mouse-click/ and you are good to go. Or pay someone to click Pause every 15 minutes. Add that to your KB article Microsoft.

Pausing indexing vs disabling indexing both achieve the same results. No indexing occurs. Why pause indexing when you can just disable the service? And then turn the service back on once Microsoft fixes the bug?

If you disable the service, searching will get excruciatingly slow. if you pause, you can still utilize the index, except it won't find new files or changed files until unpaused.

Wednesday, November 2, 2016 7:28 AM

Sign in to vote

Our clients are experiencing the same issue - not only, if we disable indexing, Explorer.exe start crashing!

Error Event ID 1000, Application Error

Faulting application name: explorer.exe, version: 10.0.14393.206, time stamp: 0x57dacb32

Faulting module name: ntdll.dll, version: 10.0.14393.206, time stamp: 0x57dac931

Exception code: 0xc0000374

Fault offset: 0x00000000000f73f3

Faulting process id: 0x1f58

Faulting application start time: 0x01d225cda0b59400

Faulting application path: C:\Windows\explorer.exe

Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll

Report Id: 723e3898-6181-4f81-b136-c97327e60dac

Faulting package full name:

Faulting package-relative application ID:

DETAILS (Friendly View):

- System

- Provider

[ Name] Application Error

- EventID 1000

[ Qualifiers] 0

Level 2

Task 100

Keywords 0x80000000000000

- TimeCreated

[ SystemTime] 2016-10-14T04:22:48.437454600Z

EventRecordID 7613

Channel Application

Computer Win-10-1607-PC.domain.com

Security

- EventData

explorer.exe

10.0.14393.206

57dacb32

ntdll.dll

10.0.14393.206

57dac931

c0000374

00000000000f73f3

1f58

01d225cda0b59400

C:\Windows\explorer.exe

C:\WINDOWS\SYSTEM32\ntdll.dll

723e3898-6181-4f81-b136-c97327e60dac

Wednesday, November 2, 2016 7:53 AM

Sign in to vote

I was experiencing this issue with build 1607. The problem is related to Quick Access. If found this fix:

Display the File Explorer ribbon in any folder, navigate to View, and then select Options and then Change folder and search options. The Folder Options window opens.

uncheck “Show frequently use folders in Quick access.”

uncheck “Show recently used folders in Quick access.”

press “Clear”

This completely solved the problem for me.

Wednesday, November 2, 2016 11:33 AM

Sign in to vote

Not worked in our case.

We were unchecked already, just in case hit "Clear" without any impact on creating/renaming folders on network.

Wednesday, November 2, 2016 1:43 PM

Sign in to vote

uncheck “Show frequently use folders in Quick access.”

uncheck “Show recently used folders in Quick access.”

press “Clear”

doesnt fix problem for me either

i think the problem is, you trigger the error once, its then ok for that session or a period of time

so you may think changing something like this fixes it

its when you come back an hour later and try again the error reoccurs

neil donaldson

Wednesday, November 2, 2016 2:26 PM

Sign in to vote

I've been using a work around.

First of all, set Windows Search start in manual in Windows Services and Stop the service.

Next, create a BAT file in your hard disk with this code inside: sc start "WSearch"

Finally, use the Task Scheduler to execute this BAT file, the user who must execute this task is SYSTEM; program it when you know few people are going to use the server.

If your server is always on, to stop Windows Search Service simply make another BAT file with the code: sc stop "WSearch" and program the Task Scheduler to execute this BAT file.

Regards,

Wednesday, November 2, 2016 7:38 PM

Sign in to vote

Thinking about workarounds (not solutions):

Has anyone tried setting the priority on SeachIndexer.exe or SearchFilterHost.exe or SearchProtocolHost.exe.

Thinking out loud: if you increase its priority, it should complete faster. If you decrease priority to low, maybe it will stay out of the way?

I messed around with that. Kind of inconclusive results from what I remember. The processes kept reverting back to their defaults so I gave up on playing with that

Wednesday, November 2, 2016 7:43 PM

Sign in to vote

I have been struggling with this issue since we applied the Anniversary Update mid-October. I was hoping that the October 28th update KB3197954 would fix the issue. But the problem still persists.

However, today, I think I made a breakthrough.

The shares for the mapped drives all have offline files enabled. On a whim I went onto one of the Windows 10 1607 desktops and opened the Sync center. I noticed there were several issues there. After going to Manage offline files -> Disable offline files, and rebooting the computer everything seems to be working normally. Of course offline files are not available, but at least people can work again.

Wednesday, November 2, 2016 7:44 PM

Sign in to vote

I've been using a work around.

First of all, set Windows Search start in manual in Windows Services and Stop the service.

Next, create a BAT file in your hard disk with this code inside: sc start "WSearch"

Finally, use the Task Scheduler to execute this BAT file, the user who must execute this task is SYSTEM; program it when you know few people are going to use the server.

If your server is always on, to stop Windows Search Service simply make another BAT file with the code: sc stop "WSearch" and program the Task Scheduler to execute this BAT file.

Regards,

How does this help at all? You are stopping search and then starting it when no one is using the server, therefore making search useless. Might as well just disable it. I think the focus of this thread at this point is how to fix the issue of creating folders while leaving search enabled and running. Pausing the index is the closest answer I have come up with and the solution is messy. Pausing indexing will prevent new items from being indexed, but search will still work. This is far better than disabling search altogether. Don't pause it during non-work hours to index anything new on the server from that day. Generally searching is done over old items anyway and it can take some time index new items so I never expect immediate results from new items.

Edited by ehclw Wednesday, November 2, 2016 8:00 PM

Wednesday, November 2, 2016 7:58 PM

Sign in to vote

I have been struggling with this issue since we applied the Anniversary Update mid-October. I was hoping that the October 28th update KB3197954 would fix the issue. But the problem still persists.

However, today, I think I made a breakthrough.

The shares for the mapped drives all have offline files enabled. On a whim I went onto one of the Windows 10 1607 desktops and opened the Sync center. I noticed there were several issues there. After going to Manage offline files -> Disable offline files, and rebooting the computer everything seems to be working normally. Of course offline files are not available, but at least people can work again.

Travis,

I tried disabling offline files and rebooting but this did not do anything for me, I still am consistently having the issue.

Wednesday, November 2, 2016 8:59 PM

Sign in to vote

Virtually without exception I am having to roll back all our customer W10 workstations to previous build!

This upgrade should be optional. I have customers coming into work in the morning and having to wait for an hour before they can touch their pc because of this update! Then after it breaks everything they have to wait for it to roll back.

Apart from the network folder issues we are having loads of problems with devices. The latest customer issue was that windows wouldn't see any of their printers - the problems couldn't be fixed either by HP or Samsung. After messing around for ages we ended up rolling back. And automagically everything worked again...

We are now delaying upgrades for 8 months on all our customer W10 stations....

I think this is So rude!

Thursday, November 3, 2016 8:40 AM