TL;DR: When you inherit PDQ, treat it like a live production system: observe first, change later. Map out what runs automatically, confirm how devices are grouped, and learn the workflows tied to deployments, inventory, reporting, and maintenance. Once you know what PDQ is already handling, start with one low-risk task, test it on a small group, document the results, and build from there.
When you inherit PDQ, start by taking a quick look around at what is already configured before making changes. Review existing packages, schedules, automations, and deployment history so that you understand how PDQ is managing your environment today.
Starting a new sysadmin job and finding PDQ already installed can feel like finding a very useful button labeled “Do not press unless you know what this does.” The good news: You do not need to become an expert on day one. PDQ gives you practical ways to deploy software, track inventory, automate maintenance, and troubleshoot endpoints once you know where to look.
Loading...
What should you do first when you inherit PDQ?
Your first job is to figure out what PDQ is already doing.
Start by taking a walk around the Deployments dashboard. Look at which packages have been deployed, which machines they targeted, which groups are in use, and what runs automatically. This reconnaissance will give you a detailed view of all deployments in your environment, including which ones have succeeded or failed and why.
In many environments, your PDQ instance may already include custom packages, dynamic groups, schedules, reports, and more.
What PDQ features should new sysadmins learn first?
New PDQ admins should focus first on dynamic groups, the PowerShell Scanner, and automation workflows. These features help you understand what is in your environment, target the right endpoints, and reduce repetitive manual work.
Dynamic computer groups with filters
Dynamic groups use filters to group computers automatically based on specific criteria. Instead of manually updating static lists, you can create groups that update as device data changes.
This matters because targeting is everything. If you need to deploy software only to machines missing an application, identify devices with outdated versions, or isolate computers with a specific configuration, filters give you the control to do it without spreadsheet gymnastics.
PowerShell Scanner
The PowerShell Scanner lets you collect custom inventory data from endpoints using PowerShell scripts. That data can then support reporting, targeting, and deeper visibility into your environment.
Use it when built-in scanners do not capture the exact data you need. For example, you can collect application-specific settings, registry values, service states, Windows activation details, or other custom data that helps you make better deployment decisions.
Automations
Automations connect conditions to actions so PDQ can handle recurring work with less manual intervention. Depending on your setup, that may include scheduled deployments, packages tied to inventory groups, recurring maintenance tasks, or other repeatable workflows.
This is where PDQ starts to feel less like another console and more like a coworker that actually does the boring stuff. Start small, test carefully, and document what each automation is supposed to do.
What can you use PDQ for?
PDQ helps sysadmins manage software, run scripts, track inventory, generate reports, and troubleshoot deployment issues across their endpoints. The best use case to start with is usually the one that removes the most repetitive work from your day.
Software management
Use PDQ to manage common software tasks across your fleet:
Deploy applications to multiple computers
Push updates and patches
Remove unwanted or outdated software
Standardize application versions
Test packages before broad rollout
System maintenance
Use PDQ to run remote maintenance tasks without logging in to each machine:
Run scripts for configuration changes
Execute PowerShell commands remotely
Restart services
Apply registry changes
Perform routine cleanup tasks
Inventory and reporting
Use PDQ to understand what is installed, configured, and potentially out of compliance:
Track installed software across endpoints
Monitor hardware configurations
Identify missing or outdated applications
Build reports for audits or internal reviews
Use groups to surface machines that need attention
Troubleshooting
Use PDQ deployment history and output logs to understand what happened when something fails. Failed deployments are not fun, but mystery failures are worse. Check output logs to identify failed steps, return codes, permission issues, offline targets, and other problems that explain why a package did not land as expected. Then fix the package, target, credential, or condition before trying again.
Common PDQ use cases and features
Use case | PDQ feature to use |
Scheduled patch management | Automations and Package Library |
Email alerts for missed updates | Automations with Notifications or Zapier |
Inventory reports | Reports and Groups |
Condition-based restart enforcement | Packages with step conditions and Automations |
PowerShell scripts on targeted groups | Custom packages and Groups |
Battery health monitoring | PowerShell Scanner |
Firewall validation | PowerShell Scanner or Registry Scanner |
Mapped drive verification | PowerShell Scanner |
New-build auto-provisioning | Groups and Automations |
Dynamic groups by app version | Groups with Software filters |
Sentinel file or flag file logic | Package step conditions for file existence |
Install log files | Custom package step that writes to a log path |
Where can you learn from other PDQ admins?
The PDQ community can help new admins see how real sysadmins use PDQ in production. Reddit, PDQ’s Discord, PDQ documentation, and community examples are useful when you are stuck, validating an approach, or looking for ways to solve a weirdly specific problem that somehow affects 47 machines.
Use community advice as inspiration, not gospel. Every environment has its own constraints, permissions, naming conventions, network quirks, and mystery devices that nobody wants to claim. Test anything you borrow before rolling it out broadly.
How can you get started without breaking anything?
The safest way to start with inherited PDQ is to observe first, test small, and expand gradually. Do not change broad schedules, production packages, or dynamic groups until you understand what depends on them.
A safe first workflow looks like this:
Review existing packages, group, schedules, and reports.
Check recent deployment history.
Identify one low-risk task to test.
Deploy to a small group of test machines.
Review the results.
Adjust the package, filter, or schedule as needed.
Document what changed before expanding the rollout.
This keeps you from turning “learning PDQ” into “accidentally deploying Java to Accounting at 4:55 p.m.” Nobody needs that character-building exercise.
What should you do next?
Inheriting PDQ means inheriting a powerful endpoint management setup, not just another tool to babysit. The key is to understand what already exists, master the features that affect targeting and automation, and expand your use cases as your confidence grows.
Focus first on the problems PDQ can solve right away. That may be software deployment, inventory reporting, patch visibility, scripted maintenance, or cleaner troubleshooting. Once the basics click, you’ll start finding new ways to save time, reduce manual work, and make your environment a little less haunted.
Manage Windows & macOS devices from anywhere
With PDQ Connect, get real-time visibility into remote and local devices, deploy software, remediate vulnerabilities, automate routine maintenance, and remotely troubleshoot endpoints from one easy-to-use platform.
