Help Center


How It Works: PDQ Deploy

You wish to understand how PDQ Deploy installs software. This can be helpful in troubleshooting deployment issues.

Depending on your PDQ Deploy preference settings, there may be slight variations in the process outlined below.

Package Files on the PDQ Console Computer:
First, we create/import a PDQ Deploy package for Microsoft Silverlight 5.1. Opening the package and selecting an Install Step, the Install File location is $(Repository)\Microsoft\Silverlight\Silverlight-5.1.50901.0.exe.

From the image above, the Install File is placed in the $(Repository). The Repository is a system variable defined by OptionsPreferences > Repository. By default, the Repository folder is located in %PUBLIC%\Documents\Admin Arsenal\PDQ Deploy\Repository.

PDQ Deploy Credentials:

PDQ Deploy utilizes three sets of credentials. They can be the same credentials or different, depending on the needs of your environment.

Background Service:
The first set of credentials are the
Background Service credentials, located in Options > Background Service. These credentials were supplied when PDQ Deploy was first run.

underthehoodedit1.pngIn the above example, the PDQ Deploy Background Service (called PDQDeploy) runs under the domain user account PDQUser in the deadwood.local domain.

NOTE: is not necessary the Background Service credentials have local admin privileges on target machines, but they are required to have local admin privileges on the PDQ console machines regardless whether the consoles are running Central Server or configured to run in Local Mode.

The second set of credentials are the Credentials as found in Options > Credentials. These credentials are the credentials used as the Deploy User and runs the deployments on target machines via the remote runner service.

IMPORTANT: As the Deploy User, the user(s) in Options > Credentials must be a local administrator on all target machines.


Console Users:
The last set of credentials are Console Users in Options
 > Console Users. These credentials are necessary if a user will be opening the PDQ Deploy console and that user is not the Background Service user. In this example, we’re opening PDQ Deploy using the\Jane.Doe credentials and not the deadwood.local\PDQUser credentials. Because of this, it is necessary to have Jane Doe listed in Console Users.

The deployment Credentials are set to DOMAIN.COM\PDQDeploy (see above). Here's an example using the Deploy Once window:


  • References to the Background Service applies to the Background Service running on the PDQ Deploy console computer. References to the Runner Service refers to the service running on the remote target computer.
  • When deploying to targets in child/sub-domains using a domain-specific account, OR to targets in a workgroup, it is necessary to Disable UAC.
  • For more information on Console Users (Options > Background Service), see Our Handy Video.
  • In Options > Credentials, the (default) user credentials are the default deployment credentials.

Package Deployment Process:

Using the examples above, there are three target computers: Guinness, Heineken, and Lopan.

Step 1: The PDQ Deploy Background Service attempts to retrieve the installer file, Silverlight_x64-5.1.50901.0.exe from $(Repository)\Microsoft\Silverlight\.

In Pro and Enterprise Deploy, there is a Copy Mode option (OptionsPreferences > Performance). The default method is "Push". If the Copy Mode is changed to "Pull," the Background service will not attempt to copy the files down to each target. Each target will attempt to Pull the files down using the Runner service. In this case, the deployment Credentials (Options > Credentials) MUST have full access to the package files. For more information about Push and Pull, please see This Document and This Document.

Step 2: Using the Deployment Credentials the Background Service attempts to copy  Silverlight_x64-5.1.50901.0.exe to the following paths:


Some antivirus application may prevent copying into the ADMIN$ share. You may need to exclude the %WINDIR%\AdminArsenal directory from the antivirus real-time scanning.

Step 3:
A Windows Service is created on each target and is called PDQDeployRunner-n (-n will usually be "1"). As explained above, this is referred to as the "Runner" service. The Runner service is set to run under the Deployment Credentials. For this example, we've used deadwood.local\DeployUser (see image below).

There are option available when deploying a package to have each step Run As either Deploy User (use package settings), Deploy User, Deploy User (Interactive), Local System or Logged On User. We recommend using Deploy User (use package settings) or Deploy User but there may be times to change this behavior. If a step's Run As option is set to Local System, the Runner service is created using the Deployment Credentials (deadwood.local\DeployUser) but the service runs as Local System (or whatever Run As option was selected).

Step 4: The Runner service is created and performs an evaluation on the Conditions for the step. If the Conditions are met, the Runner service begins to run the first Step in the package. If any Conditions are not met, the step is skipped and the process (evaluation) is replicated on the second step. Conditions are evaluated as Local System, which can cause curious results if a file condition exists to look for something within a user profile using a variable like %userprofile% even if the step is set to run as "Logged on user".

In this example a 64-bit OS would not pass the first step’s Conditions but it would pass the second step’s.

An evaluation of step conditions is performed on each package step, since there are cases where the conditions might change from one step to a later step (e.g. updated PowerShell version, logged on state, a file or registry condition).

Step 5: In the case of our Silverlight install, when a Step runs and meets all conditions, it executes the files or commands from %WINDIR%\AdminArsenal\PDQDeployRunner\service-1\exec\Silverlight_x64-5.1.50901.0.exe on the target computer and passes the /q parameter (the /q in the Install Step’s Parameters field).

While MSI (and friends) have relatively standard silent parameters that are included in those Install steps, executable (*.exe) installers can vary widely. Please see this video, Google Fu: The Art of Finding Silent Parameters, on how to find silent parameters/command line switches for your executable installer. For more information, see Considerations below.

