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

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.

We ran into this same problem and going from notes here we hacked a different band aid into the logon script (this is hokey at best and I've got far worse ways to describe this...)

We added a sleep statement at the top of the logon script which delayed the drive mapping, this (so far in testing) appears to work for all of the workstations we tested on.  Simply add the timeout command to the top and see what you get.  Your experience may vary...

timeout /t 60

I to am experiencing the same issue.  Although in my situation we have an older Windows 2003 server that uses SMB1.  All the way up to 1909 the PCs connected fine.  When installing 2004 on 4 different machines the logon scripts took about 15 minutes to complete and when finished most drives were inaccessible.  Windows Explorer shows a progress bar and most drive mappings are shown as disconnected.  

I found that running the command "net use * /d /y"  BEFORE rebooting, the script ran fine on the next boot, it ran in less than a second and all drives showed connected and were accessible. However subsequent reboots caused the same issue UNLESS proceeded with the UNmap command. 

We have a bunch of drives mapped to various server - NONE of the rest are to a Windows 2003 server.  I UNMapped JUST the drives to the Windows 2003 server leaving those to 2008/2012/2016 servers, and on the next boot the script ran instantly and all drives are connected properly.  

This is somehow caused by the SMB1 connection.  I am unable to experiment with the logon scripts because only a select few in security are allowed to modify them.

Try doing that on all machines in your domain.

No. That's not a solution. It's a band-aid.

The purpose of using logon scripts is doing things only once.

I've tried GPO but for some reason - maybe because it's an old domain - it doesn't work with Windows 10, compliments of MSFT.