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

Same issue here, took over a client that has a 2003 server and purchased a bunch of Win 10 machines, all machines were on a workgroup before but I wanted to fix that and put them on a domain. Well much to my surprise when I set a logon script it connects fine the first time by name and maps but then you reboot it it cant connect by name but can by IP, so as a test I mapped the drives by IP then reboot and wouldn't you know the next time it wont connect by IP but it will connect by name. Reboot again and the opposite happens. Went over this post and tried everything and yes I do have SMB v1 enabled.

i just installed Windows 10 20H2 (October update).

It has the exact same issue, so no fix there either.

MS is silent on this issue.  In ONE forum they closed the thread stating 'Update your server's OS' as the solution.  

I'm harping to my companies powers that be about this, and it looks like there is no money to replace our server.  And it WILL require replacement as it is so old that it will not support anything newer. It's 32 bit so no upgrade is possible.

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!

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.

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.