Run As options in PDQ Deploy

Shane head shot
Shane Corellian|Updated January 26, 2021
Generic blog header
Generic blog header

We recently started this new series to bring you delightful little nuggets of information for PDQ Deploy. Last time we brought you details on the Copy Mode, today we bring you the Run As options.

There are situations when you need to change up how PDQ Deploy will run deployments. For the most part, running a deployment as the Deploy User is appropriate and, indeed, recommended. There are instances when you need to run certain package steps (or even entire packages) as a Logged on User or as the Local System account.

Why waste time with small talk, let’s get right into the meat and potatoes.

Fine Tune Your Run As Options

Run As can be changed globally via Preferences > Deployments, but we strongly encourage you to only change the Run As option as needed at the Package, Package Step or Deployment levels. Below are some examples of appropriate situations to modify the standard Deploy User option.

Logged on User: This attempts to run packages in interactive mode as the Logged on user of the target machine. This setting is only available in Pro or Enterprise mode.

Example: Use when you need to access the %APPDATA% folder or HKEY_CURRENT_USER hive of a user that is logged onto the target machine during deployments.

Example: Use when you need to start a process as the Logged on User (as opposed to the Deploy User) or need access to the logged on user’s desktop. Note that when you run as the Logged on User then you inherit the permissions that user has. If that user is not a local administrator AND the steps you are performing require Administrator access then your steps may fail.

Local System: This option is largely based on any policies and procedures that your organization may have.

Keep in mind: When you run a package or a step as Local System you won’t have access to remote file shares. If you are running a script in this way and the script needs to access a UNC path somewhere it will most likely fail. Occasionally you may run into a program that requires that it be installed via Local System. I saw this years ago with Lotus Notes.

Deploy User (Interactive): This option should really only be used when the Deploy User account needs access to a desktop session or you want the end user to see some part of the deployment (but still have that step running in an Administrator context). This setting is only available in Pro or Enterprise mode.

Example: When it is appropriate seems to be when deploying Autodesk software like AutoCAD or Revit. Those applications are designed to be “silently” installed so long as the installer has access to an interactive session.

Logged on User in Action

Let’s take a look at the Dropbox package for an example. Steps 1 and 2 are run as the standard Deploy User, however, Steps 3 and 4 start Dropbox if a user is logged on (Logged on User).

In Step 4 we list the command to run Dropbox on the target.

2bc7657e-8e06-4582-bf74-ae301ac1df10

Notice we list the conditions to run the command. Pay special attention to the Logged On State. We will only run this step if a user is logged on.

23265602-b90c-4be0-b602-3bdcdce43d75

We set this step to run as Logged On User.

Deploy User (Interactive) in Action

Here is a package which installs AutoCAD LT. The installation itself runs silently but it does require access to an interactive desktop. In a case such as this you would want to have your Run As set to Deploy User (Interactive).

Stay tuned for the next tidbits so you can become a PDQ Deploy Master.

Shane head shot
Shane Corellian

Shane is the co-founder of PDQ.

Related articles