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

This helped me, thank you.  Shares that were being mapped were on Server 2019.

I had already NET USE * /DELETE /YES persistent: yes

What resolved the issue for me was to remove persistent: yes

I think I found a valid workaround for my scenario, which involves a 2003 Server.

From my tests, the problem is not caused by the logon scripts, but from using PERSISTENT mapped drives. During logon, when Windows 10 tries to automatically reconnect the persistent , 2003-based drives (no script involved!!!!), the reconnection fails/hangs, the drives become extremely slow, the user session is slow and malfunctioning and, in the worst case, takes several minutes of black screen before showing the desktop.

Consider that in my case I use the 2003 server in several ways: DC, shared folders, redirected user folders, roaming profiles (yes, I DO know that there is something wrong here... :-) ), so the effects of hanged connections to the server are exacerbated (for example, the 10 minutes of black screen at logon).

The workaround I found has allowed more than 10 successful restart + logon in a row, so I think it is a valid one (in my scenario at last)

TLDR;

In your script, AFTER the creation of persistent, 2003 based mapped drives, add 

REG DELETE HKCU\Network<DRIVELETTER> /v useOptions /f

for each of your persistent, 2003 drives.

IMPORTANT: If your script does not recreate connections when they are already existent, add the instruction nonetheless, because the useOptions value is recreated at each logon if it's missing, and it appears to be the cause of the problem.

Longer version

What I think is happening is this:

• when initially creating a persistent connection (eg: NET USE W: \server\share /persistent:yes), Windows saves it to HKCU\Network <DRIVELETTER>. Among the other values of the key, it creates useOptions but fills it with some WRONG values for 2003-mapped drives
• at next logon, Windows reads HKCU\Network, and tries to use the WRONG useOptions , causing connection hang
• (the workaround), if, at next logon, useOptions is missing, Windows connects successfully, but recreates userOptions with wrong values: this is why it is necessary to delete it at every logon, otherwise at next logon the reconnection would hang again

Having spent an afternoon (and not the first!) on this problem, I didn't investigate too much, but it looks that useOptions has been introduced with 2004. I checked a 1909 machine, and useOptions is not present. 

useOptions is created for every mapped drive, not only for 2003-based ones. For 2008-based drives it contains different values. I searched for documentation but couldn't find anything.

Last thing: when should

REG DELETE HKCU\Network<DRIVELETTER> /v useOptions /f

be run? AFTER Windows has automatically recreated persistent connections (and thus recreated the wrong useOptions).

In my environment I use 

Computer Configuration

  » Administrative Templates

    » System

      » Logon

        » Always wait for the network at computer startup and logon

and I've found that, with so-called fast boot deactivated, when logon scripts run, the useOptions value has already been recreated. BUT, to be extra sure, instead of deleting the values from registry in a logon script, I'm deleting them a bit later, using a .cmd in 

User Configuration

  » Administrative Templates

    » System

      » Logon 

        » Run these programs at user logon

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.

A partial work-around:

I added

NET USE * /DELETE /YES

to the top of the login script. Issue seems worse if the mapped drive already exists. Impatient people reboot, and it works 2nd time (no mapped drives).

For people that follow instructions:

I added a line to copy a simple batch file to their desktop called ReBoot.bat with:

@ECHO OFF

ECHO *** Press ENTER when all programs are closed, system will reboot ***

PAUSE

NET USE * /DELETE /YES

SHUTDOWN /R /T 20

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.