I have several drives mapped on different Windows 7 boxes in my office. Just about every time I boot up one of these systems I receive the message "Could not reconnect all network drives" in the system tray. I should note that merely clicking the drive inside Windows Explorer will restore the connection. I store the server logon credentials in Control Panel / Credential Manager then just map the network paths to drive letters. I'm pretty sure the problem doesn't stem from any credentials type of problem though, because I have the exact same situation when connecting to only open shares. I have noticed that a couple applications will restore the connection themselves when trying to access information on a share. Most applications however will give an error and time out trying to access the shares unless I go and manually click each drive letter in Explorer. For instance if I place Firefox bookmarks on a share and open Firefox, Firefox will display no bookmarks until I click the drive in Explorer and reopen Firefox. One thing I can do to fix the problem is hard code my IP address. I never receive the message if a computer has fixed IP address. My router hands out IPs on the LAN dynamically, so I switch it to another router and tried a using a Linux based dhcp-server as well. Neither fixed the problem. I'm a long time user of batch files and realize I could place use one as a band aid for this issue, but I don't want to go that route.

you can try if configuring the "always wait for the network at computer startup and logon" policy in Computer Config\Administrative Templates\System\Logon affects the problem.

Yeah, I had tried that. Just toogled that to enabled again to be certain, and it doesn't help.

Most of these behaviors are caused by firewall. You may temporary disable firewall on the computers that share the folder with red X. Additionally, if any problematic computers have Windows XP or Windows Server 2003 installed, please refer the following article to resolve the issue. Mapped Drive Connection to Network Share May Be LostPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I can completely disable the firewall and that doesn't help. I'm willing to try anything though. I'm pretty sure this is a general problem with Windows 7. Any machine I have that doesn't have a hard coded ip address has this problem. While searching for a solution I've seen others with the exact problem. Other than the hard coding the ip that I come up with, I've haven't seen a solution yet either.

I'm curious to know if you ever found a solution to this problem. I'm encountering the same issue and have posted my 'cry for help' here. http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/f6ec02e9-50c5-4311-b8e0-523490c16883 I'm curious, are you using GPO's in your environment? If so, have you tried setting the "Always wait for the network at computer startup and logon" and "Turn off all balloon notifications" GPO settings to 'Enabled'? If you have, can you confirm whether or not you're seeing an improvement, or are you getting mixed results? Keep us posted!

I'm having the same problem that marstech describes. Specifically, after logon I will see that bubble. My systray network icon shows connected and launching Explorer shows all drives are connected. We're planning a Win7 rollout early next year and want to find how to disable this message or at least the cause of it. Thanks! Setup: Win7Ent domain joined w/s, Win2k3 domain, 1 network drive mapped via %HOMEDRIVE% in AD account, no persistant drives mapped in local OS or via GPO/logon script.

No, I have tried the group policy settings though and they didn't help. The problem for me are applications that use data from the network. For instance if Roboform is using data from a network share, it will not function at boot until you open Windows Explorer and click the network resource. The same is true for writing data to the network. For instance I have an application that rips disc images. It is set to rip to V:\temp\$discname$ and will create a sub-directory based on the title of the disc. That application will fail until I manually go open the V: drive. I posted a video here: http://youtu.be/XQZanQD-wG8?hd=1 As you can see in the video the only solution I've come up with is to hard code the IP address of the workstations (the server has always been static). Although this works 100% of the time for me, it is annoying to have to do that.

masrtech: Thanks for the video - great work there. Its, *very* interesting to know that having a static IP 'corrects' this problem. While were on the subject of network drives, I wanted to share with everyone something else we've discovered. In Windows XP, if a user has a persistent network connection (a remembered network drive), when they logon, it immediately reconnects the drive. If the same user logs into the same Windows XP machine while offline (disconnected from the network) naturally the drives don't reconnect. They're in the same 'disconnected' state as in we've observed. If we take that same user and have them connect to our VPN system, within seconds of establishing a connection, Explorer re-connects the network drives without the user doing anything. This is nearly instant, not a 30-60 second thing, as once I connected to the VPN I opened Explorer and the drives were already connected. So, I don't expect there to be any real surprises at this point, but here's the interesting part... Windows 7 behaves differently. If you follow the same steps in Windows 7, Explorer will *not* re-connect the network drives; It doesn't automatically re-establish a connection to the network like Windows XP. We've tested this on a few Windows XP & Windows 7 machines and its 100% repeatable. Something specific must be triggered before Explorer [on Windows 7] re-connects the network drives. I won't go into great detail but I will say that UNC paths (\\server\share\file) work fine (be it a shortcut or start > run), while anything that references a drive letter (F:\file, G:\Folder) fails. (I'm curious, as anyone else noticed this?) The good news is that we opened a ticket with Microsoft and they were able to reproduce this problem and have confirmed it is a 'bug' but there's no word on whether or not this is seen as something that needs to be fixed. I mentioned the network drive bubble & icon issue but they were more focused on the network drive issue I discuss here. If you want more information on this, let me know if you want to know. I have a video that details this but I can't release it just yet without first cleaning it up.

This is interesting. I have Windows 7 Professional client that display the same red x and mapped drive unavailable message until you brose them in explorer. I didn't thin it was causing any problems until a database we used error out when tring to retrieve an image from a mapped drive. We also have three issues with wireless connectivity; *Yellow exclamation manifest in three distinct ways - 1) partial access that is restored when IE is opened or by pinging external address 2) no access - shows leased IP but cannot ping to or from and opening IE does nothing 3) no access - local IP address opening IE does nothing. I've searched all the threads and tried all of the fixes and nothing works consistently. I'm working with MS and all of the hardware vendors -we're into our sixth month now. I was already wondering if there was a connection between the wireless and the mapped drive issue. With the statement about the hard coded IP I'm really wondering. We do not see these problems on our Windows XP machines. There must be something about how Win7 establishes and verifies connections that's causing this. Does anyone know enough about the difference between winxp and win7 network connections to lay out some possibilities?

