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

Anonymous
2020-06-06T22:33:25+00:00

Since we updated Windows 10 to Version 2004 that all the machines in our domain stopped mapping NAS drives at first logon.

When the users start the machines and logon the logon script maps correctly the drives in several servers but not in the NAS.

If they logoff and logon again then the mapping is done correctly.

The problem occurs sistematically and started only after Version 2004 was installed.

It has nothing to do with SMB 1.0 being enabled - it was already enabled before Version 2004 as it was needed because we are talking about an old NAS.

Direct SMB appeared enabled and we disabled it, but it didn't solve the problem.

Windows for home | Windows 10 | Internet and connectivity

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

42 answers

Sort by: Most helpful
  1. Anonymous
    2020-11-19T15:07:46+00:00

    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.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2020-11-09T06:15:47+00:00

    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!

    Was this answer helpful?

    0 comments No comments