none
[SOLVED] Disable "Could not reconnect all network drives" Message/Icon in Domain Environment

    Domanda

  • I've seen this posted elsewhere but the proposed solutions don't apply to, or are simply 'solutions' we can't apply in this environment.

    We occasionaly see one or both of the following on desktops and laptops alike

    1. "Could not reconnect all network drives" balloon message and an icon in the system tray
    2. No balloon message but the icon exists in the system tray

    Understandably this happens off the network (although we want to suppress that), however, this happens while on the network.  In every case that we've seen this, when we check 'Computer' (formerly 'My Computer'), all of the network drives are connected.  Windows reports a 'false positive' - so to speak.

    Briefly here's our setup

    • Win 7 Enterprise in a domain environemnt
    • Built-in Win 7 firewall has been disabled; No third-party software firewall solutions present
    • Network drives are mapped via net use /persistent:yes, Explorer with reconnect & logon set & via exporting/importing the network drive information from HKCU\Network

    We use a login script, however, the login script does not handle the mapping of all of our network drives.  This is because we have a number of different departments, who, over the years, used overlapping drive letters and there are some situations where users also overlap departments that use overlapping drive letters.  (This goes back before my time.)  So instead, users map their own drives, remember the credentials and reconnect at logon.  Furthermore, when users call the Help Desk, the Help Desk uses the '/persistent:yes' switch/parameter when doing mappinv via command line.
    Not sure if this is relevant, but, when we move users to a new machine, or reimage their machine, we backup & restore the HKCU\Network key, which houses the mapped connections, to make the transition nearly seamless.  (So, doing a `net use * /delete /Y` to 'fix' this problem is not an option here.)

    Is there anything I can do to to prevent that message from popping up along with preventing the icon from displaying in the system tray?  Although the "Always wait for the network at computer startup and logon" and "Turn off all balloon notifications" GPO settings are set to 'Enabled', those are the only potentially relevant GPO setting I could find, and they don't appear to fix this issue.

    Also, I've been looking at the setting discussed here http://support.microsoft.com/kb/937624/en-us but although users are promoted to local administrators via a GPO I'm not certain that applies here or if that will help.
    Lastly, thanks to another post I found on the forums, I ran across this setting http://support.microsoft.com/kb/297684 and am wondering if this is worth investigating, however, I'm concerned of how changing this setting may affect the servers the user's are connecting to based on way this sentence was phrased:

    • "This behavior occurs because the systems can drop idle connections after a specified time-out period (by default, 15 minutes) to prevent wasting server resources on unused sessions. "

    If we set this value to some insanely high value (65535), how might that impact a server with a 1000 connections?

    Any suggestions are greatly appreciated.


    mercoledì 15 settembre 2010 11:06

Risposte

  • From Microsoft after submitting the Design Change Request (DCR) and Business Impact Statement

    I was in Redmond last week and 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.

    Cause and Status

     

    There is a change in code path /design from windows XP to Windows 7 that is  leading to this behavior

    A request of design change was filled . 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 .

     

    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.

     

     

    Workaround

    One of the basic script workarounds is that , if we have a batch script that will attempt to access \\server\share that should be mapped to z: then the expected behavior can be achieved with net use.  At the top of the batch script we can add the line: net use z:\\server\share

    In the situation where we currently have a failed access, the script will work precisely the same.  If the user was in a functional situation then the added line will give the following error message: “System error 85 has occurred. The local device is already in use.” However, the batch script will continue as before providing the expected functionality.

    If this error message is not acceptable (although it will be hard to notice it because if we just click on a script it will flash the cmd window by quickly) then the output can be suppressed.  Using “net use z: \\server\share 2> nul” will suppress any errors this command would produce.

     

    • Contrassegnato come risposta JuliusPIV mercoledì 27 marzo 2013 15:59
    martedì 13 settembre 2011 22:42
  • Update: All - I updated another post with this information but failed to update this one & for that I apologize.

    Here's the 'official' response from Microsoft:


    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.
    1. 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.
    2. 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:
    1. 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.
    2. 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.

    • Modificato JuliusPIV mercoledì 27 marzo 2013 15:58
    • Contrassegnato come risposta JuliusPIV mercoledì 27 marzo 2013 15:59
    mercoledì 27 marzo 2013 15:56

