A scheduled browser update finishes overnight, and the console reports the job as complete. In the morning, several laptops haven’t checked in. Other devices ran the installer but still show the old version. Some are waiting for a restart. The job ended while part of the fleet remained unpatched.
Reliable automation needs a complete process: discover the endpoint, define its required state, authorize the change, deploy it in stages, recover exceptions and verify the result on each device.
Patching and software deployment follow this process but need different completion checks. Patching updates an existing operating system component or application. Deployment installs an approved application that wasn’t there before. Both need tested packages, controlled rollout and device-level verification.
Start With an Automation-Ready Endpoint Inventory
A deployment can only target devices the management tool knows about. The Cloud Security Alliance’s guidance on universal endpoint management controls recommends maintaining an inventory of all endpoints used to store and access company data. For automation, that inventory must be current enough to drive targeting and explain why a device did or didn’t receive a change.
Define the Managed Population
This workflow covers company-managed Windows and macOS laptops and workstations in office and remote locations. Servers, mobile devices and unmanaged personal hardware need separate policies and tools. Record that boundary so coverage reports don’t include devices the automation wasn’t designed to reach.
Record Actionable Fields
An inventory template should include the owner, operating system and build, managed application versions, business role, last check-in, connectivity model and pending restart status. Last check-in helps distinguish an offline device from an installation failure. Business role helps assign representative pilot groups. Restart status helps explain why an update hasn’t taken effect.
Separate Connectivity Requirements
Cloud management can reach remote devices when their agents can connect to the service. Segmented or disconnected Windows environments need a separate deployment plan, and often a separate on-premises tool. Check both network access and operating system support before selecting a tool. Also check third-party application deployment and operating system patching separately: support for managing a Mac doesn’t establish support for enforcing macOS operating system updates.
Assign an owner to each deployment group and flag missing inventory fields before using them for automated targeting. A device with an unknown application version or an old check-in needs investigation before it can count as verified coverage.
Turn Risk Into an Explicit Patch Policy
A usable patch policy specifies which changes go first, who approves them and what happens when a device cannot comply. Automation then applies those decisions consistently.
Prioritize Exposure
Consider severity, exploitability, affected devices and business impact together. An exploitable flaw affecting finance workstations may need attention before a higher-severity finding on isolated test devices with an effective mitigation. Severity alone doesn’t describe the organization’s exposure.
Microsoft’s vulnerability management guidance makes a Windows-specific distinction: because Windows security updates are cumulative, prioritization should determine which devices update first, rather than which individual fixes get deployed. For third-party applications, risk ranking also helps determine which packages to prepare and release first.
Separate Routine and Emergency Changes
Routine changes follow the standard deployment rings. Emergency changes need an expedited path with a shorter pilot, an available approver and a required review afterward. Set remediation targets based on your organization’s risk tolerance, business needs and existing mitigations.
Give Exceptions an Expiry
If an application compatibility issue prevents an update, record the affected devices, owner, reason, compensating control, review date and resolution plan. An exception should return to its owner for review rather than remain open indefinitely. The Cloud Security Alliance also recommends reviewing endpoint policies and procedures at least annually; schedule exception reviews according to the exposure involved.
The illustrative layout below separates patching from new application deployment. Replace the deployment windows and exception treatments with approved local requirements.
| Change type | Priority inputs | Owner | Deployment window | Exception treatment |
| Routine Windows cumulative update | Device role, exposure, restart tolerance | Endpoint administrator | Ring sequence within the routine target | Documented exception with review date |
| Routine third-party application update | Exploitability, affected devices, business impact | Package owner | Ring sequence after detection testing | Compensating control and resolution plan |
| Emergency fix for an actively exploited flaw | Exploitability, affected devices, available mitigation | On-call approver | Expedited pilot, then broader rollout | Short-lived exception with frequent review |
| New approved application deployment | Business request, licensing, dependencies | Application owner | Pilot group, then target population | Scope exclusion recorded in inventory |
Build Packages Around a Verifiable Desired State
A package should define both the installation steps and the required result. That result, often called the desired state, might be an approved application installed at a specified version with its required restart complete.
Create a Package Manifest
Before testing, record the approved installer source and checksum, intended version, OS and architecture requirements, installation context, silent-install instructions, dependencies, detection criteria, restart behavior and recovery instructions. Use the software vendor’s documentation for installation parameters.
The detection rule explains how the tool checks that the intended version is present. It may check a file version, registry value or installed-application record. An installer reporting success is insufficient if that check still finds the old version.
Design Packages for Safe Rerunsa
Check what is already present before installing, and test whether a repeated deployment skips completed work. This reduces duplicate installation attempts during retries and offline catch-up.
Test Installation and Detection Together
For an approved browser update, confirm that the package upgrades the existing installation, detects the new version and records any required restart. For a new-device application bundle, test the installation order and dependencies, verify each application, then rerun the bundle to check that it skips completed steps.
Microsoft’s documented Win32 application flow in Intune evaluates the detection rule again after installation. Use that sequence as a testing pattern: detect the current state, install when needed, then detect again.
Match Tooling to the Manifest
Choose a tool that can carry the manifest through to verification. PDQ, for example, manages Windows and macOS devices from anywhere and deploys OS updates, applications and scripts from a single dashboard, using hundreds of prebuilt and verified packages or custom ones you build. It can automate patching when new vulnerabilities are detected and confirm that fixes were successfully installed, while its Deploy & Inventory option covers on-premises and air-gapped environments. Whichever tool you evaluate, test the required operating systems, installation steps and detection behavior against your manifest before relying on it in production.
Protect the Automation Control Plane
A management system that can deploy software across the fleet needs strong administrative protection. CISA’s guidance on hardening endpoint management systems recommends least-privilege administrative roles, phishing-resistant multi-factor authentication and privileged-access hygiene.
Scope Permissions
Create roles around deployment tasks. Package authors need different permissions from administrators who approve production rollout. Help desk staff may only need read access to verify status. Limit both the actions each role can take and the devices it can target.
Protect Administrator Access
Require phishing-resistant MFA for administrator sign-in to the management console and its identity provider. Use dedicated administrator accounts, avoid daily browsing or email from those accounts and review privileged access on a schedule. Review service-account permissions separately and keep them limited to their required tasks.
Require Independent Review for High-Impact Changes
Microsoft describes Multi Admin Approval in Intune as a control requiring a second authorized administrator to approve selected changes before deployment. Feature availability varies by subscription plan, so check the capabilities available in your environment. Where a tool lacks an equivalent approval gate, require a recorded review before fleet-wide assignments or production-ring changes, and keep an emergency approval path with logged actions and a defined deadline for review afterward.
Use this permissions-and-approval checklist when configuring the process:
- Map roles to package authoring, rollout approval and status verification.
- Limit each role to the devices and actions it needs.
- Require phishing-resistant MFA for administrative sign-in.
- Review dedicated administrator accounts and service-account permissions.
- Require independent review for fleet-wide and production-ring changes.
- Record emergency changes and review them afterward.
An account responsible for viewing deployment status should not also be able to change package contents or assign software across the fleet.
Promote Changes Through Tested Deployment Rings
Deployment rings divide the fleet into groups that receive a change in sequence. Microsoft’s Windows servicing guidance recommends this approach and identifies feedback as the purpose of deployment testing. The same staged process can support third-party updates and new application deployments.
Choose Representative Test Devices
A pilot consisting only of IT laptops leaves business workflows untested. Include representative hardware models, business roles, application dependencies and remote connections. Tell participants what will change and which problems they should report.
Define Promotion Gates
Set the evidence required before moving to the next ring. A waiting period alone doesn’t establish that a package works. Check detected versions, restart completion, representative application workflows and classified failures. Decide in advance which findings pause rollout and who can authorize promotion.
A pilot ring, an early-adopter ring and a broad rollout ring provide a practical starting structure. Add separate rings when a population needs distinct testing or timing, such as isolated Windows devices or a site with constrained bandwidth.
Coordinate Installation and Restarts
Windows update-ring controls include deferrals, restart settings, deadlines, active hours and user notifications. Installation schedules, restart policies and active hours are separate settings that need to work together. An overnight installation may miss a sleeping laptop; a restart deadline during a shift may interrupt work. Tell users what is changing, when a restart is expected and how long they may defer it under policy.
Adapt this promotion checklist to the change and its risk:
- Detection confirms the required version on devices that received the package.
- Required restarts are complete, with unresolved devices identified.
- Representative users have checked the affected application workflows.
- Failures are classified and resolved or covered by approved exceptions.
- The recovery option for the next ring has been confirmed and tested.
Record the promotion decision and unresolved issues. That record gives the next administrator enough context to continue the rollout or hold it.
Give Failed and Offline Deployments a Recovery Path
Plan for exceptions before rollout. Each failure type needs a defined next action and an owner, so the administrator on shift doesn’t have to invent a response.
Classify the Outcome
Separate unreachable devices, unmet prerequisites, installer failures, detection failures and pending restarts. Prerequisite problems may include an unsupported OS build, a missing dependency or insufficient disk space. A detection failure means the installer reported success but the expected application state wasn’t found. An offline laptop may need another opportunity to check in, while a package that repeatedly installs without passing detection needs investigation, so keep those cases separate in reports and escalation queues.
Retry With Limits
Microsoft documents a specific behavior for Intune Win32 applications: when an installer returns a code mapped to Retry, the agent attempts installation three times, waiting five minutes between attempts. This behavior applies to that platform and return-code mapping; it isn’t a general retry recommendation. Configure and test bounded retries, escalation after repeated failure and re-evaluation when an offline device reconnects.
Pause Before Extending a Problem
Hold promotion when a package causes unresolved issues. Uninstalling an update or restoring an earlier application version depends on vendor support and the recovery path you tested. Where permitted, retain the previous installer and a tested downgrade package, and record recovery limits in the manifest before deployment.
Plan for Disconnected Endpoints
Disconnected Windows endpoints need a separate recovery and content-delivery plan. Packages that download update content directly from the internet won’t work on isolated devices, even when the deployment tool itself runs on-premises. Plan how operating system update content will reach a local source, then test installation and verification without internet access. Treat content availability and deployment-tool connectivity as separate requirements.
Verify Remediation and Measure Real Coverage
Verification should answer whether each eligible device reached the required state. A completed deployment job cannot answer that question on its own.
Check Device-Level Evidence
Job completion records that the scheduled task ended. An installer exit status records what the installer reported. A device check-in confirms recent contact. Application detection checks the installed state, while a vulnerability scan checks whether the flaw remains detectable. Keep these signals separate. As vendors increasingly focus on patching, vulnerability management and automation, that distinction matters when coordinating detection, remediation and follow-up across repeatable endpoint workflows.
Keep Unverified Devices Visible
A practical reporting model separates the in-scope population into these groups:
- Successful: detection passed and the required restart is complete.
- Failed: a classified failure requires action.
- Pending: installation occurred, but restart or detection is incomplete.
- Offline or unverified: no check-in has occurred since package release.
- Approved exception: a current record identifies the owner and review date.
Use Consistent Denominators
Define verified patch coverage as successful devices divided by the full eligible, in-scope population at a stated snapshot time. Show offline devices and approved exceptions separately while retaining them in the denominator. This keeps improved reporting from being mistaken for improved coverage.
Define the time-to-remediation clock, too. State whether it starts at vulnerability publication or package approval, and stop it at device verification. Label these measures consistently so reports remain comparable.
Build a Compact Dashboard
- Per package: eligible devices, successful, failed by class, pending, offline, exceptions and snapshot time.
- Fleet view: verified coverage by ring, restart backlog and repeated failures.
- Exception view: overdue reviews grouped by owner.
- Package health: pilot failures exceeding the threshold set for rollout.
Review overdue exceptions and unhealthy packages at a cadence that matches release volume. Return each exception to its owner for a decision. For a repeatedly failing package, review its detection rule, installation steps and prerequisites before scheduling another attempt.
