"Could not connect all network drives" upon login after new server

My office runs all Windows 7 x64 machines connected to a Windows server using Active Directory in a domain environment, using login scripts to map 3 drives X, Y and Z.

For many years we were using a Windows Server 2003 x86 server box. This past weekend we made the switch to a new 2012 R2 x64 box, and the login scripts were adjusted to add a 4th drive letter U for each user's own personal folder. The login script has the U drive mapped by connecting to \\server\share\%username%.

The problem now is that EVERY time any workstation restarts or logs out and logs back in, the "could not connect all network drives" balloon pops up. But when clicking on the balloon, Computer shows up with all 4 network drives properly connected.

I have looked at this thread: A Solution to Could not reconnect all network drives but I don't see why this would have just started happening when switching to this new server. I almost never saw that message on any machine before, when using the old server and mapping 3 network drives.

I don't mind doing the registry edit on each machine to suppress that message, as we only have about 10 machines in the office. But I'm wondering if there's something else causing this to happen now and not before the switchover?

I do not know why this happens after moving to 2012 server, but we see it too :-(

You can:
1) live with it
2) suppress the message (your link)
3) delay the appearance of the desktop
4) find another solution

The solution that you pick should depend on the problems (if any) that are caused by not having a network connection to a mapped drive. For us, the network drive connection is not re-established until the user clicks on the drive letter via Windows (file) Explorer. This created a problem for an application that we use. Embedded in that app are paths to files on the mapped drive. If there is no network connection to the mapped drive, the app would throw an error - stating that the files do not exist. This confused those using the app. The work around is to open Windows (file) Explorer and click on the mapped drive to re-establish the network connection - then retry the app.

We also had some things that ran at start up and needed that network connection to the mapped drive.

Because of those issues, we oped for solution #3 from the list above. However, that "solution" added so much delay to some of the computers during boot time, that we removed it and we are back to option #1. Those using the app still get confused, but they eventually figure out why the app cannot find the file. For the start up items, we moved files to each computer so as to not depend on the server.

This is just one of the many stupid things that Microsoft does...
...making us waste hours and hours chasing solutions.

Thanks for that Option 3 link, I may look into that.

You are welcome.

Perhaps the delay will be tolerable for you. For some systems, it added more than 2 minutes to the boot time. Maybe you will see no noticeable delay on your relatively small network.

Well this is odd, the registry key and value listed in your link above does not exist on my Win7 workstation.

The keys will not be there unless you manually create them or use GPEDIT.MSC to create them.

The Group Policy Search website that I linked to offers the path to follow in GPEDIT:
Computer Configuration\Administrative Templates\System\Logon\







For those that do not have GPEDIT, the website offers the registry path too:
HKLM\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon




I have attached the setting as a reg file...
...in case you want to take that route.

Ah yes, I found it in GP Editor, changed that setting to Enable, then restarted. Still said could not connect all network drives.

Perhaps that GPO setting only helps with drives that were manually mapped - not mapped via log on script.

I'm not sure what else to try.