How installer files get to target computers with PDQ Deploy

One of the questions we often get about PDQ Deploy has to do with how the installer files get to the target computers. There are two different ways to install software on a computer over the network, each with strengths and weaknesses. The choice whether to copy the installer files to the target machine before installation or to run them directly off of a file share is not always obvious. Neither option is perfect for all situations and some of the considerations are:

1. Security. Network policies may prevent running executables over the network. This can be a particular problem with deployment tools (more on this below.)

2. Performance. Depending on what is being installed, its size, or how the installer was built – one method may be faster than the other.

3. Disk space. Installing directly from the network typically takes less space during the installation.

4. Bandwidth. Copying first and then installing uses bandwidth in a more predictable fashion. A file copy can be throttled and managed (with a deployment tool or file copy utilities like Robocopy) while an installation reading directly from a file share can’t.

5. Installer requirements. Some installers have problems when run over a network, but this isn’t very common. Others must be run from a share, there are some Office administrative installations that require this.

PDQ Deploy both use the option of copying the installer files to the target computers to install. We did this for two reasons. First, it’s the best option in most situations. Most installers are small enough that any extra overhead won’t be noticed, there’s less to do to get it running without having to set up file shares and permissions in advance, and installs can be copied directly from an administrator’s local disk. The other reason is that it’s easy to install directly from a file share when necessary while still using this method (while the the reverse isn’t always so easy.)

Installing from a File Share

It’s actually quite easy to install from a file share using PDQ for those situations where you need or want to. There are two things that you need to do.

First, create a batch file that will install from the file share (use a .bat or .cmd extension.) This batch file can then be installed and it will be copied to the target machine and not the installer itself. The batch file could be something as simple as this:

You will still need to be aware of silent command line arguments like you would when installing directly. If the installer is an MSI file, though, you will need to run the installer with msiexec.exe instead of directly. You can find the exact command-line you need by creating a deployment in PDQ Deploy and seeing what the full command line is:

Just put in the name of the MSI file:

You can also do a number of other things in the batch file such as set environment variables, map network drives, and run several installs at one time. I’ll have some blog posts on these more advanced topics in the future.

The second thing that you need to do is to properly set the authentication used during the install. When installing software remotely there are three different types of credentials that can be used:

1. A standard service account. This is usually Local System or Network Service. Neither of these accounts are going to have the sufficient rights to install software off of a share (this can be changed, but it’s not something that is typically done in most environments, it’s best to assume that no access will be allowed.)

2. An secondary token or impersonated account. Running an installer through WMI uses this method, it’s a feature of the Windows networking infrastructure. Impersonated accounts don’t have the necessary access to run installers from file shares. This is something known as the “double-hop” problem because the security token used by an impersonated account can’t itself be impersonated and make that second hop to the server, the first hop being from your workstation to the target computer. (This can also be changed but it requires configuring a Kerberos server to allow “delegation” which a very specialized thing only for the very brave.)

3. A primary token. Primary tokens can be used to run installers off of file shares, these can only be used if the application has the user’s password. When you log into your workstation you are giving your system your password for a primary token and that’s why you can access network resources. PDQ Deploy can both create primary tokens by using the “Use Other Authentication” option in PDQ Deploy. You will need to use one of these options to ensure that the batch file can access the files off of the share.

With a batch file in hand and the right authentication setting you will then have the best of both worlds: Copy the files to the targets for most deployments to keep things simple but have the power to use file shares when needed.

As always, feel free to drop our support site if you ever need any help with a specific installation. Happy deployment!