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

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

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.

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 :-)

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?