System Updates
System update policies control how Windows and Linux patches are deployed to your endpoints. Each policy defines which updates to install, which agents to target, and when installations should occur. You can run multiple policies in parallel to handle different groups of endpoints with different patching strategies.
How TridentStack Control manages Windows Update
When the TridentStack Control agent is installed on an endpoint, it automatically suppresses native Windows Update. This ensures that the platform is the sole provider for system updates, preventing conflicts between Windows Update and your managed patching policies.
- On modern systems (Windows 10 2004+, Windows 11, Server 2022+), the agent blocks quality, feature, and other updates while allowing driver updates through Windows Update.
- On older systems (Server 2019, Server 2016), all update categories are blocked and managed exclusively through TridentStack Control.
The agent verifies this configuration on every startup and reapplies it if it has been changed. No manual configuration is required. For full technical details, see the Agent Reference.
Creating a policy
Navigate to Update Management > System Updates in the left sidebar and click Create Policy. The policy creation form walks you through these sections:
Name and description
Give the policy a descriptive name that reflects its purpose and audience. For example, "Production Servers - Monthly Security Patches" or "Dev Workstations - Weekly All Updates". The description field is optional but recommended for documentation.
Target agents
Choose which endpoints receive this policy. You can target agents in two ways:
- By tag - Select one or more tags. Any agent with a matching tag receives the policy. This is the recommended approach because new agents automatically pick up the policy when tagged.
- By individual assignment - Select specific agents from the list. Useful for one-off policies or testing on a specific machine.
Schedule
Define a maintenance window that controls when updates are installed:
- Day of week - Select one or more days (e.g., Tuesday and Thursday)
- Time window - Set a start time and duration (e.g., 2:00 AM for 4 hours)
- Recurrence - Weekly, biweekly, or monthly
Agents only install updates during their assigned maintenance window. Outside the window, agents download and stage updates but do not install them.
Pre-staging
When enabled, agents download approved updates ahead of the maintenance window. This means the actual installation phase is shorter because the files are already on disk. Pre-staging is especially useful for large cumulative updates that take significant time to download.
Restart behavior
After updates are installed, some patches require a restart to complete. Configure how restarts are handled:
| Option | Behavior |
|---|---|
| Restart immediately | Agent restarts as soon as installation completes, within the maintenance window |
| Schedule restart | Agent waits until a configured time to restart (e.g., next morning at 6:00 AM) |
| User decides | A notification is shown to the logged-in user, who can restart now or defer |
| No restart | No automatic restart. The update remains in a pending-restart state until the machine is manually restarted |
Use pre-staging to download updates ahead of the maintenance window. This reduces the time agents spend in the installation phase and keeps maintenance windows short.
Update approval workflow
By default, updates are not approved for installation. You control exactly which patches reach your endpoints through the approval workflow.
Browse available updates
Open the policy detail page and use the update browser to see all patches that are available for the targeted endpoints. The browser shows update title, KB number, classification, severity, release date, and whether the update supersedes older patches.
Approve updates
Select individual KBs or approve in bulk by classification. Approved updates are eligible for installation during the next maintenance window. You can approve updates at any time, and they will be picked up by agents on their next check-in.
Deny updates
Explicitly deny updates you do not want installed. Denied updates are hidden from the available list and are never offered to agents. This is useful for known-problematic patches or updates that conflict with specific software in your environment.
Auto-approve rules
Set rules to automatically approve updates by classification after a configurable delay. For example:
| Rule | Effect |
|---|---|
| Auto-approve Critical Updates after 3 days | Critical patches are approved 3 days after release |
| Auto-approve Security Updates after 7 days | Security patches are approved after a 1-week observation period |
| Auto-approve Definition Updates immediately | Antivirus definitions are approved with no delay |
Auto-approve rules are evaluated when an update policy is modified and when new updates are synced into the catalog. When an update matches a rule and the delay period has elapsed, it is approved automatically. You can combine auto-approve rules with manual review: auto-approve routine classifications and manually review higher-risk categories like Feature Packs or Service Packs.
Update classifications
Updates are organized by classification. Each classification represents a different type of patch:
| Classification | Description |
|---|---|
| Critical Updates | Non-security fixes for critical bugs |
| Security Updates | Patches that address security vulnerabilities |
| Definition Updates | Antivirus and anti-malware signature updates |
| Feature Packs | New product functionality distributed outside a full release |
| Service Packs | Cumulative collections of hotfixes, security updates, and critical updates |
| Update Rollups | Cumulative sets of hotfixes packaged together for easier deployment |
| Driver Updates | Updated device drivers published through the update catalog |
Microsoft Office updates
System update policies can manage Microsoft Office versions on both Windows and macOS endpoints. Office is managed alongside system updates because the update channel is a policy decision, not a per-app one.
On Windows, Office is delivered through the Click-to-Run service (OfficeC2RClient.exe) and channels follow Microsoft 365's standard channel names: Current, Monthly Enterprise, Semi-Annual Enterprise, Beta, and the long-term-servicing channels (LTSC 2021, LTSC 2024).
On macOS, Office updates are delivered through Microsoft AutoUpdate (MAU) via the msupdate CLI. MAU has three channels: Production (the default for most users), Beta (the InsiderSlow ring), and Current Channel (Preview) (the InsiderFast ring). Channel names match exactly what defaults read /Library/Preferences/com.microsoft.autoupdate2.plist ChannelName returns on the endpoint.
Enabling Office management on a policy
In the policy edit screen, open the Office Update Management section and toggle Enable Office Updates on. With management enabled you can configure:
- Target Update Channel (Windows) - which Microsoft 365 Click-to-Run channel Windows agents should track. Leave unset to keep each Windows agent on its existing channel.
- Target Update Channel (macOS) - which MAU channel macOS agents should track. Leave unset to keep each macOS agent on its existing channel.
- Defer Updates (Days) - delay between a channel release and when this policy considers it deployable, 0 to 365 days. Applies to both platforms.
- Auto-update Office when non-compliant - whether the agent should self-trigger an Office update when it observes itself below the target version.
- Enable ring deployment for Office updates - whether deployment rings dispatch Office as a stage in the ring's update chain (see below).
A policy can apply to a mixed fleet. Each agent is evaluated against the channel selection for its own platform; an unset selection for one platform does not disable Office for the other.
How Office updates are dispatched
Office updates reach an endpoint in two ways:
- Through a deployment ring - When the policy has both Enable Office Updates and Enable ring deployment for Office updates enabled, deployment rings dispatch Office as the stage between application updates and system updates. The ring evaluates each agent's Office version against the policy's target for that agent's platform and skips agents that are already compliant. See the deployment ring dispatch order for where Office sits in the chain.
- Manual trigger from the agent detail page - On a Windows or macOS agent's detail page, administrators can trigger an Office update directly. The manual trigger is gated on the same compliance check: if the agent is already at the policy's target version, or the policy has Office updates disabled, the manual trigger is refused with an explanation. There is no override for the manual path. To force a re-install, use a one-shot tag-based policy assignment with a different target instead.
macOS-specific behavior
- Five apps are managed: Word, Excel, PowerPoint, Outlook, and OneNote. Teams and OneDrive ship their own auto-updaters and are not part of the Office bundle for compliance purposes.
- Compliance uses the lowest installed version: an agent is compliant only when every detected Office app is at or above the policy's target version. A single out-of-date app reports the agent as non-compliant.
- Cross-channel changes are best-effort: MAU honours channel changes only when it next launches. A policy that switches a macOS agent's channel may not take effect until the user re-opens an Office app or MAU itself.
- MAU CLI prerequisite: the agent invokes
msupdateat/Library/Application Support/Microsoft/MAU2.0/Microsoft AutoUpdate.app/Contents/MacOS/msupdate. Microsoft has shipped this path since MAU 4.0 (2019); endpoints predating that will not have current Office at all.
Why Office runs before system patches in the ring
System patches often require a reboot. Running Office ahead of system patches in the ring chain means the Office update completes against the still-current OS state and does not have to wait for a reboot cycle. Both Click-to-Run on Windows and MAU on macOS handle their own in-place updates without rebooting the endpoint, so the chain can advance into system updates immediately after the Office stage's settle window expires.
What Office updates look like in the history
A ring-driven Office update appears in the agent's Activity History tab as Office Update Install with the trigger source Deployment Ring. A manual trigger uses the same task title with trigger source Web Portal or API depending on how it was launched. In both cases the expanded view shows the task's phases (Preflight, Check, Install, Verify on macOS; Preflight and Install on Windows) with their durations and outcome details, plus the Office version Before/After and the channel.
Feature upgrades
Feature upgrades move a Windows endpoint from one feature version to another (for example, Windows 11 23H2 to 24H2, or 24H2 to 25H2). TridentStack Control handles them as a distinct flow from monthly cumulative updates because they change the underlying build number and require a restart to complete.
How feature upgrades are dispatched
Feature upgrades can reach an endpoint in two ways:
- Through a deployment ring - When the update policy's feature upgrade settings have ring deployment enabled and a target version configured, the upgrade flows through the same phased rollout as other updates. The ring picks up eligible endpoints automatically as it reaches each phase.
- Manual trigger from the agent detail page - On the agent's System State tab, administrators can open the pending feature upgrade and trigger it immediately. This path bypasses the ring.
Install method
Depending on the source and target version, TridentStack Control picks one of two install methods automatically:
| Method | When it is used |
|---|---|
| Enablement package | Used for in-family upgrades where the target version is delivered by a small enablement package (~1 MB) that toggles features already staged by cumulative updates. Typical for upgrades like 24H2 to 25H2. Install takes under a minute. |
| Full upgrade | Used for cross-generation upgrades (for example, Windows 10 to Windows 11), or when the endpoint's current build revision is below the minimum required for the enablement package. Downloads the full Windows installation media (~4 GB) and runs setup.exe. Takes approximately 15 to 20 minutes plus a restart. |
If a manual enablement-package upgrade is attempted but the endpoint's build revision is below the prerequisite level, TridentStack Control automatically falls back to the full upgrade method rather than allowing a silent failure.
Prerequisite updates
Some feature upgrades require a specific cumulative update to be installed first (for example, the enablement package for 25H2 requires a recent revision of 24H2). If the prerequisite is not already installed, TridentStack Control automatically queues it ahead of the upgrade. The prerequisite installs during the next maintenance window, and the feature upgrade becomes eligible on a subsequent evaluation.
Restart choice (enablement package)
When triggering an enablement-package upgrade from the agent detail page, you choose one of two restart modes:
| Mode | Behavior |
|---|---|
| Install Only | Installs the enablement package but does not restart. The endpoint remains on the current build until you trigger the restart later from the pending upgrade banner. Best for production systems where restart timing is sensitive. |
| Install and Restart | Installs the enablement package and restarts the endpoint automatically about 30 seconds after install completes. The full sequence (install, restart, post-restart verification) takes 2 to 3 minutes. |
Full upgrades do not offer this choice because setup.exe manages the restart itself.
Upgrade banners on the agent detail page
While a feature upgrade is in progress, the System State tab displays a banner reflecting the current phase:
| Banner | Meaning | Action available |
|---|---|---|
| Upgrade Pre-Staged, Awaiting Maintenance Window | The upgrade media has been downloaded and prepared. Finalization will run during the next maintenance window. | Finalize Upgrade to trigger immediately |
| Enablement Package Installed, Restart Required | The enablement package installed successfully. A restart is required to activate the new version. | Restart Now to restart the endpoint |
| Upgrade Finalizing | Setup.exe or the enablement finalization is running on the endpoint. | None (waiting for completion) |
| Upgrade Rebooting | The endpoint is restarting to apply the upgrade. The agent will reconnect and validate the new build. | None (waiting for agent to reconnect) |
Once the upgrade completes and the agent reports a new build, the banner clears and the new feature version appears in the Operating System section of the System State tab.
Install time estimates
TridentStack Control displays estimated installation times next to each update in the catalog browser and on each agent's pending updates list. Estimates appear as approximate durations (for example, "~15 min" or "~1h 30m").
Estimates are calculated from historical installation durations recorded across your fleet. New tenants see catalog-based estimates initially. As more updates are installed in your environment, the estimates become more accurate and are tailored to endpoints with similar hardware profiles when enough data is available.
Click the info icon next to any estimate to see the confidence level (High, Moderate, or Low), the number of recorded installs, and a statistical breakdown including median, average, and 95th percentile durations. High confidence means the estimate comes from 5 or more installs on similar hardware. Moderate means 3 or more installs are recorded. Low means fewer than 3 data points are available.
When selecting multiple updates to install, the confirmation dialog shows an aggregated estimated total install time.
Estimates use the median duration to avoid skew from occasional slow installs. For conservative maintenance window planning, check the 95th percentile in the estimate detail popover.
Install Stats
The Install Stats column appears in the update catalog browser and on each agent's pending system updates list. It shows fleet-wide installation success metrics for each update, helping you identify problematic patches before approving them.
What Install Stats show
Hover over or click the Install Stats badge on any update to see:
| Field | Description |
|---|---|
| Total deployments | Number of times this update has been installed across all endpoints in your fleet |
| Success rate | Percentage of installations that completed successfully, color-coded: green (95%+), amber (80-94%), red (below 80%) |
| Confidence | Data quality indicator based on deployment count: High (50+), Moderate (10-49), or Limited (fewer than 10) |
| Common errors | Top 3 most frequent error codes from failed installations, with occurrence counts |
How Install Stats are populated
Install Stats are computed from actual installation outcomes recorded by the TridentStack Control agent on your endpoints. Every time an update is installed (whether it succeeds or fails), the agent reports the result back to the platform. These results are aggregated periodically (approximately every 15 minutes) into the stats you see in the UI.
New tenants and newly synced updates will show empty Install Stats ("--") initially. Stats appear only after updates have been installed on at least one endpoint in your environment. The more updates your fleet installs, the more data points are available, and the more useful the stats become.
Install Stats in the catalog expanded row
When you click on a system update in the catalog browser to expand its detail row, an Install Intelligence section appears showing the same deployment count, success rate, and common errors in a larger format. This complements the existing install time estimates and known issues sections to give you a complete picture of each update's installation track record.
Policy lifecycle
A typical policy follows this progression from creation to reporting:
Each stage builds on the previous one. You can return to any stage at any time to adjust the policy. Changes take effect on the next agent check-in.
Monitoring deployment
After a maintenance window runs, check the policy detail page for deployment results. The results view shows each targeted agent with the following information:
| Column | Description |
|---|---|
| Agent | Endpoint hostname |
| Updates installed | Count of successfully installed patches |
| Updates failed | Count of patches that failed to install, with error details |
| Restart status | Whether a restart was performed, is pending, or was not required |
| Duration | Total time the agent spent in the installation phase |
Click any agent row to expand it and see per-update details, including individual KB results, error codes, and timing.
Always test update policies on a small group of endpoints before deploying fleet-wide. Use deployment rings to implement phased rollouts and catch issues before they affect production systems.