Why does the PatchReporter installer fail immediately?

The most common reasons are ExecutionPolicy restrictions, running without elevation, or launching the wrong install command for the context.

Why does the install succeed but no data appears?

Usually because the tenant key, base URL, scheduled task, or outbound network path is wrong or incomplete.

What should I check first after installation?

Confirm the scheduled task exists, run the agent manually once, and inspect install.log and agent.log for first check-in events.

Docs

Agent Install Troubleshooting for PatchReporter

Step-by-step troubleshooting for PatchReporter agent installation, including ExecutionPolicy, administrator permissions, scheduled task checks, and first check-in validation.

Category: Troubleshooting | Published 2026-03-05 | Updated 2026-03-21

Troubleshooting for Admins onboarding or repairing PatchReporter agents

Jump To

Use a Known-Good Install Command Fix ExecutionPolicy and Script Launch Issues Fix Admin/UAC and Permission Problems Confirm Task Creation and First Check-In Install Succeeds but No Data Appears Common Mistakes

Free Audit

Run The Free Audit

If you need to separate stale scans, reboot debt, failure signals, and real patch risk across endpoints, run the free RMM Patch Health Audit.

Run the free audit

Use this guide when a PatchReporter endpoint install fails, completes without reporting, or behaves inconsistently after onboarding. The goal is to get from symptom to working agent with the fewest possible checks.

The fastest triage is to prove four things in order: the install command was valid, PowerShell was allowed to run it, the scheduled task was created correctly, and the endpoint can complete first check-in.

Use Microsoft's execution policy reference when install failures are really PowerShell policy or script-launch issues. Microsoft Learn: about_Execution_Policies

What You'll Get

Validate whether the installer, task registration, or network path is failing
Confirm first check-in with actionable commands instead of guesswork
Move from install symptom to remediation steps quickly

Use a Known-Good Install Command

Direct answer: start with a known-good install command, then verify ExecutionPolicy, elevation, scheduled task creation, and first check-in logs in that order.

Most install issues are not subtle. They usually show up immediately as launch restrictions, permission problems, task-registration failures, or missing first-check-in evidence.

Goal: Start from a known-good baseline so you can isolate real failures quickly.

Downloaded installer command (recommended): the downloaded script already includes tenant key and base URL defaults.

PS> powershell -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Downloads\Install-PatchReporter.ps1"

Repo/source script command (explicit values required):

PS> powershell -NoProfile -ExecutionPolicy Bypass `
>>   -File .\agent\Install-PatchReporter.ps1 `
>>   -TenantKey "<tenant-key>" `
>>   -BaseUrl "https://patchreporter.com" `
>>   -IntervalMinutes 5

Run the installed agent immediately (manual test run):

PS> powershell -ExecutionPolicy Bypass -File "C:\ProgramData\PatchReporter\agent.ps1"

Expected: Installer shows numbered progress steps and ends with a summary block.

Caution: do not start changing task definitions or network settings before you know the install command itself is correct for the source you used. A lot of false troubleshooting starts with the wrong launch path.

Fix ExecutionPolicy and Script Launch Issues

Symptom: "Running scripts is disabled" or PowerShell window flashes and closes.

Cause: Current execution policy or browser zone marker blocks script execution.

Fix:

Check all policy scopes.
Set process-scope bypass for this session only.
Rerun installer.

PS> Get-ExecutionPolicy -List
PS> Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
PS> powershell -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\Downloads\Install-PatchReporter.ps1"

Alternative (repo/source installs): Use wrapper if direct .ps1 launch is unreliable.

PS> .\agent\Install-PatchReporter.cmd -TenantKey "<tenant-key>" -BaseUrl "https://patchreporter.com" -IntervalMinutes 5

Fix Admin/UAC and Permission Problems

Symptom: "Installer must be run from an elevated PowerShell session."

Cause: Command is running without admin privileges, so task registration and ACL writes fail.

Verify elevation:

PS> ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
PS> # Expected output: True

Fix: Open PowerShell as Administrator, rerun the installer command, and accept UAC prompt.

Confirm Task Creation and First Check-In

Goal: Confirm install succeeded operationally, not just syntactically.

Run:

PS> Get-ScheduledTask -TaskName "PatchReporter"
PS> Get-ScheduledTaskInfo -TaskName "PatchReporter"
PS> powershell -ExecutionPolicy Bypass -File "C:\ProgramData\PatchReporter\agent.ps1"
PS> Get-Content "C:\ProgramData\PatchReporter\install.log" -Tail 80
PS> Get-Content "C:\ProgramData\PatchReporter\agent.log" -Tail 80

Expected:

Task exists and has valid NextRunTime.
Agent log shows agent.run_started and agent.run_finished.
Ingest events show success or actionable failure metadata.

If first check-in works but reporting later looks inconsistent, use patch dashboard or patch compliance to understand how summary status can drift from endpoint evidence.

Install Succeeds but No Data Appears

Symptom: Installer summary looks successful but dashboard has no device data.

Common causes: Wrong tenant key, wrong base URL, blocked network path, invalid TLS/proxy behavior.

Checks:

PS> Get-Content "C:\ProgramData\PatchReporter\config.json"
PS> Invoke-WebRequest "https://patchreporter.com/agent/agent.ps1" `
>>   -UseBasicParsing
PS> Get-Content "C:\ProgramData\PatchReporter\agent.log" -Tail 120

Interpretation:

ingest.send_success: endpoint can submit data.
ingest.send_failed: network/auth/server issue to remediate.
ingest.skipped_invalid_base_url: config URL is invalid for current policy.

If the agent installs but the endpoint itself is also showing restart debt, Windows Update failures, or inconsistent patch evidence, continue to update requires restart, Windows Update fails to install common fixes, or Windows Update logs before treating the symptom as agent-only.

Common Mistakes

Running the installer without elevation and assuming it completed cleanly.
Mixing the downloaded installer flow with the repo-source flow.
Skipping the manual agent run after install.
Checking the dashboard before checking install.log and agent.log.
Assuming a good install summary proves the first check-in succeeded.