Group Policy deployment
Deploy PMT Windows checks with Group Policy
Use normal Windows admin tooling to deploy visible PMT scheduled tasks across selected systems. Test one machine first, choose only justified checks, then roll out with Group Policy where that is already the right operational route.
Rollout model
- Choose the project and token
- Test the starter pack on one machine
- Choose simple, silent, registry, or GPO deployment
- Inspect the scheduled tasks and logs
- Roll back by delete mode or removing
PMT_*tasks
PMT receives selected results. Windows remains under your control.
Before you deploy
Group Policy deployment is useful when you want the same transparent PMT checks on multiple Windows systems.
- you have a clear project boundary
- you have a send token for that project
- you know which checks are justified
- you can test on one machine first
- you have normal Windows admin rights for rollout
Do not start by pushing every possible check everywhere.
What this does not do
- discover customer estates
- install a PMT agent or service
- run remote commands from PMT
- patch or remediate systems
- diagnose causes
- prove whole-machine health
- replace endpoint management tooling
It creates Windows scheduled tasks that send selected signal results.
Deployment routes
Use the simplest route that fits the estate. The same signal model applies whichever route you use.
BAT setup
Fastest manual path for one machine.
Run-Setup.batRun as Administrator. The BAT launcher starts the PowerShell deployer.
PowerShell setup
Direct deployment for local or scripted use.
.\Deploy-PMT-Simple.ps1Use this when you want to inspect or call the deployer directly.
Silent deployment
Non-interactive path for automation.
.\Deploy-PMT-Simple.ps1 -Token "YOUR_SEND_TOKEN" -SilentTreat the token as a credential.
Quick GPO shortcut
If you already know the check you want, you do not have to start with the full starter-pack deployment.
Create a Group Policy scheduled task, paste in a prepared one-line PMT check, set the schedule, and point it at the right project token.
Where practical, put the send token in a registry value so it can be rotated without editing the task body. For a temporary or quick-and-dirty check, embedding the token in the task or script may be acceptable if you understand the exposure.
Group Policy rollout pattern
The GPO helper is for Windows estates where normal domain tooling is the right way to stage and run scripts.
The helper can copy deployment files locally and use a marker so rollout can be made repeatable.
- local staging:
C:\ProgramData\PMT\Deploy\ - script staging:
C:\ProgramData\PMT\Scripts\ - deployment marker:
C:\ProgramData\PMT\Deploy\.pmt_deployed
Use Group Policy refresh triggered tasks where suitable. Startup-script fallback normally waits for reboot.
What to test before rollout
- Run on one test machine
- Confirm the expected
PMT_*scheduled tasks exist - Check setup logs
- Run local verification
- Confirm the signal appears in the intended project view
- Confirm rollback works
Only then move to a wider OU, customer, branch, or site.
Token handling
A send token identifies where the signal belongs. Treat it like a credential.
For small manual deployments, inline token mode may be acceptable if the operational risk is understood.
For repeated or wider deployment, prefer a configuration path that keeps tokens out of editable script bodies where practical.
Registry mode can read from:
HKLM:\SOFTWARE\PMT\TokenRotation and larger estates
Registry or protected configuration makes token rotation easier than editing every deployed script.
Where a split token/PIN model is used, the broad token can be deployed separately from a protected machine-specific PIN.
This does not protect against Domain Admins. They already control the endpoints.
If a token is exposed, rotate or revoke it and redeploy the affected configuration.
Inspect what was installed
The starter pack creates visible scheduled tasks. It does not install a hidden service.
Tasks use the PMT_ prefix, for example:
PMT_heartbeatPMT_system_free_gbPMT_sys_vol_spacePMT_reboot_pendingPMT_winupd_fail_24h
Tasks run as SYSTEM and are visible in Task Scheduler.
Verify and troubleshoot
Use local verification before assuming the deployment is correct.
.\Test-PMTWindowsStarterChecks.ps1
.\Test-PMTWindowsStarterChecks.ps1 -AsJsonSetup logs are under:
%ProgramData%\PMT\SetupLogs\Per-check logs are under:
%ProgramData%\PMT\PMT_*.logCompatibility assumptions
The packaged Windows deployer requires Administrator rights and the Windows ScheduledTasks module.
That generally means Windows 8 / Server 2012 or newer for the packaged script.
For older or unusual systems, use custom checks or simpler one-line sends rather than forcing the starter pack to fit.
Optional hardening
Where appropriate, require signed scripts before rollout.
-RequireSignatureUse a controlled file share, known script path, predictable staging location, and limited write access.
Hardening should not make the deployment mysterious. Operators should still be able to inspect what runs and remove it cleanly.
Rollback and removal
PMT should be removable without collateral damage.
Delete mode removes the deployed starter checks:
.\Deploy-PMT-Simple.ps1 -DeleteYou can also remove PMT_* scheduled tasks through normal Windows administration where appropriate.
After rollback, check Task Scheduler and the PMT logs to confirm the expected state.
Do not hide the mechanism
A good PMT deployment should be understandable in one sitting.
- where the files are staged
- which tasks run
- what each task sends
- which project token is used
- how to stop it
- how to remove it
If the deployment cannot be explained simply, simplify it before expanding rollout.
Group Policy deployment questions
These answers are intentionally narrow.
Is this an agent?
No. The starter path creates visible scheduled tasks that run scripts and send small PMT signals.
Can PMT run commands on the endpoints?
No. PMT receives signals sent by the endpoint-side task or script. It does not provide remote command execution.
Should tokens be embedded in scripts?
For small tests it may be acceptable. For repeated or wider deployment, prefer registry or protected configuration so token rotation is easier.
What if a task stops running?
If a signal was expected and stops arriving, the webapp or operator view can make that absence visible. PMT does not diagnose the cause.
Can I deploy only some starter checks?
Yes. Use only checks that answer useful operational questions. Do not deploy checks just because they are available.
How do I remove it?
Use delete mode or remove the PMT_* scheduled tasks through normal Windows administration.
Starter checks
See what the Windows starter pack includes and what each check does not prove.
Use your own checks
Where starter checks do not fit, send custom results from your own scripts or jobs.
Trust & security
Review token handling, project separation, and what not to send.
Deploy slowly, inspect everything
Start with one machine, one project token, and one useful starter check. Expand only after the signal path, scheduled task, logs, and rollback are understood.
Get your signal
Create a project.
Test one signal.
Deploy only where justified.