How to deploy Windows patches using Trinetri Autonomous Platform

Overview:

Why the patch gap is the attack surface

Most Windows compromises do not exploit an unknown flaw. They exploit a known one that was fixed months earlier and never installed. The distance between a patch shipping and a patch landing is the entire exposure window, and in a manually managed estate that distance is measured in weeks: long enough for a proof of concept to become a commodity exploit kit.

The operational reason is familiar to anyone who has run a monthly cycle by hand. Someone reviews the release notes, someone else builds a collection, a change ticket goes to a board that meets on Thursdays, a pilot group gets it, and by the time broad deployment is approved the next cumulative update has already shipped. The work is not difficult. It is repetitive, it is unforgiving of small mistakes, and it does not scale past a few thousand endpoints.

Trinetri Autonomous Platform closes the gap by treating patching as a policy problem rather than a monthly task queue. You define the rule once (which products, which severities, which rings, which windows, which reboot behaviour) and EndpointOps executes it every cycle, reports on it continuously, and repairs the devices that fall out of line without anyone opening a ticket.

This guide walks the full production workflow end to end. By the end you will have a repository synchronized against Microsoft Update, a rule-based patch policy bound to deployment rings, a maintenance window and reboot policy that respect your change calendar, a live view of the rollout, exportable compliance evidence, and autonomous remediation watching for drift.

• Reduce vulnerabilities: critical CVEs close in hours rather than change cycles, cutting mean time to remediate and shrinking the window in which a public exploit is useful against you.
• Prove compliance: continuous, per-device evidence for CIS, ISO 27001, HIPAA, PCI DSS and internal audit, captured as a record rather than reconstructed at audit time.
• Increase security posture: ring-based rollout means a defective update reaches a pilot group, not the estate. Rollback is a policy action, not an emergency project.
• Remove manual work: policies inherit last cycle's approval logic, so there is no monthly approval marathon and no spreadsheet reconciling what actually installed.
• Deploy autonomously: the platform detects missing or reverted patches on its own and reinstalls them inside the next approved window, without a ticket or an engineer.

Prerequisites

Confirm all five before beginning. A missing prerequisite usually surfaces at step 7, when patches are already released and the failure is far more disruptive to diagnose.

1. Administrator access: your account holds the Patch Administrator or Tenant Administrator role in the Trinetri console. Read-only operators can view policies but cannot approve or release them.
2. Agent installed: the Trinetri agent is deployed, registered and reporting healthy on every target endpoint. Devices in a Pending registration state are not evaluated by any policy.
3. Internet connectivity: the distribution server can reach Microsoft Update endpoints, and endpoints can reach the distribution server on the configured content port. Proxy exceptions are in place.
4. Repository sync configured: an upstream catalog source is selected with the product scope and classifications you intend to manage. Step 1 covers this if it is not yet done.
5. Device groups defined: endpoints are organised into groups that map to deployment rings, typically pilot, early adopter, broad, and critical infrastructure. Dynamic groups by OS, site or tag are recommended over static membership.

Architecture: how a patch reaches an endpoint

Content and decisions travel separately. Microsoft Update supplies binaries and metadata to your distribution server; Trinetri supplies the policy that decides who receives them and when. Endpoints only ever pull content from the distribution server, so branch bandwidth stays predictable.

Step 1: Synchronize patch repository

Connect EndpointOps to Microsoft Update and pull a complete catalog, so every later decision is made against current metadata rather than a stale snapshot.

Instructions

1. Open the EndpointOps console and go to Patch Management → Repository.
2. Select Configure source and choose Microsoft Update as the upstream catalog.
3. Narrow the product scope to the Windows editions you actually run. A tighter scope syncs faster and keeps every downstream report clean.
4. Set classifications to Security Updates, Critical Updates and Cumulative Updates at minimum. Add Definition Updates only if you are not using a separate antimalware pipeline.
5. Schedule the sync daily, offset one hour after your distribution server's own download window.
6. Select Sync now and wait for the job to report complete.

Path: Console / Patch Management / Repository / Configure source

Verify

# Confirm the agent sees the synchronized catalog
Get-TrinetriPatchCatalog -Source "MicrosoftUpdate" |
    Select-Object LastSyncTime, UpdateCount, Status

Console: repository sources

Result: The repository reports Sync complete with a populated update count and a timestamp inside the last hour. Patches now carry severity, CVE references, supersedence chains and affected device counts.

Step 2: Review available patches

Triage the synchronized catalog by severity, CVE and affected device count so you know what this cycle actually contains before committing anything to a policy.

Instructions

