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

Well, I've rebooted my test system and have found that the above reg deletion does NOT fix it 100%.  Occasionally on logon the scripts still stall and take ~10 minutes to complete.   It's happened to me twice in maybe 20 reboots.

I took almost a week, but I finally got the logon script changed.  Politics!  Pah!

I put the REG delete commands at the head of the script for the 2003 server mappings, I also stuck it on the end should the NEW mapping command recreate it. 

It works, but is not a real fix.  Any YES, I know replacing the 2003 server is the way to go. Still working through that issue.

Since our sites logon scripts are site specific this won't fix users who are mapping drives to the 2003 server from the WAN. If the update to 2004 they are going to not likeit.

This also will not fix any drive mappings that a user has created manually.  If they map to this 2003 server and that mapping creates the UseOptions key and value they are going to be in trouble.

So, I don't look forward to what's around the corner at my work.  This is not going to be fun. 

Has anyone heard from Microsoft about this issue anywhere else?  I imagine they are not too interested in fixing this issue. 

Does anyone know what this value in UseOptions actually does?

Not related to the main topic, I apologize, but... very old school VBScript will let you check mapped drives with 5 lines of code, add 5-10 more to intercept those you want to delete / fix

https://www.devguru.com/content/technologies/wsh/wshnetwork-enumnetworkdrives.html

Powershell will probably be even more compact. 

Regarding the server: I'm also in the eternal process of replacing it... Maybe I WON'T tell the managers that its conflict with 2004 has a workaround, after all :-)

Thanks AndreaRiva1. An amazing find. One main issue I have is that I have over 150 computers to do this to once I get them on 2004.  

I elected to put all the reg deletions at the head of the logon script.  That way the map command below it will run OK. To make sure it removes them after the MAP commands run I also put it at the bottom of the script.  So elegant! NOT!  

Oddly enough, it appears the the second REG DELETE command at the bottom fails because the TOP set of commands has deleted it.  I thought the keys and values were created from the results of the MAP commands?   Does. Not. Make. Sense. 

It seems to work.  I reran the old script on multiple boots to get the problem to rear it's ugly head, then ran the modified script to make sure it cleared it up.  Looks like it does.  

I have about 150 PCs that use mapping to this server, many of those with multiple users.  Using a startup script on the systems didn't seem the best way to go.

I WILL have to deal with people who have added drive mappings manually to other resources on the server, as well as people not at this site who connect over the WAN.  Jeez, this is gonna be fun  😜

I've been trying to get this server replaced for 10 years.  The last 2 years it's been budgeted and then cancelled.  I guess the thinking is if a 17 year old OS isn't broken then it doesn't need fixing.

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