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

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.

Well, guys it's been (not) fun working with you all on this issue.  I have to bid you all adieu.  After me fussing and fuming about this issue to management, my company finally allocated the resources to build us a new Windows 2016 64 bit server and we migrated the data to it.  So this is no longer an issue for me as we no longer have any SMB1 servers left.  

MS has clearly stated in it's complete silence on this and a few other forums that it will NEVER address this issue and the only route we have to a real fix is to update the servers.  For non MS SMB1 devices this is still an ongoing issue.  

The bit of script I describe above works well to remove the registry keys for all drive letters.  So even if your users map their own drives to these old servers, the script will remove the key and prevent it from stalling the logon process and make the shares immediately accessible.  When I was using it I put this at the head of the script before the map commands and again afterwards so that the registry key was gone no matter what. 

So, good luck all.

OK , still not a fix and we are just supposed to update the servers to eliminate this issue.  So for those of you stuck for whatever reason using Windows server 2003 or an old NAS that only does SMB1 then we are on our own to find a kludge to work around this issue.

I have over 100 users on this server. I know MOST of the drives they have mapped but if a user has one (or more) I don't know about or adds one manually then we are back at the stalling an disconnect issue.

The overall bypass for me is to eliminate the UseOptions key for ALL network drive letters.  I tested this with mappings to LATER server (2008 - 2012) and removing this reg key NOT will cause issues with drive mappings as far as I can tell, I would appreciate if someone would also test this to make sure.  I do not have anything later than 2012 to test. 

The below script will march through all the drive letters and delete the UseOptions key for every drive letter a-z.  Park it at the top of your logon script to delete them ahead of NEW or refreshed mappings.  The drive mapping recreates the registry key, so you may want to run it again at the BOTTOM of your logon script - not sure about this.  I did it at the TOP to delete any that may be there and again at the bottom to delete those just made.  AFAIK it creates the reg keys only in lowercase letters.  

Please let me know how this works for you people.  

@echo off

setlocal enabledelayedexpansion

::65,1,90 for Capitals

::97,1,122 for small

for /L %%A in (97,1,122) do (

cmd /C exit %%A

call set char=%%^=ExitCodeAscii%%

reg delete HKCU\Network!char! /v UseOptions /f

)

endlocal disabledelayedexpansion

Put your drive map commands here.

Sorry, I have not check on this thread in quite a while.  MS is still silent on this, I suspect they will provide NO solution and the only real fix is to update or replace the offending server.  In my case we have no room on the virtual Host to replace the server and the company will not buy us new equipment to replace it.  So we are stuck with a Windows 2003 32 bit server.  

I used the script as follows.  I put these lines BEFORE the scripts NET USE command to map out the drives.  The letter after the 'HKCU\Network' portion of the line is the drive letters being mapped by the following (not shown) NET USE commands.  

This still is not a good solution.  It does not fix any mappings a user might have set themselves as I have no idea what they are.  So the hanging still occurs when those drives are missed.    It also will not fix the issue for people outside our corporate site who map drives to our server as I have no idea who the are, what letters they are mapping. Each of our sites uses it's own logon script and will not run ours - which I fixed. 

REM Windows 10 update 20.04 introduced a new key and value, it does NOT work on 2003 servers

REM The below commands delete the value and key. 

REM Without deletion the script wil take 10 minutes to run and connections will not work 

REM Only necessary to run on Windows 2003 mapped drive letters

reg delete HKCU\Network\h /v UseOptions /f

reg delete HKCU\Network\j /v UseOptions /f

reg delete HKCU\Network\n /v UseOptions /f

reg delete HKCU\Network\w /v UseOptions /f

For the hell of it I put the SAME commands at the BOTTOM of the script so that the keys are again deleted AFTER the mapping creates them. 

If someone can recommend a way to delete ALL the subkeys that represent the drive letters specified in the HKCU\Network  portion of the command.  An asterisk (*) does not work as a wild card and marching through ~26 letters of the alphabet does not seem smart.

A few days back I posted an "old" NAS (D-Link and IOMEGA) versus a "new" NAS (QNAP) drive mapping problem here:

https://answers.microsoft.com/en-us/windows/forum/windows\_10-networking/nas-network-mapping-fails-after-update-to-windows/db47fd74-6e0b-4e0a-87c2-6a870f673aac?messageId=25e1dbc2-cbb8-4b21-8a42-f04929ff10dd

After studying the posts here, I believe the fact that the old NAS are over 10 years old, whereby the QNAP is fairly new, mirror what is described here, e.g. the server2003 problems.

I have also identified the "UseOptions" registry key as an essential difference between 1909 and 2004 / 2009.

I have studied the logon script solutions here but I am not an IT professional. Would anyone be able to provide me an idea how the "net use / REG DELETE" script would have to be written to workaround the mapping problem?

Many thanks!