1. Go to Patch Management → Patches.
2. Filter by Severity: Critical, Important and State: Not installed to see only what matters this cycle.
3. Sort by Devices affected to surface the updates with the widest blast radius first.
4. Open any update to read its CVE list, supersedence chain, restart requirement and known issues.
5. Flag anything that touches a business-critical application stack for extended pilot soak time.

Path: Console / Patch Management / Patches / Filter

Console: available patches

Result: You have a short, ranked list of the updates that matter this cycle, each with its CVE references, device count and restart requirement.

Step 3: Create patch policy

Define a reusable rule-based policy so each monthly cycle inherits the same approval logic instead of being rebuilt by hand.

Instructions

1. Go to Patch Management → Policies and select New policy.
2. Name it for what it does, not when it was made: Windows Security Monthly reads better in an audit than July patch v2 final.
3. Choose Rule-based selection rather than picking individual KB articles. Rules survive next month; manual selections do not.
4. Set the criteria: classification Security and Critical, severity Critical and Important, product scope Windows, released more than three days ago.
5. Enable Auto-approve superseded chains so the newest cumulative update replaces older members automatically.
6. Add an exclusion rule for any KB your application owners have flagged, and record the reason in the description field.
7. Save the policy as a draft. It has no targets yet, so nothing deploys.

Path: Console / Patch Management / Policies / New policy

Console: policy definition

Matches 27 updates across 1,412 devices, evaluated live.

Result: A saved draft policy showing a live match count. Next month's updates will fall into the same rule without any rework.

Step 4: Configure deployment

Set the maintenance window, bandwidth limits, download behaviour and installation deadline that govern how and when the policy reaches endpoints.

Instructions

1. Open the draft policy and select the Deployment tab.
2. Define the maintenance window: the only period in which installation may begin. Two to four hours on a fixed weeknight is typical for workstations; servers usually follow the change calendar.
3. Set download behaviour to pre-cache. Content lands on the endpoint ahead of the window so installation starts immediately rather than competing for bandwidth.
4. Apply a bandwidth cap per site. Branch offices on constrained links should throttle to a fixed ceiling rather than a percentage.
5. Set an installation deadline. After it passes, the patch installs at the next opportunity regardless of window: this is what stops a device deferring indefinitely.
6. Enable Wake on LAN if your network supports it, so machines powered off overnight still receive the wave.

Path: Console / Policies / Windows Security Monthly / Deployment

Console: deployment settings

Result: The policy now carries a schedule. Endpoints will pre-cache content ahead of the window and begin installing only inside it, with a hard deadline as backstop.

Step 5: Configure reboot policy

Decide how restarts are handled: forced, deferred, user-prompted, or suppressed for servers under change control. Reboot behaviour causes more user complaints than patching itself.

Instructions

1. On the same policy, open the Restart tab.
2. Choose a mode. Prompt with deferral suits workstations, Suppress suits servers whose restarts are governed by a change ticket, and Force suits kiosks and shared devices with no interactive user.
3. Set the number of permitted deferrals and the interval between prompts. Three deferrals at four-hour intervals is a reasonable default.
4. Set the forced restart deadline: the point at which deferrals stop being offered.
5. Enable active hours protection so a restart never interrupts a working day, and presentation detection so it never interrupts a full-screen session.
6. For server groups, enable restart only with approved change record and bind it to your ITSM integration.

Path: Console / Policies / Windows Security Monthly / Restart

Console: restart behaviour

Result: Restarts follow a defined, predictable rule. Users get warning and a bounded number of deferrals; servers restart only under an approved change record.

Step 6: Assign device groups

Attach the policy to deployment rings so patches move from pilot to broad production in controlled waves with soak time between them.

Instructions

1. Open the Targets tab on the policy.
2. Add your rings in order: Ring 0 (IT pilot), Ring 1 (early adopters), Ring 2 (broad), Ring 3 (critical infrastructure).
3. Set soak time between rings: 24 hours from Ring 0 to Ring 1, 48 hours from Ring 1 to Ring 2, and a change window for Ring 3.
4. Define the promotion gate: a minimum success rate that must be met before the next ring is released. Ninety-five percent is a common threshold.
5. Confirm each ring uses dynamic membership so new devices inherit a ring automatically instead of sitting unmanaged.

Path: Console / Policies / Windows Security Monthly / Targets

Console: deployment rings

Result: The policy targets four sequential rings covering 1,412 devices, with soak time and an automatic promotion gate between each wave.

Step 7: Deploy patches

Release the policy to the first ring and confirm the distribution server is actually serving content to endpoints.

Instructions

