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 Options > Preferences > 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.
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.
In 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.
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 deadwood.com\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:
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 (Options > Preferences > 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.
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