Resolving PDQ Connect package failures with Sophos XDR

What you see

Error codes from PDQ Connect

Typical PDQ output looks like this:

Step failed, Exit Code: 1
The PDQ deployment log shows the step failed and returned code 1

Exit code 1 is a generic failure. It means the installer returned a non-zero exit status when PDQ ran it. Do not assume the installer binary itself is bad. PDQ can change the environment, working directory or account context.

Logs from the Sophos installer

If the installer supports a silent log switch, use it. If it does not, capture the console output when you run it manually. What you want to see is:

Installer starts and writes a log file
Final log line showing success (exit code 0) or an explicit error line

If the installer produced no log when run under PDQ, that points to a working directory issue or a partial download.

Common package installation errors

The usual causes I see are:

Wrong working directory, so the installer cannot find supporting files.
Partial or corrupted downloaded file. Get-FileHash will show this.
PDQ running the step under a different account (Local System) with different environment variables.
Relative paths used in the install step instead of absolute paths.
An installer step that needs an interactive desktop and fails under system context.

Where it happens

Environments affected

This shows up on Windows targets where PDQ downloads the installer to its cache and then runs it. It affects domain-joined and non-domain machines alike. It is more common on locked-down endpoints with application whitelisting or restricted profiles.

User account permissions

PDQ usually runs package steps as Local System by default. An install that works when I run it as a logged-on admin, but fails under Local System, points to:

Missing per-user prerequisites
The installer expecting a user profile
Network resources that need user credentials

Check PDQ’s Run As setting for the step. If you changed it to a service account, check that account has rights to the file and any network share in use.

Command line vs. PDQ Connect execution

You reported: “The client is an executable and it installs fine from the command prompt with the –quiet switch. The same command is failing to install as a package.” PDQ can change the current directory and the path to the executable. Test the exact command PDQ will run, including the working directory and full path to the installer.

Find the cause

Diagnostic commands to run

Run these on a target machine and keep the output.

Check the file exists and the hash matches:

PowerShell: Test-Path 'C:\PDQCache\YourInstaller.exe'
PowerShell: Get-FileHash 'C:\PDQCache\YourInstaller.exe' -Algorithm SHA256

Expected: the file exists and the hash matches the expected SHA256. A missing file or hash mismatch means the download is bad.

Run the installer as SYSTEM to match the PDQ context:

psexec -s -i powershell.exe -NoProfile

Inside that session:

Start-Process -FilePath 'C:\PDQCache\YourInstaller.exe' -ArgumentList '--quiet' -Wait -NoNewWindow -PassThru

Expected: exit code 0 and the same logs as the interactive run. Exit code 1 or no logs points to an environment difference.

Run Start-Process with an explicit working directory:

Start-Process -FilePath 'C:\PDQCache\YourInstaller.exe' -ArgumentList '--quiet' -WorkingDirectory 'C:\PDQCache' -Wait

Expected: the same result as the command prompt run. Failure here means the working directory matters.

Capture installer output if the installer supports it:

Start-Process -FilePath 'C:\PDQCache\YourInstaller.exe' -ArgumentList '--quiet --log=C:\temp\sophos-install.log' -Wait

Expected: the log contains successful install lines. If not, the installer log should show the error.

Expected versus actual outcomes

Expected: the manual run at a command prompt returns 0. The PDQ run should return 0 as well. Actual: PDQ returns 1. That difference usually points to the PDQ execution context.

Installer log analysis

Open the installer log and look for:

Missing file errors
Permission denied lines
Network path failures
“Unable to extract” or “failed to write to” errors

Note the last actionable line before the exit code. That line often shows the root cause, for example “Access denied writing to C:\Program Files\Sophos”.

Fix

Steps to correct installation commands

Use the full path to the installer in the PDQ step. Do not rely on relative paths.
Add the working directory explicitly in PDQ or in the Start-Process call. Example:

Start-Process -FilePath 'C:\PDQCache\YourInstaller.exe' -ArgumentList '--quiet' -WorkingDirectory 'C:\PDQCache' -Wait

If the installer supports a log switch, add it so you get output during PDQ runs.
If the installer needs per-user components, change the PDQ step to run as an account with an interactive profile, or run a second post-install step under the user’s context.

Modifying the PDQ package settings

Set the step to use the full installer path. Tick the box to set the working directory to the package location.
Run the step as Local System only if the installer supports it. Otherwise specify a local admin account.
Increase the step timeout. Some Sophos installers extract payloads and can run past the default timeout.
Enable PDQ step output capture and log retention so you can inspect stdout and stderr.

Testing the installation process

Test in this order:

Manual interactive install with --quiet on a test machine.
Run as Local System using PSExec and the same command PDQ will use.
Deploy via PDQ to a single test machine with verbose PDQ logging.

Check the installer logs after each test and compare the output.

Check it’s fixed

Verifying successful installation

Verify via the registry and installed programs:

PowerShell: Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall* | Where-Object { $_.DisplayName -like '*Sophos*' }

Expected: a matching DisplayName and InstallDate.

Also check files on disk:

Test-Path 'C:\Program Files\Sophos\'

And confirm PDQ shows Exit Code: 0 for the deployment.

Monitoring for recurring issues

Keep the PDQ logs for a week after rollout. Set a simple report in PDQ that lists failed installs by exit code. If failures come back with the same code, capture the installer log from one failed machine and compare it to a working one.

Gathering feedback from users

Ask any affected user to report:

Whether they were logged on during the install
If any antivirus or policy blocked the install

Collect the installer log and PDQ step output for each failure. That is what Sophos or PDQ support will ask for.

The usual root cause is an environmental difference between an interactive prompt and PDQ’s execution context: wrong working directory, partial download, or a different account. Fix the command, make paths absolute, test as Local System, then redeploy.