Jump to content

Subsequent DriveMapAdd Statements


 Share

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)
         Else
            MsgBox(16 + 4096, "Mapping Failure", "An error has occurred mapping to a network share (" & $UNC & "), please contact the network administrator for more information.")
         EndIf
      Else
         MsgBox (0,"","Cannot find map file: " & $MapFile & ".")
         ExitLoop
      EndIf
      
      $i = $i + 1
      Sleep(5)
   Wend
EndFunc

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

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

Regards,

Matt @ MPCS

Link to comment
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 comment
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,

Matt

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...