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: Oldest
  1. Anonymous
    2020-07-24T13:29:02+00:00

    I just tried this on my system, it does not work :)  In my case it is a Windows 2003 server.   The real solution is to get rid of the 17 year old OS.  However I am stuck between a corporate rock and a hard place and can't update it. 

    I am experiencing the same issues, logon scripts won't run in less than 20 minutes and the persistent connection swill always fail.

    What is really baffling is that it will run OK the FIRST time after all the connections are removed (net use * /d /y) .  But if you forget to blow the connections off before rebooting your're stuck again with no access and glacial logon scripts.

    Hopefully your fix will help some of the people that have access to SANS.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2020-07-24T14:29:47+00:00

    Had the same issue after 2004 update, mapped drive on windows server 2012. Found the fix a moment ago, enable smbv2 protocol with the following powershell command :

    Set-SmbServerConfiguration –EnableSMB2Protocol $true

    • shame on microsoft for having us suffer this long!!

    This worked for me using an old NAS.

    Edit - Actually I take that back unfortunately it does not work for me.

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2020-07-27T07:13:44+00:00

    Sorry to hear that, unfortunately we don't have any more servers 2003/2008 servers with file shares for me to be able to troubleshoot and help with a solution. It must be something to do with the security vulnerabilities of SMBv1, MS is forcing everyone to upgrade. How i came across my fix was to disable SMBv1 on the client side and when trying to open the mapped drive i received the below error:

     - This is what led me to enabling SMBv2 on server side. So id suggest upgrading to server 2012 r2 or higher and enabling SMBv2/3.

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2020-07-27T22:26:26+00:00

    A partial work-around:

    I added

    NET USE * /DELETE /YES

    to the top of the login script. Issue seems worse if the mapped drive already exists. Impatient people reboot, and it works 2nd time (no mapped drives).

    For people that follow instructions:

    I added a line to copy a simple batch file to their desktop called ReBoot.bat with:

    @ECHO OFF

    ECHO *** Press ENTER when all programs are closed, system will reboot ***

    PAUSE

    NET USE * /DELETE /YES

    SHUTDOWN /R /T 20

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments
  5. Anonymous
    2020-07-27T22:55:34+00:00

    I thought of that with a minor variation. We have only one 2003 server that this issue is causing, an loads of other network drives mapped by individuals that aren't on this server.

    So I unmapped individual drives reflecting those that are on the 2003 server.  

    THis is still taking way too much time, the unmapping takes about 10 minutes to run.  

    I know the ultimate remedy is to replace the 2003 server.  However this isn't an option now.  It's on a VMWare cluster that shares a SAN and there is insufficient room to create a replacement.  The thing is 32 bit as well, so no inplace upgrade path. And I'm not on the team to do the replacement either. 

    I just hope the company replaces it before either 2004 is forced upon us or they elect to update users computers to it despite my warnings not to.

    Was this answer helpful?

    0 comments No comments