Tutte le risposte

  • Two things

    First:  Bump!

    Second: While were on the subject of network drives, I wanted to share with everyone something else we've discovered.

     Steps taken to reproduce the problem.

    1.       Logon to a machine

    2.       Map some network drives and check the ‘reconnect at logon’ box.

    a.       Or use net use with the /persistent flag

    3.       Create shortcuts that reference files on the network drive (like F:\my files\info.txt; h:\home_drive\application.exe)

    4.       Shutdown or Restart

    5.       Disconnect the network cable

    6.       Login to the machine

    7.       The network drives connection icon (and balloon notification) appears

    8.       Connect to the VPN network

    9.       Try to access the shortcuts created on the desktop (this fails).

    10.   Open a command window and type `net use` to confirm status of drives

    11.   Open the ‘Computer’ window (formerly ‘My Computer’; or open Explorer & go to Computer)

    12.   Double click the network drives

    13.   Go back to the shortcuts on the desktops and they now work.


    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.

     

     



    • Modificato JuliusPIV martedì 13 settembre 2011 23:00
    lunedì 24 gennaio 2011 03:00
  • I think I've found a workaround for this issue. If you disconnect the mapped drives from My Computer, log off and back on again (I have persistence enabled) it makes the reconnect error balloon stop popping up.
    venerdì 28 gennaio 2011 18:47
  • Thanks for taking the time to read & reply to this thread.  How do you disconnect the mapped drives:

    • Right click disconnect?
    • net use Drive: /delete /y?
    • Some other method?

    As time permits I'll try to test this but I'm concerned abhout implementing this workaround programmatically across ~1500 machines.

    Here is another post discussing the same thing: http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/48f5ca04-6561-404d-b3ab-897320593aa6

    mercoledì 16 febbraio 2011 12:10
  • Hi JuliusPIV....

     

    I am curious if you have found out any further info on the re-connection of network drive's when connecting to the VPN.   This has been a on-going issue for the company I work for....for the last few months.   But now, we just rolled out 130 new windows 7 machines to be used primarily off-site.  They have a batch file they run, that pulls info from a network drive.  So naturally, the sales people are not going in and initiating the network drive first.   And as you said, Windows XP did this on its own.

    Have you heard anything back from Microsoft for a fix to this bug?   Or have you perhaps found a work around to the issue?   I was going to begin working on a script to put in the VPN client that would connect this drive for them....but have not found the time.  And if Microsoft has a hotfix or something in the works, that would be great to know.

     

    Any further info you could provide would be great.

     

    Thanks!!

    giovedì 17 febbraio 2011 15:23
  • It actually worked for right-click disconnect and net use Drive: /delete /y. It did randomly resurface once, but the reason for that was that Active Directory was mapping the user drive automatically at login, but the drive was being mapped in the login script as well. I removed it from the login script, and haven't seen it since.

    I started off implementing this on a few computers for testing purposes, and as of Monday have successfully rolled this out to the entire company (about 150 users). I have not had any user complaints, or seen the issue since. 

    giovedì 17 febbraio 2011 19:18
  • Good point - as part of our migration process we backup existing mapped drives which also includes their home directory.  We'll try to take that into consideration thanks for sharing this is great news.
    venerdì 18 febbraio 2011 05:33
  • Found this in another forum

    Whenever I mapped the drives in Windows it asked for credentials. However these credentials were then created with a persistence type of "Logon session" which is not editable.

    Having discovered this, I restarted windows and then before supplying the credentials to reconnect the mapped drives, I added credentials explicitly as follows:

    1. Goto Control Panel -> All control Panel Items -> Credentials Manager
    2. Next to the heading "Windows Credentials" click on the link "Add a Windows credential".
    3. Enter the name of your server and the appropriate credentials.

    The result is an entry that has a persistence type of "Enterprise". This seems to do the trick. (I then restarted windows)

    This fixed the problem for me, hope it does for you.

    BTW. In order for windows to resolve the server name you may have to create an entry in the "Hosts" file located in "C:\Windows\System32\drivers\etc".


    martedì 7 giugno 2011 04:37
  • From Microsoft after submitting the Design Change Request (DCR) and Business Impact Statement

    I was in Redmond last week and 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.

    Cause and Status

     

    There is a change in code path /design from windows XP to Windows 7 that is  leading to this behavior

    A request of design change was filled . 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 .

     

    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.

     

     

    Workaround

    One of the basic script workarounds is that , if we have a batch script that will attempt to access \\server\share that should be mapped to z: then the expected behavior can be achieved with net use.  At the top of the batch script we can add the line: net use z:\\server\share

    In the situation where we currently have a failed access, the script will work precisely the same.  If the user was in a functional situation then the added line will give the following error message: “System error 85 has occurred. The local device is already in use.” However, the batch script will continue as before providing the expected functionality.

    If this error message is not acceptable (although it will be hard to notice it because if we just click on a script it will flash the cmd window by quickly) then the output can be suppressed.  Using “net use z: \\server\share 2> nul” will suppress any errors this command would produce.

     

    • Contrassegnato come risposta JuliusPIV mercoledì 27 marzo 2013 15:59
    martedì 13 settembre 2011 22:42
  •  Am I right to discern from MS’s reply to you that they are suggesting that: in the situation where a user is connecting to VPN (after windows logon) to run a batch script manually in order to reestablish connection with their mapped network drives?

    venerdì 23 marzo 2012 12:33
  • Hey Mikes87: That sounds about right.  Very specific actions trigger the network refresh by Explorer, but is it worth the hassle of trying to explain that process to a user?  Even worse is how silly that looks on paper!  For instance, if I had a shortcut pointed to a mapped drive (Like Z:\path\something\file.exe) and I right clicked on the shortcut, I think that triggered a refresh and suddenly all mapped drives worked.

    From what I think I remember, batch scripts can trigger a refresh of the network connections but a VBScript will not.

    If I can help, let me know.  Its been ages since I last messed with this!

    • Modificato JuliusPIV lunedì 2 aprile 2012 23:52
    lunedì 2 aprile 2012 23:43
  • Had the same issue here with a T420S on Win 7 Enterprise 64-bit but was traced to a SD card in the laptops slot.  Once that was removed, an F5 refreshed the 7 missing network drives in My Computer.
    venerdì 4 maggio 2012 16:57
  • Had this issue on a Vista machine and a W2K8 Terminal Server.

    Found that the users had a previous persistent drive mapping to their Personal User Drive (U: drive). Since then, their personal user drive mapping (U: drive) was added to their AD profile for automatic mapping.

    Resolved by disconnecting their personal user drive at the problem machine by right clicking and selecting disconnect. This kills the persistent mapping. After reboot, the AD profile takes over and maps the drive (U: drive). Error no longer appears.

    Hope this helps...

    • Proposto come risposta hpanisch lunedì 21 ottobre 2013 09:52
    venerdì 15 giugno 2012 18:03
  • Found a possible solution

      Hive: HKEY _CURRENT_USER
      Key: Network
      Value Name: RestoreDiskCheckedbr>DWORD Value: 0 = disabled, 1 = enabled

    That should do it.

    giovedì 5 luglio 2012 15:10
  • Julius,

    Has making the above registry change helped with the drive mapping issue?

    Thanks

    martedì 16 ottobre 2012 03:29
  • bjohnrini: I haven't tried since then honestly.  When we couldn't get a fix from Microsoft, we implemented some workarounds [where possible] & communicated the issue with our Help Desk.  I went on vacation shortly after my last post & was gone for 5 weeks; needless to say I forgot about it!  I've been playing catch up since my vacation, and I have other initiatives I need to concentrate on at this time so I won't be working on this soon.

    However, if you have time to test, I'm sure I speak for everyone else who has dealt with this when I say that we'd all love to get an update/feedback!  Plus its likely to help others in the future.

    • Modificato JuliusPIV martedì 16 ottobre 2012 16:02
    martedì 16 ottobre 2012 16:00
  • Haven't had any luck yet...

    Does the key need to be created in the network key, or in the key for the individual drives listed?

    32 bit dword or 64 bit?

    venerdì 19 ottobre 2012 22:38
  • I haven't seen a definitive answer for this yet, other than to create a batch file or script that runs after startup. This is essentially a non-fix for me because we used GPO drive mappings specifically so we could stop using logon scripts. Anyone have an update?
    venerdì 4 gennaio 2013 01:05
  • Found a possible solution

      Hive: HKEY _CURRENT_USER
      Key: Network
      Value Name: RestoreDiskCheckedbr>DWORD Value: 0 = disabled, 1 = enabled

    That should do it.


    Nope, not the solution. I created a 32-bit DWORD in each of the mapped drive letters, restarted and still got the error message. Why is this case marked as solved when it clearly isn't?
    martedì 12 marzo 2013 11:15
  • I had this problem with a Windows 2012 Domain with Windows 8 machines - it was driving me mad but I believe I have now solved it!

    I am mapping a network drive to a network share based on membership of a specific Security Group. In Group Policy I created a Drive Map (User Configuration/Preferences/Windows Settings/Drive Maps) using the Action:Update and over on the "Common" tab I used "Item-level targeting" to target the specific group I wanted to map the drive for.

    No matter what I did every time one of those users logged in they got the balloon warning that all network drives were not available - even though when you looked in File Explorer they were!!!

    The solution came when I went back to the Drive Map config (using Group Policy Editor) and unchecked the box entitled "Reconnect"

    Hope this helps - it certainly worked for me.


    Mark G Briggs - technology is a passion

    sabato 23 marzo 2013 10:08
  • I have read this thread and others, I have a win7 pc that is used off site, from what I have gathered i simply need to create a script to run and re-maps the drives after the vpn connection is made.... correct? I have just started in this area so i have not built scripts. Any direction?  
    martedì 26 marzo 2013 14:01
  • I haven't seen a definitive answer for this yet, other than to create a batch file or script that runs after startup. This is essentially a non-fix for me because we used GPO drive mappings specifically so we could stop using logon scripts. Anyone have an update?
    From my perspective, you're right: there isn't a definitive answer for this.  We ended up having to create a workaround to solve this.  I'll provide an update I received from Microsoft shortly regarding this.  You could try the GPO method outlined below by Mark G Briggs.
    mercoledì 27 marzo 2013 15:45
  • Nope, not the solution. I created a 32-bit DWORD in each of the mapped drive letters, restarted and still got the error message. Why is this case marked as solved when it clearly isn't?
    Thanks for the update on the suggested registry change.  (Good to know it doesn't work!)  Its been marked as 'solved' because of the response from Microsoft - see my post further down.  Its not solved (or fixed) in the sense that Microsoft released a patch or has provided a method for working around this.  Unfortunately we have to work around it on our own; although some of the responses here suggest some methods may work better than others.
    • Modificato JuliusPIV mercoledì 27 marzo 2013 15:48
    mercoledì 27 marzo 2013 15:47
  • I have read this thread and others, I have a win7 pc that is used off site, from what I have gathered i simply need to create a script to run and re-maps the drives after the vpn connection is made.... correct? I have just started in this area so i have not built scripts. Any direction?  

    You're correct: The answer has been to create a batch file to reconnect the drive mappings.  It could be something as simple as this:

    net use X: \\server\share


    To something way more complex!  Try some of the examples in the posts here:

    If you need some help, create a new post, let us know what you want to accomplish and I'm certain someone will swoop in to help you out!

    mercoledì 27 marzo 2013 15:55
  • Update: All - I updated another post with this information but failed to update this one & for that I apologize.

    Here's the 'official' response from Microsoft:


    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.
    1. 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.
    2. 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:
    1. 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.
    2. 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.

    • Modificato JuliusPIV mercoledì 27 marzo 2013 15:58
    • Contrassegnato come risposta JuliusPIV mercoledì 27 marzo 2013 15:59
    mercoledì 27 marzo 2013 15:56
  • I know this might be an old thread, but in answer to the OP's question: "Is there anything I can do to to prevent that message from popping up along with preventing the icon from displaying in the system tray?"   Yes, here is one thing you can try:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\
    Set or create a DWORD
    RestoreConnection = 0

    Here is the original thread the fix is located under: http://social.technet.microsoft.com/Forums/windows/en-US/8f3e052a-8115-4dad-8d2a-b37ee5dc347a/help-howto-delay-maping-drive-until-network-is-up?forum=itprovistanetworking#24cff623-acd6-4295-9c25-c384cd166053

    I had this problem with mapped drives that I want to remain "connected" whether I am on or off my company VPN.  The alert is really annoying when I am off the VPN because of course the drives won't connect.  But with this fix the drives stay mapped and will connect the very first time I click on them once I am again on VPN, and I get no annoying alert message on start-up.  Win7.

    • Modificato flguy2 martedì 19 novembre 2013 22:14
    martedì 19 novembre 2013 22:07
  • It is an old thread ...this problem goes back at least 6 years, which says a lot about Microsoft. For the average non-enterprise user like myself, NetDrives has solved the problem that MS refuses to address. And for most of us, Policy Editor is unavailable.

    Even in 8.1 the same problem occurs, as if network storage hasn't hit the mainstream yet.

    NetDrive connects the drives in 8.1, but not before the annoying message. Thank you flguy for the fix I've been hunting for.

    domenica 5 gennaio 2014 18:58