I have a static IP and see this same issue whether or not my firewall is active or disabled in Windows 7 SP1 64-bit. Most of our environment is XP SP3 and those users are also seeing this issue. I added a START /wait command to our login scripts but that didn't help.

ANy word from Microsoft on a fix?

As I mentioned above I opened a case with Microsoft [some time ago] regarding the behavior of mapped network drives in Windows XP versus Windows 7. Here's some updated (10/06/10) information from them: "I have some word back on this issue as to why you see differences in operation from XP to Win7. What I am being told is that wscript implements the opening of a file in two different ways between XP and Win7. In XP there are extra calls made to open a file via shell32 which triggers the reconnect, in Win7 these extra calls are not made and so the trigger does not occur to cause the reconnect to occur. I have been given two workarounds to offer you on this. Create a batch file to start the app that maps/reconnects the drive first and fails if it can't map the drive (net use drive: \\server\share && foo.exe The && states that the first one has to succeed before the second one runs. Create a cmak package that runs a script to map the drive after the connection is established. While I realize you would like to see Win7 changed to work like XP on this, I cannot offer much hope a DCR for this would be accepted, especially when there are ways to workaround it. If you want to discuss this further we can." So we created the DCR and recently (4/13/11) heard back: "...in Redmond last week...this issued was discussed in detail with the development team . We did figure that this is a change in the design /code that lead to the issue you are seeing . The team weighed the effort of investigating this further ; the effort of changing the component code that has already being isolated verses a workaround for the issue that could be provided. The team felt that this request did not meet the set ( high) bar for taking in design change request for Windows 7 . Case notes indicate there are some workarounds that have been work on by previous engineers who worked on this case with you. If not, the Dev team and me will be glad to work on the workaround by editing the scripts. With my request the Dev team will file this design change request for the next OS release (the one after Windows 7) . At this moment I don’t know if this request will be accepted in the next release but if will certainly be discussed and a decision will be made." So unfortunately it appears the blow is two fold: While we didn't get the warm and fuzzy we wanted (i.e.: this network drive auto-remapping issue fixed v.s. relying on a workaround), the workarounds will suffice. With this new change, we'll likely continue to see the notification, or the icon in the systray at least, until the next OS release. Tammie C: I've not witnessed that specific problem but its possible there is a connection (to a certain degree), although I think unlikely. Have you created a thread elsewhere describing the symptom(s)/problem, what hardware (IBM, Dell; laptops v.s. desktops with wifi NICs or usb 'dongles') and what the overall experience is? jsepeta: I can't speak to Windows XP (SPx) users seeing this problem. Only our Windows 7 users witness this phenomenon. Windows XP is pretty good about re-establishing/re-activating network connections. If its not mapping drives, perhaps there's another issue at play...?

Hello marstech, According to the research, the mapped drive lost issue may be caused by the several possible reasons: Possible reason1. The problematic client doesn't reconnect to the target share at logon. Please follow the steps to re-configure the mapped driver on the client and then check if the issue will re-occur. Steps: a. Open "My Computer" b. Click on "Tools" and then select "Map Network Driver" c. input the \\ipaddressofserver\sharename to give the path of the share d. Check "Reconnect at logon" e. Drive gets mapped f. Double click on the drive to check. Possible Reason 2. Antivirus software or Windows Firewall may block the SMB protocol on clients. Please check if there is any Antivirus software and the Windows Firewall is enabled on the problematic client. If so, please disable them to check if the issue can be resolved. Possible Reason3. Fast Logon Optimization is enabled on the clients. The fast logon feature may affect the display and drive letter assignment of a mapped network drive. As a result, the drive may have been mapped; however, the user on client cannot see it in Windows Explorer. He may recognize it as a failed network drive mapping. This is the reason why we usually suggest you to disable fast logon on the clients via a GPO, and please check if the mapped network drive will be occur under this circumstance. Please also configure the following group policy setting to disable Fast Logon Optimization to see if the issue still exists on the problematic clients. Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon When this policy is enabled, a Windows XP client behaves in the same manner as a Windows 2000 client at both system startup and at user logon. Please note: As this is a computer configuration, please run "Gpupdate /force" and then reboot the problematic clients to make it take into effect. For more information about Fast Logon Optimization feature, please check the following KB article. 305293 Description of the Windows XP Professional Fast Logon Optimization feature http://support.microsoft.com/?id=305293 831998 Mapped network drive shows no drive letter or will not allow you to create new long-named files or folders http://support.microsoft.com/kb/831998 297684 Mapped Drive Connection to Network Share May Be Lost http://support.microsoft.com/kb/297684 If the issue still exists on the problematic clients, please also try adding the following registry subkey on the problematic client to check it works. Steps: a. Click Start, click Run, type REGEDIT, and then click OK. b. Locate and click the following registry subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache c. Click Edit, point to New, and then click DWORD Value. d. Type SilentForcedAutoReconnect , and then press ENTER to name the value. e. Double-click SilentForcedAutoReconnect . f. In the Value data box, type 1, and then click OK. Please feel free to let me know if you have any concen. Hope the information can be helpful for you.Thanks and Regards Scorpio_Milo MCTS: Windows Vista | Exchange Server 2007 MCITP: Enterprise Support Technician MCITP: Server & Enterprise Administrator Microsoft Infrastructure Consultant Enterprise Service: Solution Architect Microsoft Storage Team - File Cabinet Blog My Blog