Help Center


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


The computer is already connected via SMB (file and printer sharing) to another computer and a new connection is being attempted with a different user name.

Possible Causes

The most common cause is having a mapped drive connected to a share on the target computer with a different user name than that used by PDQ Deploy or PDQ Inventory. 

Recommended Fix

Disconnect all previous connections to the target computer and try again. 

***Updated 2014-12-02***

The target computer may not be processing the domain name in the credentials as expected. If your credentials are using the fully qualified domain name (FQDN) for the domain then try creating a new set of credentials using the same account but the short name of the domain. (e.g. Instead of try raindog). Reverse this if you are already using the short name.


Was this article helpful?
0 out of 1 found this helpful
Have more questions? Submit a request


  • 0

    I have to say this is going to be an issue for most business users. Who DOESN'T have mapped drives to shares for their users, especially when working with server storage etc.

    Surely there should be a fix for this by now. I'm constantly having to reboot either my pc (deploying) and/or the target pc just to get a deploy to work.Or am i missing something here?

  • 0

    Unfortunately, this is a limitation in Windows and it's unlikely that it's going to be changed.  

    Are you running into this issue because you have mapped drives on your computer to shares on the computers you're deploying to using a different user name? We've seen this caused in some cases where the two connections use the same account but just different names, like domain.local\user and domain\user. 

  • 0

    Hi Adam,

    no every user has a set of mapped drives that connect to shares on a central server on the domain. That's it really. Standard setup for most domain environments i'd imagine. So must be loads of people suffering from this issue too.

  • 0

    Are you using the Pull Copy option in your deployments? That could be an issue if the files are on the same computer where there are already mapped shares since the target computer needs to make an outbound connection to the same server. 

  • 0


    I keep getting this error, and I have never gotten it before. Seems to be a bug.



  • 0

    Hi Aaron! What kind of connections (particularly mapped connections) to these target computers exist? We (PDQ products) are still beholden to Windows and particularly SMB when it comes to connections. There are times when this error is thrown and it usually comes down to mapped resources. You can see in the  image below that Windows threw this error when I tried to map two different sessions using two different credentials to the computer, Homer.

    Does your console machine have any mapped sessions to the target? Does the target have a mapped connection to the console or to a file server containing files for deployment? (Pull Copy mode)



  • 0

    Ok, i'm still getting this even after rebooting my win8.1 pc that holds the PDQ software and the target pc is on but not even being used.

    It makes no difference whether i use the PUSH or PULL copy mode, some deployments are from the package library, some are made by myself which have been proven to work in the past.

    I really don't get this mapped drive business. I'll try and explain as fully as i can my situation:

    DEPLOYMENT PC (win8.1 pro)

    Logged in as me. Has mapped drives to server shares.

    TARGET PCs (win7/8.1 pro)

    Logged in as standard domain user. Has mapped drives to server shares. Some shares are the same as the DEPLOYMENT pc.

    Trying to deploy to target pc which has 'some' of the same mapped drives, but not all. The PDQ deployments are on a unc path and use domain\administrator credentials to deploy software.

    Sometimes, i reboot both deploy and target pc and still get the 'multiple connections..." errors.

    Not wanting to play devils advocate here, but if you say "We (PDQ products) are still beholden to Windows and particularly SMB when it comes to connections" then that surely pretty much screws most of what PDQ Deploy does?! Most if not ALL organisations i know have mapped drives for domain users as a group policy or logon script. So there's no getting out of that setup.

    I can't believe that the only fix is to reboot the deployment and target computers in the 'hope' that it will then work.

    Or am i still missing something here?

  • 0

    Hi Kevin,

    Sorry for the frustration. Yes, the majority (I'd say vast majority) of our customers utilize mapped drives throughout their networks. This issue rarely pops up and when it does it always comes down to what we had mentioned before with multiple connections with different credentials. 

    To figure out exactly where you are having the problem I'd suggest that we move this to a support ticket. The reason for this is that some of the data I'll need (server names, user names, etc.) aren't appropriate on a public forum.

    Submit a ticket and we'll get back to you. 



  • 0

    Hi Shane and Kevin,

    I had the same problem today, I'm not sure if it helps but I think I resolved it in my case by running remotely this command: net use * /delete /y

    with the same user I use to use for deployments.

    Hope this help,

  • 0

    Hi Josué,

    thanks for the info, but are you saying you remoted into the target pc from the deployment pc and ran the command?

    Problem is that my users are undoubtedly working with files that are on the mapped drives, that's how most people would work i guess. So i can't remotely disconnect their drive whilst they're working.


  • 0

    Hi Kevin,

    For instance through PDQ Inventory, you can select one or several machines then run a remote command through the tools menu. Once open, check the "Credentials" user. Use the same user you use to deploy package through PDQ Deploy. Then run the command: net use * /DELETE /Y

    This, apparently, WILL NOT unmap the drives of the current logged user (tested). Even if the deploy user = logged user, for some reason... (tested as well).

    Hope this help,

  • 0

    It seems not to solve the problem actually... I have more and more machines with this error.

  • 0


    I tried something that works for me, could you try it on your side to confirm please?

    I duplicate the package (right click and Duplicate), then I deploy once a computer that had the error

    "Multiple connections to a server or shared resource by the same user" then the deployment works for this time.

  • 0

    *** TRY THIS***

    We just spoke with a customer who was seeing this problem. The issue seemed to be related to DNS and Windows authentication. The customer used the FQDN (long name) for his Windows domain in his credentials (Preferences window). We created a new set of credentials but instead of the FQDN we used the short name. We changed the background service to use the shortname credentials and we made sure the deployment user used the same shortname and the issue went away.

    It appears that SMB on the target was resolving the FQDN to the shortname during the authentication phase however when the deployment service was created it attempted to use the FQDN (after the credentials passed) and this triggered the Windows limitation of multiple connections using different credentials. 

    If you are seeing this issue try this. Create new credentials. If you are currently using the FQDN of the domain then switch to the shortname. If you are currently using the shortname of the domain (and still seeing this issue) try using the FQDN. The image below shows two credentials. One uses the FQDN and one uses the Shortname. 



    What is odd is that this issue usually relates to DNS on the target computer not resolving one of the domains. This usually results in an Access Is Denied error since it can't resolve the domain. In this case, however, the credentials passed but then Windows threw the multiple connections error. 

  • 0


    This worked for me!!!!

    Thank you so much!


  • 0

    Glad to hear it worked for you, Aaron. Thanks for getting back to us.

  • 0

    It works for me too, thanks Shane!

  • 0

    Holy macaroni, it worked!!!!!

    i tested a deployment to a tablet with the FQDN creds and it failed. I selected 'redeploy' but chose the new shortened creds and it worked.

    Shane, thank you so much for persevering with this, it really was a big issue for many of us, you da man!

    Onwards and upwards :)

  • 0

    I'm just now getting a similar error message. This is in a workgroup environment and happenes while scanning the computer that is running PDQ Inventory. I scan all computers and all others are OK but this one. No FQDN. Above fix does not seem to apply here. Or?...

  • 0

    Hi Paul. If you are only getting this on the machine that is running PDQ Inventory then I would gather there is another session somewhere. Try running the command net session from cmd.exe. Do you see any connections? Are you using PDQ Deploy as well? If so, are both Deploy and Inventory running the same account for each background service?

  • 0

    Hi Shane. Thanks for the reply. This is what I have found as of 1-Jun-2015. Running Windows 7 Pro 32 bit. This has both PDQ Inventory, v. and Deploy, v. installed using the same account. Updates are installed when I see the notice on each program's bottom status bar. I don't seek out updates and assume that running different version levels is not a problem.


      Running net session shows no connection until I run either PDQ Inventory or Deploy. I do not find multiple sessions and session status doesn't seem to matter during these tests.


      So, starting from a fresh reboot, I find two PDQ services running: PDQDeployService.exe and PDQInventoryService.exe. At this point, if I run PDQ Inventory, scanning this computer fails. If I kill PDQDeployService.exe, I can scan this computer successfully. If I then run PDQ Deploy, I see that PDQDeployService.exe restarts (along with the client program), but I can scan this computer without errors. I can even run a deployment on this computer and initiate a scan during this deployment without error. When I quit PDQ Deploy, PDQDeployService.exe is still up, but I can also still scan this computer without errors - until I reboot.


      I tested this routine multiple times and every time was consistent as described above. So I now know what to do to get it to scan. Thank you.




  • 0

    confirming! ist working, many thanks

  • 0

    Restarting the PDQ Deploy Service worked for me.

  • 0

    I just tried that (Restarting PDQ Deploy service) and that does not work for me. Now running fresh install of Windows 10 x64 Pro. I have to stop the Deploy service in order to scan this computer. I don't see a need to have the Deploy service running when Deploy isn't running. No scheduling here.

  • 0

    I tried the FQDN trick and it didn't work, here's what worked for me:

    On the target computer

    CMD > net session. net session /delete

    Restart computer

    On the PDQ Server

    Delete the computer from inventory. Restart the PDQ Deploy service, restart the PDQ Inventory Service. Re-add computer to inventory. Then redeploy package.

Article is closed for comments.