Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Wednesday, September 28, 2011

Could not reconnect all network drives

Source
Map of a network drive
Go to an Explorer window (such as My Computer) and choose Tools - Map Network Drive...
In the Map Network Drive window that appears, click on the Connect using a different user name option.
In the box that opens, enter as the user name ukc\xyz1 where xyz1 is your UKC network login. In the password field enter your UKC network password. (NB. Do not forget to put ukc\ before your username, the process will not work otherwise.)
Click OK.
Back in the main window, type the full path to the folder you are mapping, e.g. \\corfe\install. Alternatively, click on Browse to browse for a folder on the network. Most of the folders you will need to access (for example, those on the host ward) will be located under ‘UKC’ - e.g. \\ward\courses
To map your central filestore (Z: drive on public PCs) select Z: as the drive name and in the path box type \\bodiam\??? where ??? is your system ID, not your Login. You can find out your sysid on a public PC by running the mailinfo program (Start, Programs, UKC UTILITIES, Mailinfo). Make sure you run the mailinfo program on your own login. When using your sysid, only enter the three letters and NOT the numbers. E.g. hcg003 would be entered as \\bodiam\hcg.
--------------
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.
If any problematic computers have Windows XP or Windows Server 2003 installed, please refer the following article to resolve the issue.
--------------
Delete A Network Drive:
this is for those who suffering from annoying Balloon(pops in Traybar). Use this method for remove Disconnected
Drive But Mountable in every Logon.
OK, Lets Do it Go to Start - Run  - type Regedit
Now go to Following Address:
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\MountPoints2
find your Network Drive From its Name and Address,then delete the key
Try changing the username on either XP or Windows 7, or using the same password on both.
If you want your account to have a password, but not ask you for one at logon:
Start -  Run (search area) - netplwiz {enter}
uncheck the checkbox "users must enter a username and password to use this computer"
------------
Change "User user accounts and passwords to connect to other computers" in the Homegroup settings as detailed here:
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.
"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.
----------------
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.
  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.
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.

No comments: