Jump to content

Subsequent DriveMapAdd Statements

Recommended Posts

Hey everyone,

I am working on a network drive mapping script that maps drives based on a configuration in an INI file. For some reason the first map works properly but then all subsequent calls to DriveMapAdd have authentication problems which cause the login dialog to popup. I have been searching the forums (and RTFM) for about an hour without finding the answer so I figured someone out there might have some clues.

Following are a few clips that may help explain the point to the script:

Func ProcessMapFile($MapFile)
   Local $Drive, $UNC, $retVal, $i = 0
   While 1
      If IniRead($MapFile, "Map" & $i, "UNC", "") <> "" Then
         $Drive = IniRead($MapFile, "Map" & $i, "Drive", "")
         $UNC = IniRead($MapFile, "Map" & $i, "UNC", "")
         $User = IniRead($MapFile, "Map" & $i, "Username", "")
         $Pass = IniRead($MapFile, "Map" & $i, "Password", "")
         TrayTip("Mapping Drive: " & $Drive, "Currently mapping network share: " & $UNC, 30, 1)
         If MapDrive($Drive, $UNC, $User, $Pass) = 0 Then
            TrayTip("Drive Mapped Successfully", "Drive " & $Drive & " has been successfully mapped.", 30, 1)
            MsgBox(16 + 4096, "Mapping Failure", "An error has occurred mapping to a network share (" & $UNC & "), please contact the network administrator for more information.")
         MsgBox (0,"","Cannot find map file: " & $MapFile & ".")
      $i = $i + 1

Func MapDrive($Drive, $UNC, $User, $Pass)
   Local $retVal
   $retVal = DriveMapAdd($Drive, $UNC, 8, $User, $Pass)
   If $retVal = 1 Then
      Return 0
      Return -1

Any help provided would be well appriciated, and thanks in advance.


Matt @ MPCS

Link to post
Share on other sites

How familiar are you with mapping drives? Here are some of the "gotchas" I've encountered:

1) "The local device name is already in use." (Mapping to a letter that is already used tends to fail)

Calling DriveMapDel before DriveMapAdd increases scipt reliability

2) "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."

So if you X: mapped to \\sever\foo with userOne's credentials, you probably won't be able to map Y: to \\server\bar with userTwo's credentials.

3) "The network folder specified is currently mapped using a different user name and password. To connect using a different user name and password, first disconnect any existing mappings to this network share."

So if userOne maps \\sever\foo to W: on one computer, he won't be able to map \\server\foo to X: on another computer. (He would need to use the letter W: in order for the second mapping to work.)

Hope that helps

Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!
Link to post
Share on other sites

Thanks for the reply CyberSlug. You're right in the assumption that I am not really familiar with Windows drive mapping, and I believe the problem here falls under the 'Gotcha' #2.

What doesn't make sense though is that I can map each drive manually through the 'Map Network Drive...' GUI provided by Windows Explorer, so I don't quite understand why I am seeing this issue with the DriveMapAdd function and not the native Windows functionality.

The true purpose of this script is to get by the bug in Windows that after restarting the PC all samba network drive mappings do not remain signed on. Here is the scenario:

1) UserABC is logged into WinXP and maps a samba share (\\samba_server\ShareABC) to drive X:. (Note: Reconnect after logon is checked)

2) UserABC restarts WinXP

3) UserABC opens Windows explorer (Note: Drive X: is still listed in the list of drives)

4) UserABC double-clicks on the X: drive and is prompted for password

This scenario has been reproduced on multiple boxes throughout the company (All running WinXP Home SP1/SP2) but Windows network shares do not appear to have this same problem. Perhaps someone can suggest an alternative method of solving this problem or suggest a way to make this script work as expected.

Thanks again,


Link to post
Share on other sites
  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...