PDQ PowerShell Scanner best practices

PDQ PowerShell Scanner best practices are all about controlling script output. Use $null, clear error handling, structured objects, Select-Object, and centrally stored .ps1 files to return only the data you need, keep errors readable, and make scanners easier to maintain.

Cast unwanted PowerShell output to $null

The PowerShell Scanner processes the PowerShell object stream, so any unwanted output written to that stream can interfere with clean scanner results. To keep scan results clean, assign unwanted output to $null before the command so it does not add extra data to your scanner results in PDQ.

A great example of this would be if you need to install a module.

This allows NuGet to be used, but it also drops some output that looks like this.

This output will show up in your scanner, which we don't need. Putting $null = in front of that line removes all output from that line.

If you have completed a script and are ending up with more than you want in your results, this helps you remove everything that you don't want.

Use clear error handling in PowerShell Scanner scripts

Use clear error handling when a missing service, file, module, or permission should stop the scanner. A targeted throw message makes failed scan results easier to understand without opening the script or rerunning the scan manually.

For example, if your script requires a service to be running, you can test to make sure that it is, as well as put whatever you want in the error, so you don't have to dive in.

Now, if you run this against a computer that fails to meet the coolness requirements, you'll have a clear message informing you to get to hipper waters stat.

Return only the objects and properties you need

Return only the properties you need so your PowerShell Scanner results stay focused and easy to read. When a command returns more data than you need, use Select-Object to keep existing properties or [PSCustomObject] to build custom, predictable columns in PDQ.

For example, Get-Acl returns several properties about a file or folder, including the path, owner, access rules, and more.

With this, we are looking into our file, but we are grabbing the path and the owner. We don't need that, all we need is who has access to it.

There we go, no unneeded information cluttering our precious database.

Return structured data, not console text

PowerShell Scanner results are easiest to work with when your script returns structured PowerShell objects instead of console-style text. Avoid using commands that are meant only for display, such as Write-Host, Format-Table, Format-List, or Out-String, because they can turn useful object data into plain text.

Store scanner scripts in reusable .ps1 files

You can paste a script directly into the scanner, but a stored .ps1 file is easier to version, review, reuse, and update. If the same scanner runs in multiple places, updating one script file is much simpler than editing the script in every scanner configuration.

Use PDQ PowerShell Scanner examples as a starting point

For real-world PDQ PowerShell Scanner examples, check out PDQ’s PowerShell Scanners repository. It includes prebuilt scanner profiles, examples you can learn from, and contribution guidelines if you have a scanner worth sharing.

There are some great scripts in there that will give you some great data on your machines, as well as help you get started on creating your own. Before using an example scanner, review the output and make sure it returns only the data you actually want to store.

PowerShell Scanner FAQs

What does the PDQ PowerShell Scanner capture?

The PDQ PowerShell Scanner processes the PowerShell object stream and stores structured object output as rows and columns. Return PSCustomObject data only, and suppress logging, status messages, strings, formatted output, and other unwanted output.

Should PowerShell Scanner scripts use Write-Host or Format-Table?

No. Avoid Write-Host, Format-Table, Format-List, Out-String, and other console-focused output in PowerShell Scanner scripts. These commands can convert structured object data into display text, which prevents PDQ from reliably detecting columns and values.

How should I handle errors in a PowerShell Scanner script?

Use a targeted throw only when a missing service, file, module, or permission should stop the scanner. If the condition is expected inventory data, return it as a property on a PSCustomObject instead of writing text or status messages to the output stream.

Where can I find PDQ PowerShell Scanner examples?

You can find PDQ PowerShell Scanner examples in PDQ’s PowerShell Scanners repository. Before using an example, confirm that it returns structured objects only and does not exceed scanner limits for rows or columns.

Final tips for cleaner PowerShell Scanner results

Clean PowerShell Scanner results come from controlled output, predictable columns, readable errors, and reusable scripts. Keep each scanner focused on the data you actually need, test before scanning broadly, and use shared script files or Git when you want easier maintenance.

The great thing about PowerShell is that it can do just about anything you can imagine, including ensuring your drives are healthy and tracking connection speed! If you stick to these few guidelines, you'll have a much easier time getting all the data that you need most.

Try PDQ Connect today to use the PowerShell Scanner and become the envy of your peers. Go forth and PowerShell!