Fix for ‘Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed” problem with MDT 2010


There have been reports of a problem when running Refresh, Replace, Sysprep and Capture, and Custom task sequences with MDT 2010.  When running those scenarios an error message is displayed after completing the wizard that states “A connection to the distribution share could not be made”.  When looking at the log files the error states: ‘Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.”


This problem seems to occur most often when logged onto the client machine as one user and entering different credentials into the deployment wizard or customsettings.ini.


We have developed a fix for this problem.  To fix the problem you should edit the ztiutility.vbs file in the deployment share under the scripts folder.  Open the file in notepad and replace the following code in the MapNetworkDriveEX function:


Case Else


‘ Case &h800704C3 ‘ Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.


‘ Case &h8007052E ‘ Logon failure: unknown user name or bad password.


‘ There was a some kind of fatal error.


If ErrDesc <> “” then


             MapNetworkDriveEx = ErrDesc


Else


             MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) “


End if


oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType


Exit function


End select


With this code:


Case Else


Err.Clear


On Error Resume Next


oNetwork.MapNetworkDrive  chr(sDrive)&”:”, sShare, False


HasError = err.number


ErrDesc = err.Description


On Error Goto 0


If Err.Number <> 0 Then


‘ There was a some kind of fatal error.


             If ErrDesc <> “” then


                                        MapNetworkDriveEx = ErrDesc


             Else


                                        MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) “


             End if


             oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType


                           Exit function


Else


      Exit Function


End If                   


End select


We thank you very much for your feedback and assistance in helping us fix this problem.  We are currently working on a KB article that decribes these steps and will update once that KB article is available


Comments (10)
  1. Anonymous says:

    editing script didnt help me and am using MDT 2012(in testing phase.

    my problem was that i had local admin named "administrator" and that was also name of admin on my test domain and they had same passwords. After changing local password, i had no more issues.

  2. Anonymous says:

    I encountered this issue and I found that it was caused by the local workstation credential trying to authenticate against the the network sharepoint with the same password.

    For example, if I have

    \VS1Deployment$ as a MDT 2010 sharepoint

    and VS1 (Win2008)’s local administrator’s password is set to P@ssw0rd.

    When I installed W7 workstation by using MDT and login as W7’s administrator with the password as P@ssw0rd (the same as VS1), Sysprep and Capture script can be initially accessed and launched from \VS1Deployment$ as W7administrator (not VS1administrator) then the ztiutility.vbs try to properly authenticate with VS1 by using VS1administrator.

    Workarounds:

    1. Simply, change your W7Administrator’s password to something else like 1111, reboot and try again.

    2. or, provide your current user’s credential (Domain should be W7 instead of VS1)

    Please update the script to avoid this issue…

    Thanks,

  3. Jack says:

    Still does not work

  4. SCOTT S says:

    I found that if I gave full control of the share to the Users group, I was able to make things work.  I used //IP/share method to access the vbs script and the server name for the second part.

  5. newman says:

    Just use full domain name or full computer name.

    Example: \VS1.domain.orgDeployment$ OR \VS1.computernameDeployment$

  6. Kernel_Panic says:

    Thanks a lot newman, that worked for me

  7. Newman's suggestion works says:

    Thanks Newman. Using the full path worked.

  8. lsmith says:

    I know there has been some time passed but I ran into this as well. after trying all the suggestions, I found that I will get the errors if I DON'T use DHCP addressing?????? once I set the box to DHCP, all runs fine….

    The info is good..

  9. Mohaltron says:

    I executed as YPAE said which is

    "I encountered this issue and I found that it was caused by the local workstation credential trying to authenticate against the the network sharepoint with the same password.

    For example, if I have

    \VS1Deployment$ as a MDT 2010 sharepoint

    and VS1 (Win2008)'s local administrator's password is set to P@ssw0rd.

    When I installed W7 workstation by using MDT and login as W7's administrator with the password as P@ssw0rd (the same as VS1), Sysprep and Capture script can be initially accessed and launched from \VS1Deployment$ as W7administrator (not VS1administrator) then the ztiutility.vbs try to properly authenticate with VS1 by using VS1administrator.

    Workarounds:

    1. Simply, change your W7Administrator's password to something else like 1111, reboot and try again.

    2. or, provide your current user's credential (Domain should be W7 instead of VS1)

    Please update the script to avoid this issue…

    Thanks,

    "

    I just changed the name from the remote computer that have MDT2010 to the local computer that I want to capture, and till now everything is fine.

  10. Alexander says:

    Something that I also did, was to drop the reference PC from the domain to Workgroup.

    Login with local admin password and connect to the DeploymentShare with your domain admin account.
    The PC is then successfully captured.

Comments are closed.