Troubleshooting PDQ Connect Package Installation Errors for Sophos XDR Client: A Detailed Guide

I ran into this exact fault while packaging the Sophos XDR Client for PDQ Connect. The installer works when I run it at the command prompt with the –quiet switch, but the PDQ package fails. The PDQ deployment log shows the step failed and returned code 1. This guide walks through what you will see, where it happens, how to find the cause, how to fix it and how to verify the result.

What you see

Error codes from PDQ Connect

Typical PDQ output looks like:

• 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 executed it. Do not assume it is the installer binary itself. 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 installer’s console output when run 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 is a clue PDQ changed the working directory or the downloaded file was incomplete.

Common package installation errors

Common causes I see:

• 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.
• Installer requires interactive desktop for a step and fails silently under system context.

Where it happens

Environments affected

This happens on Windows targets where PDQ downloads the installer to its cache and then executes it. It affects domain-joined and non-domain machines alike. It is more likely 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 succeeds when run as a logged-on admin but fails under Local System hints at:

• Missing per-user prerequisites
• Installer expecting a user profile
• Network resources that require user credentials

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

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. Always test the exact command PDQ will run, including working directory and full path to the installer.

Find the cause

Diagnostic commands to run

Run these on a target machine and capture output:

• Check file exists and hash:
  • PowerShell: Test-Path ‘C:\PDQCache\YourInstaller.exe’
  • PowerShell: Get-FileHash ‘C:\PDQCache\YourInstaller.exe’ -Algorithm SHA256

Expected: file exists; hash matches expected SHA256. Actual: file missing or hash mismatch indicates download corruption.

• Run installer as SYSTEM to reproduce PDQ context (PSExec required):
  • psexec -s -i powershell.exe -NoProfile
  • Then inside that session:
    Start-Process -FilePath ‘C:\PDQCache\YourInstaller.exe’ -ArgumentList ‘–quiet’ -Wait -NoNewWindow -PassThru

Expected: exit code 0 and same logs as interactive run. Actual: exit code 1 or no logs means an environment difference.

• Run PowerShell Start-Process with explicit working directory:
  • Start-Process -FilePath ‘C:\PDQCache\YourInstaller.exe’ -ArgumentList ‘–quiet’ -WorkingDirectory ‘C:\PDQCache’ -Wait

Expected: same result as command prompt. Actual: failure implies working directory matters.

• Capture installer output (if supported):
  • Start-Process -FilePath ‘C:\PDQCache\YourInstaller.exe’ -ArgumentList ‘–quiet –log=C:\ emp\sophos-install.log’ -Wait

Expected: log contains successful install lines. Actual: installer error lines to inspect.

Expected versus actual outcomes

Expected: manual run at command prompt returns 0. PDQ run should return 0. Actual: PDQ returns 1. That difference isolates PDQ execution context as the cause.

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 states the root cause, for example “Access denied writing to C:\Program Files\Sophos”.

Fix

Steps to correct installation commands

1. Use the full path to the installer in the PDQ step. Do not rely on relative paths.
2. Add the working directory explicitly in PDQ or in the Start-Process call. Example argument for PowerShell steps:
   • Start-Process -FilePath ‘C:\PDQCache\YourInstaller.exe’ -ArgumentList ‘–quiet’ -WorkingDirectory ‘C:\PDQCache’ -Wait
3. If the installer supports a log switch, add it to capture output during PDQ runs.
4. 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 working directory to 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 exceed default timeouts.
• Enable the PDQ step output capture and log retention so you can inspect stdout/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 identical command PDQ will use.
• Deploy via PDQ to a single test machine with verbose PDQ logging.
  Check installer logs after each test to confirm the same output.

Check it’s fixed

Verifying successful installation

Verify via 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 recur with the same code, capture the installer log for one failed machine and compare to a successful machine.

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.

Root cause in most cases is an environmental difference between an interactive prompt and PDQ’s execution context: wrong working directory, partial download, or running under a different account. Fix the command, make paths absolute, capture logs while testing as Local System, then redeploy. That delivers a repeatable, verifiable PDQ Connect installation for the Sophos XDR Client.