1. Review the policy summary one last time: selection rules, window, restart behaviour, rings.
2. Select Release and choose Ring 0 only. Never release all rings simultaneously: that is deployment without staging.
3. Confirm the change record reference if your tenant requires one.
4. Watch the distribution server's content status until the required packages show as cached and available.
5. Confirm the first endpoints move from Scheduled to Downloading within the pre-cache period.

Path: Console / Policies / Windows Security Monthly / Release

Verify

# Check policy state and ring release status
Get-TrinetriPatchPolicy -Name "Windows Security Monthly" |
    Select-Object Name, State, ReleasedRings, NextWindow

Result: The policy state changes to Active: Ring 0. Endpoints in the pilot group begin pre-caching content ahead of the maintenance window.

Step 8: Monitor deployment

Watch live install telemetry, failure codes and pending-reboot counts as the wave progresses, and stop the rollout if the pattern looks wrong.

Instructions

1. Go to Patch Management → Deployments and open the active deployment.
2. Track the four states that matter: Succeeded, Failed, Pending reboot, and Not started.
3. Group failures by result code. A single code repeating across many devices is a systemic problem; scattered one-off codes are usually device-specific.
4. Investigate the common codes: 0x80070643 indicates a failed installer, 0x8024402C a connectivity or proxy problem, 0x80070005 a permissions issue.
5. If the success rate falls below the promotion gate, select Halt deployment before the next ring releases.

Path: Console / Patch Management / Deployments / Live view

Console: live deployment

Succeeded 1,186 · Failed 14 · Pending reboot 78 · Not started 134.

Result: A live, per-ring picture of the rollout with failures grouped by cause, so remediation targets a root cause rather than individual machines.

Step 9: Verify compliance

Confirm patch state against the compliance baseline and export the evidence your auditors will ask for.

Instructions

1. Go to Compliance and select the Windows patch baseline.
2. Read the posture summary: compliant, non-compliant, pending reboot, and unreachable device counts.
3. Open the exception list and classify each entry: genuinely failed, awaiting restart, offline, or excluded by policy.
4. Export the report as PDF or CSV for the audit record. Schedule it monthly so evidence is captured rather than reconstructed.
5. Confirm the compliance percentage meets your internal SLA before declaring the cycle closed.

Path: Console / Compliance / Windows patch baseline / Export

Verify

# Export compliance evidence for the audit record
Get-TrinetriCompliance -Baseline "Windows Patch Baseline" |
    Export-Csv -Path "C:\Audit\patch-compliance-2026-07.csv" -NoTypeInformation

Console: compliance exceptions (98.4% compliant · 1,389 compliant · 9 non-compliant · 11 pending reboot · 3 unreachable)

Result: A compliance figure backed by a per-device evidence trail, and an exception list short enough to work through individually.

Step 10: Enable autonomous remediation

Hand recurring drift to the platform so missing or reverted patches are detected and reinstalled inside the next approved window, without a ticket.

Instructions

1. Go to Policies → Autonomous remediation and create a rule bound to the Windows patch baseline.
2. Set the trigger: a device drifting from compliant to non-compliant, or a patch reverting after a system restore or image refresh.
3. Set the action to reinstall the missing update at the next maintenance window, respecting the same restart policy as the parent deployment.
4. Set a retry ceiling (typically three attempts) after which the device escalates to a ticket rather than looping.
5. Start in recommend mode for one full cycle so you can see what the platform would have done, then switch to autonomous once the actions look right.
6. Route escalations to your ITSM queue so the exceptions that need a human still reach one.

Path: Console / Policies / Autonomous remediation / New rule

Console: remediation activity

Result: Drift is corrected on its own between cycles. Your compliance figure stops sagging in the weeks after each deployment, and only genuine exceptions reach an engineer.

Best practices for Windows patch management

The configuration above works on day one. These practices are what keep it working in month twelve, when the person who built it has moved on and the estate has grown.

Rollback strategy

Decide the rollback path before you need it. In EndpointOps, a rollback is an action on the deployment rather than a new policy: halt the wave, select the affected update, and issue Uninstall scoped to the ring where the problem appeared. The agent removes the update and reports the device as non-compliant by design, which is the correct state: it makes the exception visible instead of hiding it.

Two constraints are worth knowing in advance. Some cumulative updates cannot be uninstalled once a subsequent servicing-stack update has been applied, so rollback windows are narrower than people assume. And an update removed on a device still inside the policy scope will be reinstalled at the next window unless you add it to the exclusion list first. Exclude, then uninstall: in that order.

Troubleshooting: common issues and resolutions

Frequently asked questions