Installing the same software on 100 PCs one desk at a time is a full week of walking. PDQ Deploy turns it into one package, one target list, one click — the installs run silently in the background and the users keep working. This guide walks the whole workflow, from installation to automation, in the order you will actually use it.
PDQ Deploy is agentless Windows deployment software: nothing is installed on the target PCs. The console copies the package files to each target, runs the installer silently with administrator rights in the background, and reports success or failure per computer. Below is the complete flow — setup, first package, targeting, then automation — including the honest parts: what the free mode cannot do, and which features need a paid edition.
Three things, all from the video. First, PDQ Deploy itself, installed on one admin PC or server — that machine is the console and it must be able to reach every target over the network. Second, a 14-day trial from pdq.com, activated with a business email, which lets you test the full product before paying anything. Third — and this is the requirement the video stresses — one administrator account that works on every target PC, the same username and password added as local admin on all systems, or a domain account with local admin rights. PDQ Deploy connects with that account, copies the installer across and runs it; without admin rights on a target, that target simply fails.
Inside PDQ Deploy, open Options / Preferences → Credentials and add the administrator account. This becomes the Deploy User — the identity every deployment runs as unless a package says otherwise. Test it early: pick one friendly PC, deploy something tiny, and confirm the account truly has admin rights there. Nine out of ten first-day failures are this single account missing from some PCs, not a software fault.
Do not build your first package by hand. Open the Package Library — PDQ maintains hundreds of ready-made, silently installing packages for common software like Chrome, Firefox, Adobe Acrobat Reader and Notepad++, and keeps them updated. Download one, and PDQ stores the installer in its repository on the console. Select the package, choose Deploy Once, add two or three test computers, and watch the deployment window report each target: running, then success. That loop — package, targets, deploy, result — is the whole product in miniature.
Typing PC names works for five machines and falls apart at fifty. PDQ Deploy can pull targets from Active Directory, from text lists, or — the option that changes everything — from PDQ Inventory collections. A collection is a live group (for example, every PC with an old Chrome version). Deploy to the collection and you are always pushing to exactly the machines that need the software, never a stale hand-made list. The video shows the AD integration; the Inventory tutorial on this channel covers collections in depth.
For software that is not in the library, build a package. A package is a list of steps: an Install step for an MSI or EXE with its silent switches (for example /qn /norestart), a Command or PowerShell step for configuration, a File Copy step for dropping a config file, and a Reboot step when the software demands one. Multi-step packages like this are a paid-edition feature — in free mode a package is limited to a single Install step, which is an honest limit to know before you design around it.
Manual Deploy Once is only the start. Schedules (paid editions) push packages at a set time or on a recurring rhythm — patch Tuesday evenings, for instance. Auto Deployment (Enterprise) goes one step further: when PDQ publishes a new version of a library package, it downloads and deploys it on your schedule, so standard software patches itself. And Heartbeat schedules fire the moment an offline laptop comes back online, catching the machines that were shut during the main window. This ladder — manual, scheduled, automatic, heartbeat — is how a 100-PC job becomes a background process.
Every deployment lands in the deployment history with a per-target status and, on failure, an error or exit code. Learn to read it before you retry anything: a success code of 3010 means installed, reboot pending — not a failure. 1603 means the installer itself died and needs investigation on that PC. Successful deployments are the ones you verify — a follow-up Inventory scan showing the new version installed is proof; a green tick alone is a claim. The failed-errors guide in this series decodes the common codes one by one.
The video shows the complete journey — installation, package creation, silent installs for EXE and MSI, PowerShell steps, schedules and Active Directory targeting — with a live deployment to many PCs.
▶️ Watch Full VideoNo. PDQ Deploy is agentless. The console connects to each target with the deploy account, copies the package files across the network, runs the installer in the background, and cleans up after itself. Nothing stays installed on the target except the software you deployed.
Deploy Once is a manual, immediate deployment — you pick the package and targets and it runs now; it is also the only deployment method in free mode. A schedule (paid editions) stores that job and runs it at a set time, on a recurring pattern, or on a heartbeat trigger when offline targets come back online.
Yes, with Auto Deployment in the Enterprise edition. Library packages can be set to download new versions as PDQ publishes them, and an auto deployment schedule pushes those versions to your targets without you touching the console. Standard schedules in the other paid editions cover recurring pushes of any package.