Why is Windows 10 Version 2004 preventing logon scripts from mapping NAS drives at first logon attempt?

I thought of that with a minor variation. We have only one 2003 server that this issue is causing, an loads of other network drives mapped by individuals that aren't on this server.

So I unmapped individual drives reflecting those that are on the 2003 server.  

THis is still taking way too much time, the unmapping takes about 10 minutes to run.  

I know the ultimate remedy is to replace the 2003 server.  However this isn't an option now.  It's on a VMWare cluster that shares a SAN and there is insufficient room to create a replacement.  The thing is 32 bit as well, so no inplace upgrade path. And I'm not on the team to do the replacement either. 

I just hope the company replaces it before either 2004 is forced upon us or they elect to update users computers to it despite my warnings not to.

Sorry to hear that, unfortunately we don't have any more servers 2003/2008 servers with file shares for me to be able to troubleshoot and help with a solution. It must be something to do with the security vulnerabilities of SMBv1, MS is forcing everyone to upgrade. How i came across my fix was to disable SMBv1 on the client side and when trying to open the mapped drive i received the below error:

 - This is what led me to enabling SMBv2 on server side. So id suggest upgrading to server 2012 r2 or higher and enabling SMBv2/3.

Had the same issue after 2004 update, mapped drive on windows server 2012. Found the fix a moment ago, enable smbv2 protocol with the following powershell command :

Set-SmbServerConfiguration –EnableSMB2Protocol $true

• shame on microsoft for having us suffer this long!!

This worked for me using an old NAS.

Edit - Actually I take that back unfortunately it does not work for me.

I just tried this on my system, it does not work :)  In my case it is a Windows 2003 server.   The real solution is to get rid of the 17 year old OS.  However I am stuck between a corporate rock and a hard place and can't update it. 

I am experiencing the same issues, logon scripts won't run in less than 20 minutes and the persistent connection swill always fail.

What is really baffling is that it will run OK the FIRST time after all the connections are removed (net use * /d /y) .  But if you forget to blow the connections off before rebooting your're stuck again with no access and glacial logon scripts.

Hopefully your fix will help some of the people that have access to SANS.

Add another one to the list...

In my case a 2003 Server is at the center of my universe: roaming profiles + redirected folders + standard shares + logon scripts

I spent one day trying to mitigate the problem, but couldn't find anything which really works.

I disabled any logon script trying to connect shared folders, created the persistent connections manually, and started a series of reboots to see if the automatic reconnection of the persistent connections was working. Well, no, it doesn't work 100%. Sometimes the connected drives are setup properly, sometimes they are present but unavailable (and Explorer hangs with the green progress bar), sometimes I logon to a black screen which lasts forever, until I disconnect the network cable and interrupt the hanged connections to the 2003 server. I think that the "logon to black screen" happens when folder redirection fails, but I'm not sure.

Since all of this happens randomly, even without any attempt to create / recreate the connections via scripts, I'm heavily banging my head on the wall...

I tried to move the logon scripts to a different server (not 2003), I changed every "short" reference to the 2003 server into a FQDN (because it looks to me that using FQDNs slightly raises the chances of a successful logon), but these are not valid workarounds.

One strange discovery is this: in an attempt to understand what's going on, I changed the VBscript I've been using for years so that it just prints the connections it finds, without any attempt to change them. Well, what really puzzled me is that in the context of execution of the script there is no connection defined at logon time... I "evolved" the script into a fully diagnostic tool :-) by writing a batch:

run the script

wait 90 seconds

run the script 

Even at the second run, no connection is listed, although I have the time to open and verify in Explorer that there they are, and working. As far as I know the script runs in the context of my account, so if I can see the connections in Explorer the script should see them as well, but no, no connection is listed. While, if I run the script manually from the command line, it lists connected drives properly. The VBscript is very standard, it uses WScript.Network and enumNetworkDrives to list connected drives, it's been working since we got the 2003 server, I also disabled fast logon to be sure that network is setup properly when the script runs, yet it lists nothing...

At the moment I'm giving up: luckily I stopped the 1909 -> 2004 upgrade almost immediately, so I have just 2 machines to deal with, but I'm afraid that it's not a matter of waiting the next Patch Tuesday and that MS will not solve this one, since it is apparently involved with that black beast of SMB1...