Step 6: The Runner service waits for Silverlight installation to finish. A return code (also known as an Error Code or Exit Code) is sent from the Silverlight exe file and is returned to the Runner service on the target computer.

Step 7: At regular intervals, The PDQ console computer’s PDQDeploy service has been polling the Runner service on each target. When it detects the installation is complete (based on the return code) it returns the information to the PDQ Deploy database.

Step 8: The PDQ Deploy Console detects the change in Deployment status in the database and displays the deploy status (Success, Fail) based on the Success Return Codes specified in the Installer.


  • Install Step files with .MSI, .MSU or .MSP extensions are automatically passed the parameters needed to run silently. As explained above, If your installer file has another extension (such as .exe), you will likely need to include parameters/command line arguments in the Install Step, Parameters (Details tab). The parameters to run silently depend on the application being installed and are determined by the vendor of the application.

    IMPORTANT: If the PDQ package requires a silent parameter for the installer file and no silent parameter is provided, your deployment will likely hang or result in an error.

    When an application is installed from PDQ Deploy, windows that are normally shown when an application is installed (such as accepting a EULA or choosing an installation path) cannot be viewed. If the Installation is expecting user input, nothing can provide that input since all installation windows are hidden.
  • A return code is defined by the Vendor of the application your are deploying or the OS. In the Silverlight example, the return codes are provided by Microsoft. Return codes help determine the installation state. In many cases, the standard return code for a Success is 0. Other non-zero Success codes are 3010 and 1641. If any code is returned that is NOT specified in the Success Codes field (Details tab), the installation will be marked as a failure.

    The vast majority of error codes deal with problems outside of PDQ Deploy and deal with the specifics of the application being deployed.

    Microsoft has a list of Return Codes returned by the Windows Installer. You can find other Microsoft Return Codes here.

See Also:
Background Service Documentation
Adding Console Users to PDQ Deploy
Can’t Access ADMIN$ Share Using a Local User Account
Windows Firewall Ports And Exceptions
Service Manager Access Denied
PDQ Deploy: Understanding Push and Pull Deployments
Windows Installer (MSI, etc.) Return Codes
Microsoft Return (“Error”) Codes

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


  • 0

    Just a tag question from the forum...


    I am pushing out a basic Powershell script for my SAN team to collect some server info. Using PDQ deploy. It worked fine. It only failed on boxes that had no Power shell installed (duh lol).   My question is where exactly does pdq deploy create its folder on the target machine to copy and run the ps1 script? and does it delete it afterwards?

    Reason being is at the end of the powershell script a .cvs output file is created in that same location of the .ps1 file... We want to know where that output file is going? If the share gets immediately deleted then we will have to change the out put location..


    Please let me know.



  • 0

    **Updated**The directory does get deleted when PDQ Deploy is finished. The directory is:


    Note: the "\service-_n_ is usually service-1 but it could be service-2, service-3, etc. depending on other concurrent deployments to the target from other PDQ Deploy consoles)

  • 0

    I have a question concerning remote deployment preferences. Concerning deployment across a WAN, is it preferred/faster to have the installation files on a server on the same subnet as the machine to which you are installing, or to use files only on the main network server. When I use GPO to install msi files, I make copies on all of the domain controllers and create separate GPO's for each site. Should I follow this same idea when using PDQDeploy or will this actually double the time required as the files transfer back and forth across the WAN? Thank you.

  • 0

    Hi Jason,

    If you have slow WAN links then you'll probably want to utilize the Pull Copy Mode along with Microsoft's DFS. You can specify the Copy Mode via a default global setting (File > Preferences > Performance or per package (edit the package, Select the Package node).

    Every package that uses a Pull copy must have the Install File (and any files specified in Additional Files) available via UNC. If you use DFS then move your Repository to a share in the DFS schema via Preferences > Repository. Copy all of your existing folders in your current repository folder to the new location. 

  • 0

    Thank you Shane. I notice that none of those options are available on the free version of PDQDeploy, so therefore I will continue to push from one server across the WAN. Thank you for your quick response.

  • 0

    Hi Jason,

    Remember this one point: Free mode uses the Push copy mode. This means that the PDQ Deploy console will literally push the install files down to each target. If the install files reside on a file server then the console machine will copy the files down to itself and then push them out to the targets.

    Basically, in Free mode it is best to have the packages stored on the console machine.

  • 0

    I would like to add this. The service directory has changed, where # equals the number of the service

    Ran into this after updating PDQDeploy from v2 to v3 and 1 of my deployment stopped working (it passes a parameter to the service directory).

  • 0

    I have a tool that runs on the PDQ Deploy server. It is called delprof2.exe and deletes all user profiles older than for example 90 days.

    syntax: delprof2.exe /c:<computername> /d:90

    How would I use this in PDQ deploy. I do not want to trigger this on the remote computer but on the deploy server itself. Any thoughts on this?


  • 0


    You would use PDQ Deploy only if you wanted to have DelProf2 executed from the target itself. If you want to run from the PDQ machine (using the /c:%computername% syntax) then I would recommend using PDQ Inventory and creating a Custom Tool.  Here is a video example of using the Custom Tools feature to initiate a DameWare Remote Control session on the selected target computer. In your case you'd be calling DelProf2. To pass the Computer Name of the selected computer you would use the variable %TARGET%.

Article is closed for comments.
Powered by Zendesk