PDQ Deploy makes the fleet-wide button very easy to press. Discipline is what separates a rollout from an incident: the same package, released in rings, with a tested way back. The cost is a day of patience; the saving is the week a bad fleet-wide push can burn.
Every experienced admin has one story of a deployment that went everywhere at once and broke everywhere at once. The defence is procedural, not technical: pilot, waves, rollback. This page lays out the ring pattern that fits PDQ Deploy's tools — collections for the rings, schedules for the waves, and a prepared package for the way back.
Deploy to the IT machines first and actually use the software there for a day — open the files it should open, print what it should print, run the integration it feeds. Automated success codes cannot tell you the new version dropped a feature your office depends on; only fingers on keyboards can. A package that survives Ring 0 with real work done has earned its next ring.
Build each wave as a target list or collection — a department, a floor, a site. Size waves by your support capacity, not by optimism: if every machine in the wave failed at once, could you fix them today? Between waves, read the deployment history and scan for the new failure patterns. PDQ's schedules make waves easy to run in the evenings; the discipline is simply not promoting a wave that showed smoke.
A rollback plan made during an incident is not a plan. Before Ring 0, prepare the way back: keep the previous version's installer as its own package (with an uninstall step for the new version if the vendor requires it), and know whether user data or settings survive the downgrade. Test the rollback once in Ring 0 — deliberately break and restore one machine. Rollbacks you have rehearsed are procedures; rollbacks you have only imagined are wishes.
Tell each wave what is coming, when, and what will look different. Most rollout resistance is surprise, not software. A two-line notice — the accounts package updates Thursday evening, the icon moves, here is the one-page guide — converts a wave of confused tickets into a handful of informed questions. Note the schedule in the ticket system too, so the next morning's unrelated problems are not blamed on your update by default.
Decide the abort criteria before the rollout starts: a failure rate above a set line in any wave, one critical workflow broken, the vendor acknowledging a bad release. When a signal trips, stop the schedule — do not deploy the next wave while investigating. The fleet will forgive a delayed update; it remembers the morning everything broke at once.
The video gives you the speed; use it inside the rings. Watch the bulk deployment, then plan your next real rollout on paper before touching the console.
▶️ Watch Full VideoLong enough for real work to pass through the software — a full working day is the practical minimum for office applications, longer for software used in weekly or monthly cycles like payroll-linked tools. If the pilot group does not actually exercise the app, time alone proves nothing.
Some upgrades are one-way (database schema changes are the classic case). Then the rollback plan changes shape: full backups or VM snapshots of the affected systems before the wave, and a smaller, slower Ring 0. One-way doors deserve more testing, not more hope.
Yes — one schedule per wave, aimed at that wave's collection or target list, a day or an evening apart. Schedules are a paid-edition feature; in free mode the same discipline works with Deploy Once per wave, just with you pressing the button each time.