Failed to map drive using login script - multiple connections error
We are in the process of rolling out Windows 7 to replace Windows XP. We have a login script that maps all of the drives and works perfectly on Windows XP. However, it fails to map some drives when running on Windows 7. We have two different domains with an external two-way trust between the two. All of the user accounts that exist on DomainA exist on DomainB and the passwords are always in sync. The workstations are in DomainA. We are trying to map drives M,N,O,P to DomainA and drives X,Y,Z to DomainB using the MapNetworkDrive Method (so using a VBS script). Drives M,N,O,P always map successfully. Drives X,Y,Z behave in a random way, sometimes they map successfully, sometimes they don't. The error description returned by the MatNetworkDrive method is: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again. Just before mapping any drives on the login script, we erase any and all existing connections (be it a drive map or not), so it is not possible that multiple connections exist. I've also stopped the script at the exact time when it fails to output a net use and it shows there are no established connections to DomainB, so that could not be the problem. If one drive succeeds in mapping from DomainA to DomainB, then all drives succeed as well. If one fails, then all fail. Whether it succeeds or not is completely random and does not appear to obey any patterns. No users logging in are administrators or power users, so the login script is not running with an elevated token. It can't be a problem with the login script itself because it works properly on Windows XP (besides the error message is quite specific). Scripts are set to run synchronously (though Windows 7 doesn't respect that if the user is logging in for the very first time and creating a profile) and setting them to run asynchronously appears to make no difference. UAC is at its default state. Running the script manually after logging in will more often than not successfully map all network drives, but this is not always the case either.
May 26th, 2011 4:53pm

Forgot to say that the MapNetworkDrive Method is being called with the following parameters: objNetwork.MapNetworkDrive("X:", "\\MyServer\MyShare", FALSE, "DOMAINB\" & objShell.ExpandEnvironmentStrings("%USERNAME%")) Because the names of the account of all users exists on both domains and their passwords are synched, we don't have to pass the last parameters the method receives, which is the password. It works fine without it (both on XP and Windows 7). The error we are getting is to do with Multiple connections - which should only happen after validating the credentials.
Free Windows Admin Tool Kit Click here and download it now
May 27th, 2011 12:32pm

Hi, Would you please let me know If the same user or anybody mapped the drives? Please check if the following KB is helpful. It applies to Windows 7 as well. http://support.microsoft.com/kb/938120 If the issue persists, before running the script, boot into WinRE and open Command Prompt, use net use command to see all existing connections. Here is a similar post. Hope it helps. http://social.msdn.microsoft.com/Forums/en-US/biztalkgeneral/thread/aeeb452d-0254-4bc2-a598-20f1f57ee8e0 If the issue persists, please also post a new thread in MSDN forum to confirm the script. The script may be difference between Windows XP and Windows 7. http://social.msdn.microsoft.com/Forums/en-US/biztalkgeneral/threads Best Regards, Niki Please 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.
May 30th, 2011 12:35pm

The mappings are not persistent. Also, we are closing all existing connections before to map any drives, just in case. It's a hit and miss problem. Sometimes it will map fine, sometimes it won't. I modified a dev version of the script to try to map each drive up to 3 times in case it failed and again it's hit and miss. Sometimes it does it 1st try, sometimes it does it 2nd or 3rd tries and sometimes it just fails after all 3 tries. Running the same script manually after logging in appears to always map all drives successfully, so there are definitely no existing connections. cogu
Free Windows Admin Tool Kit Click here and download it now
May 31st, 2011 2:03pm

Hi, According to the error message and my experience, the issue may be caused by the same user account has established a SMB session to the server. Therefore, it wasn't allowed to create a new SMB session. However, to find the root cause of the issue, we should check the connections information on the server side instead of the client side. We can check such information in computer management --> shared folders --> sessions. Besides, explorer shell of Windows 7 will auto re-connect SMB session for users. So file server can't terminate a Win 7 client's SMB session, because it will be re-connected at once. Win XP shell has no such function. I think that may cause the different behavior on Windows xp and Windows 7.
June 1st, 2011 2:46pm

Hi Alex, I'll check the server side to see if that is the case, but I do not think it is the case because of the following reasons: I've created a CNAME record for DomainB (i.e., Drive-X.DomainB.com resolves to DomainB.com) and tried mapping the drive to the CNAME as oppose to the domain name directly (which is an old trick to force Windows into thinking that the drive is mapping to a different location and therefore ignoring multiple connections) - this works fine every time. Though this has had limited testing so far, if you were right, eventually we'd see the same issue even when connecting via a CNAME. On the other hand, if your theory was right, then we'd be experiencing the same issue on both domains. This issue is only happening when we try to map a drive from a computer in DomainA to a location in DomainB over the two-way external trust. Most of our drive mappings are going from computers in DomainA to shares in domainA and none of those cause any sort of issues. Lastly, I think that running the login script manually right after having fully logged in would still cause the same drive mappings to fail in many cases if this was the problem. As it stands, just waiting for the computer to fully login and manually running the script successfully maps all drives. I am assuming the client is trying to establish some connection to DomainB for some bizarre reason that only happens because of the two-way trust we have in place. Perhaps it is trying to connect to the NETLOGON share of the other Domain to see if there are any GPOs to process (even though we disabled cross domain GPO processing), which is why a connection is already established when we try to map the drive... I have no idea what the problem is, I only know that using CNAMEs does seem to fix the problem and whilst we might be forced to go with it on a temporary basis, I'd still like to get to the bottom of this. Cogu
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2011 12:54pm

Hi, I agreed with you there may be a session was established during user logon process. Therefore, the script maps the drive successfully after user logon. Based on this theory, we can add some sentences into the script. So it will idle for some time and be run after user logon process.
June 6th, 2011 12:44pm

Can't do that, scripts have to run synchronously in our environment. Everything was built around that fact (which in Windows 7 is another pain in the neck seeing as that setting is not respected for 1st login of a user to a particular workstation).
Free Windows Admin Tool Kit Click here and download it now
June 8th, 2011 7:17pm

Not offering assitance with your actual error............How about looking into Group Policy Preferences for Mapping Network Drives? Since moving from a bespoke script to GPP it has been considerably better and easier to manage. http://blogs.technet.com/b/grouppolicy/archive/2009/02/11/gp-preferences-will-reduce-logon-scripts-mapping-drives.aspx Just my 2 p's worth Regards LeeBLee Bowman MCITP MCTS
June 9th, 2011 5:00pm

hi, Did you try the GPP setting? i think it might help you fix the problem.
Free Windows Admin Tool Kit Click here and download it now
June 24th, 2011 12:24pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics