Windows fleet deployment

Deploy PMT checks with Group Policy.

Use normal Windows administration to stage visible PMT scripts and scheduled tasks across selected systems.

Group Policy deploys the check. PMT receives the result.

Test one machine first, choose only justified checks, verify the signal path and rollback, then expand.

TEST ONE → VERIFY → ROLL OUT → REMOVE WHEN DONE
Windows remains under your control

Before you deploy

GPO deployment is useful when normal Windows domain tooling is already the right rollout mechanism.

  • clear PMT project boundary;
  • send token for that project;
  • known justified checks;
  • one-machine test available;
  • normal Windows admin rights.

Do not start by pushing every possible check everywhere.

What this does not do

  • discover the estate;
  • install a PMT agent/service;
  • allow PMT remote command execution;
  • patch or remediate systems;
  • diagnose causes;
  • prove whole-machine health;
  • replace endpoint management.

GPO stages/runs the source-side logic. PMT receives the selected result.

Deployment routes

BAT

Run-Setup.bat

PowerShell

.\Deploy-PMT-Simple.ps1

Silent

.\Deploy-PMT-Simple.ps1 -Token "YOUR_SEND_TOKEN" -Silent

Use the simplest route that fits the estate.

Quick GPO shortcut

You do not have to deploy the full starter pack.

For one known check, create a Group Policy scheduled task, use a prepared PMT one-liner or script, set the schedule and use the intended project token.

For repeated/wider rollout, prefer a configuration path that makes credential rotation practical.

Signal Format & Examples →

Packaged GPO rollout pattern

The current helper stages deployment files locally and uses a marker so rollout can be repeatable.

STAGING PATHS

C:\ProgramData\PMT\Deploy\
C:\ProgramData\PMT\Scripts\

Deployment marker:

C:\ProgramData\PMT\Deploy\.pmt_deployed

ROLLOUT

Use Group Policy refresh-triggered tasks where suitable. Startup-script fallback normally waits for reboot.

Before expanding:

  1. confirm expected PMT_* tasks;
  2. check setup logs;
  3. run local verification;
  4. confirm result in intended PMT project;
  5. confirm rollback.

Token handling

The send token determines where results land. Treat it as a credential.

Registry mode can read from:

HKLM:\SOFTWARE\PMT\Token

This can make rotation easier than editing every deployed script/task.

Where a split token/PIN model is used, separate handling may be appropriate. This does not protect against Domain Admins; they already control the endpoint.

If a token is exposed

Rotate or revoke it and redeploy the affected configuration.

Token Storage & Rotation →

Verify, troubleshoot and harden

.\Test-PMTWindowsStarterChecks.ps1
.\Test-PMTWindowsStarterChecks.ps1 -AsJson

Setup logs: %ProgramData%\PMT\SetupLogs\

Per-check logs: %ProgramData%\PMT\PMT_*.log

Optional signature requirement: -RequireSignature

Use controlled paths/shares and limited write access where appropriate.

Rollback and temporary ASK

Delete mode:

.\Deploy-PMT-Simple.ps1 -Delete

Temporary ASK pattern:

define question
→ deploy with GPO
→ collect in PMT
→ filter/export
→ remove when finished

PMT tells you which systems answered. If completeness matters, compare against an authoritative expected source list held elsewhere.

Deploy slowly. Inspect everything.

A good PMT rollout should be explainable in one sitting: where files are staged, which tasks run, what each task sends, which project token is used, and how to remove it.

If the mechanism is hard to explain, simplify it before widening rollout.

Starter Checks ·
API / CLI Access ·
Use Your Own Checks