Assess and deploy patches
Review missing updates and risk, configure a staged rollout, inspect gates and device verification, and manage the deployment.
Before you start
- Enrolled devices must have reported patch inventory.
- Create a Patch Policy if the deployment should use a named maintenance window.
Screenshots show the Rapport interface with example data. Use your organization’s devices and values. Select an image to view it at full size.
Start with patch posture and coverage
Open Patch Management → Overview. Review compliance, aging, risk, and the updates prioritized for attention. Read timestamps and source coverage, then choose Review updates to inspect actionable records. The Apps tab compares reported application versions with catalog information; Devices provides device-level patch state.
What you should see: You have selected an update based on its reported risk and affected devices.
Inspect the update and its evidence
In Updates, choose Pending, Failed installs, or Installed, optionally narrow the risk band, and use Refresh updates. Expand the update’s details to inspect the recommendation, stability, vulnerability information, age, and affected records. Treat the analyst’s advice as guidance alongside the source evidence.
Scan or patch one device when that is the intended scope
Open a device’s Patches tab and click Scan for patches to request a fresh scan. Review missing patches and the last scanned time. Select particular missing patches to use Install … selected, or leave the selection empty and review Install all patches. Confirm the requested install. Failed patch rows provide Retry after you inspect the failure.
Create a deliberately scoped deployment
Choose Deploy… for the selected update. Enter a Name, select Platforms, and optionally choose Limit to OUs. No OU selection includes all matching OUs. Review the configured gates and freshness notice before creating the deployment.
| Field or control | What to do |
|---|---|
| Name | Required; at most 200 characters. |
| Platforms | Choose at least one supported platform shown in the form, Windows and/or macOS. |
| Staged rollout (rings) | Plans progressive rings instead of dispatching the full target at once. |
| Canary % | For staged rollout, choose 1–10 percent. |
| Soak hours (canary, pilot) | Use a whole number from 1–168 hours to observe early rings. |
| Auto-promote when gates pass | Allows progression after the configured gates pass; otherwise review promotion manually. |
Set the window and reboot behavior
Choose a Maintenance window or No deployment window, then set Reboot. Endpoint policy and server approval checks still apply even with no deployment window. Click Create deployment only after reviewing the target, rings, and reboot settings.
| Field or control | What to do |
|---|---|
| Never automatically | Does not automatically restart through this deployment reboot setting. |
| Prompt, then deadline / Deferred to a deadline | Set a whole reboot deadline from 1–336 hours. |
| In the window | Uses the deployment’s window-based reboot behavior. |
What you should see: The deployment opens in Deployments, where its actual approval, scheduling, and execution state are visible.
Review the rollout before advancing it
In Deployments, open the rollout and inspect its current ring, recorded outcomes, gate checks, and device verification. A deployment awaiting approval requires an eligible administrator other than its creator. Use Pause when needed. A paused deployment waiting for promotion offers Promote to next ring.
Handle paused, failed, or unwanted work
Use Refresh details before acting on a stale deployment. Resume continues the current paused ring without redispatching already queued devices; its gate is re-evaluated after the soak. Cancel stops the eligible deployment flow. Administrators can choose Roll back in supported deployment states, then inspect the resulting per-device records.
What you should see: You can identify which ring or device needs attention, rather than restarting the entire rollout blindly.
Verify the installed state
Inspect each device’s Status and Verification in the deployment. Open the device Patches tab or use Devices to check the later patch scan and reboot state. Use Apps separately for application-version coverage. A completed dispatcher command and a verified patch inventory are separate pieces of evidence.
What you should see: The rollout can be evaluated using actual device outcomes and subsequent verification.
If something doesn’t work
Deploy is disabled.
Check role, source freshness, and whether updates or deployment options are unavailable. Refresh the source and confirm the form has a valid name, selected platform, canary percentage, soak, and deadline.
A deployment is paused at a gate.
Open its details and read the gate reason and data availability. Resolve the condition, resume for re-evaluation, or make an explicit informed promotion decision.
A patch is installed but a device still needs a reboot.
Inspect the deployment reboot setting, deadline, device policy, and latest scan. Installation and reboot completion are different stages.