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

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 have a similar problem with two venerable Dlink NAS boxes using SMB1 (SMB1 is enabled).

The devices have worked for over a decade and there are no signs of hardware or network failure.

(A new Synology NAS works perfectly).

From months of testing and fiddling with settings, I confirm that these devices always fail to connect after a cold boot, with (wrong) message "The local device name is already in use".

They always reconnect and work correctly after a restart (or logout/login).

Changing from devices name \dlink-...\volume_1 to IP address \192.168.0.99\ makes no reliable difference.

The 2004 (and 20H2) updates has created some deadlock that causes this very annoying behaviour.  Microsoft - please fix it.

I'm also having these issues with a NAS and drive mappings after 2004. Was working right after upgrade until that first restart. Had to disconnect drive mappings and remap, which is fine until you reboot and have to do it all over again. Rolled back to 1909 and all is well. I also had SMB 1.0 enabled.

Hi!

So the proofs pile up; it is really a problem in version 2004.

Each time I upgrade a machine from 1909 to 2004 the problem starts.

I've been doing all kinds of experiments. Initially disabling Direct SMB appeared to solve the problem but it must have been just an occasional fluke, because the next time it occurred again.

It appears to have something to do with timings.

I guess we have to wait until someone at Microsoft realizes they broke something and decides to patch the OS.

This worked for me: create a scheduled task that launches this command at boot: "net use \your_server_or_NAS" (without quotes) and reboot.

All the mapped drives should be working again