Mapped network drives have always been a buggy area in Windows, probably at least in part because they are still linked to a DOS namespace. From MSDN:
On Windows Server 2003 and Windows XP, the WNet functions create and delete network drive letters in the MS-DOS device namespace associated with a logon session…
Whatever the reason, it is commonly reported that mapped network drives appear as ‘disconnected’ in Windows Explorer (or ‘unavailable’ via net use), and that programs that attempt to use these drive mappings will fail until the user physically clicks on the drive letter in Windows Explorer. Only this user-initiated action will restore the connection and allow other programs to successfully read from the drive letter.
This is a BIG problem!
I initially thought that the mapping of the network drives was being done before some required services had started (such as the Workstation and Server services), so I wrote a program to run on startup that attempted to map a drive and logged all the currently running services if it failed. It would keep trying to map a drive until it succeeded. I hoped it would show me which services needed to be running in order to map a drive, after which I would write a program to wait for those services before attempting to map anything. But, much to my amazement, I found that when the initial drive mapping failed and a subsequent attempt succeeded, the set of running services had not changed! So I could only conclude that there was another element in the equation. After thinking about this for a while, and reading this post, which indicates that Microsoft is apparently trying to address this, I decided ‘stuff it’, I’ll just write something that I know will work and is simple.
So I’ve written a small executable called MapDrive.exe to ‘work around’ this problem, described on the following dialog:
Now as you may know since Vista, there is the concept of a split user token, and mapped network drives apply to only one token, so if you map drives as a standard user and then run an elevated process, those network drives are not available to the elevated process. This behaviour is documented by Microsoft, however the solution they offer is both unsupported and unsafe. Other solutions have been proposed here. If you don’t wish to use any of these solutions, you can do this:
1. Run MapDrive.exe as a shortcut from your Startup folder. This will map drives for the standard user token.
2. Run MapDrive.exe as a local group policy logon script using gpedit.msc. This will map drives for the administrator token.
Note: After using this program, you may still see the above balloon popup, simply click the spanner icon, and select ‘Hide icon and notifications’ for ‘Windows Explorer’.
Download the utility for free here.
UPDATE: A few people have asked how to use this program. As stated above, there are two ways, depending on whether you need drives mapped for standard users or admins. If you don’t know what you need, you probably just need to do this for standard users. Here are the steps for both:
1. Copy MapDrive.exe to somewhere on your local hard drive.
Standard Users:
2. Right-click MapDrive.exe and choose ‘Create Shortcut’. This will create a file called ‘MapDrive.exe – Shortcut’ next to MapDrive.exe. Now go Start->All Programs, right-click the ‘Startup’ folder and choose ‘Open’. Now copy the shortcut file you made before to this folder. Now right-click the shortcut file and choose ‘Properties’. Add the drive letter and network share as argument to the end of the ‘Target’ field e.g. “C:\Users\joeblogs\Documents\MapDrive.exe s: \\server\share 20″. You are done, next time you reboot, your s: should be mapped successfully for standard users.
Admin Users:
3. Press Win+R, type gpedit.msc, go User Configuration->Windows Settings->Scripts. Double-click Logon, click ‘Add’ and enter script name (no quotes): “C:\Users\joeblogs\Documents\MapDrive.exe” and script parameters (no quotes): “s: \\server\share 20″, ok, ok, done. You are done, next time you reboot, your s: should be mapped successfully for admin users (i.e. elevated programs).
It also frequently goes down just at random, when it’s not raining. P2P seems to worsen the situation (not surprisingly), but 
