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

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.

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. 

Hi!

So the proofs pile up; it is really a problem in version 2004.

Each time I upgrade a machine from 1909 to 2004 the problem starts.

I've been doing all kinds of experiments. Initially disabling Direct SMB appeared to solve the problem but it must have been just an occasional fluke, because the next time it occurred again.

It appears to have something to do with timings.

I guess we have to wait until someone at Microsoft realizes they broke something and decides to patch the OS.

I've posted this issue on various forums, MS Technet included.  I either get NO answer or simply get ragged on for daring to use such an old protocol on a 17 year old OS.  Admittedly that's the answer to those having the issue for regular MS OS's like 2003, it won't fix the issue to those using older SAN hardware that can't be upgraded. 

I fear we will never get this issue resolved, it will instead fall to us to replace hardware / OS software to make the issue go away. 

We have the same problem.

I hope MS resolve it asap.

Any chance you are using Guest access on your NAS and you need to change the following key and restart your PC/laptop?

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

"AllowInsecureGuestAuth"=dword:1

https://support.microsoft.com/en-us/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser

Any chance you are using Guest access on your NAS and you need to change the following key and restart your PC/laptop?

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

"AllowInsecureGuestAuth"=dword:1

https://support.microsoft.com/en-us/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser

No chance.

Each user has its own credentials.

And as the article points out, that occurs in Windows 10 version 1709 and later, but in our case the problem started only with version 2004.

But thanks for the suggestion.