Every office has one application no library carries — the accounting package, the in-house tool, the vendor oddity. A custom PDQ Deploy package handles it, but only if the install runs truly silent. This guide is about the switch hunt: how to find the right silent parameters for any installer, every time.
A deployment that pops up a setup wizard on 100 screens is worse than no deployment — the installer waits for a Next button nobody should click, and the job eventually fails or times out. The whole craft of a custom package is making the installer run unattended, start to finish. Here is the method technicians use, in the order that works.
An .msi file is easy: it is a Windows Installer package and always answers to /qn (no interface) and /norestart. An .exe could be anything, so identify it before guessing: right-click → Properties often names the maker (Inno Setup, NSIS, InstallShield), and simply running setup.exe /? in a test machine frequently prints the supported switches. Guessing switches blind is how wizards end up on user screens.
/? or /help on a test PC and note what it offersCreate a new package and add an Install step pointing at your installer file — PDQ copies it into the repository. Put the switches in the step's Parameters field. Then set the details that separate tidy packages from messy ones: add 3010 and 1641 to the Success Codes so a requested reboot counts as success rather than failure; decide the Run As mode (Deploy User is the normal choice; Logged On User only when the install truly needs the user's session); and set error handling to stop the package if this step fails.
Real packages are rarely one step. A typical shape: a Command step first to uninstall the old version or close the running app, the Install step, a File Copy step to drop in the company configuration, and a Reboot step only if the software insists. PDQ also offers PowerShell steps for anything scriptable. Remember the edition rule: multi-step packages are a paid feature — in free mode you get a single Install step, so design simple or trial the full version.
Deploy the finished package to your own PC. Then to one cooperative user. Only then to a group. A custom package earns trust in rings, because every installer hides one surprise — a licence prompt, a .NET prerequisite, a reboot demand. Finding that surprise on two machines is a lesson; finding it on two hundred is an incident.
The video's package-creation section shows this build live, including EXE, MSI and PowerShell deployments — the perfect companion while you package your office's odd application.
▶️ Watch Full VideoWork the method: check the vendor site, ask the installer with /? or /help, identify the installer family from the file properties and use that family's standard switches, then test on a single machine while watching for windows. One of those four steps answers almost every installer.
Almost always an invisible prompt. The installer is waiting for input in a session nobody can see. Re-run it by hand with your chosen switches and watch: if any window, licence page or reboot question appears, the switch set is wrong or the installer needs a response file (InstallShield) or a different parameter.
Start with 0, and add 3010 (installed, reboot required) and 1641 (installed, reboot started). Many good installers return those instead of 0, and without them PDQ reports a successful install as a failure, which poisons your deployment history and any retry logic built on it.