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 new updates become visible

TridentStack Control checks for new updates automatically in the background. You do not need to trigger a refresh, or take any action on an endpoint, for a newly published update to show up as pending.

• Windows - when a new update is published, for example on Patch Tuesday, it typically appears as a pending update on affected endpoints within 15 to 30 minutes of entering the TridentStack Control catalog. Endpoints are also re-checked against the catalog on a regular schedule throughout the day, so pending updates stay current between releases.
• macOS - macOS updates are detected from each endpoint's built-in software update check and refreshed automatically on a periodic basis.
• Linux - pending updates come from each endpoint's own package manager. See How Linux updates are detected below.

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.

Free disk space

The free space setting is the amount of space that must remain on the system drive after update downloads finish. TridentStack Control installs the updates that fit and holds the rest for a later maintenance window. If no updates fit, the endpoint reports "Not enough free space on C: ..." and the deployment ring retries during its next window. Set the threshold to 0 to turn this check off.

Reboot behavior

After updates are installed, some patches require a reboot to complete. Configure how reboots are handled:

Option	Behavior
Reboot immediately	Agent reboots as soon as installation completes, within the maintenance window
Schedule reboot	Agent waits until a configured time to reboot (e.g., next morning at 6:00 AM)
User decides	A notification is shown to the logged-in user, who can reboot now or defer
No reboot	No automatic reboot. The update remains in a pending-reboot state until the machine is manually rebooted

tip

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.

You can also filter by update name. Add an "Update Name / Title" condition and use * (any text) and ? (single character) wildcards, for example *Preview* or KB5034*. Choose matches to include updates whose title fits the pattern, or does not match to exclude them (for example, approve all security updates except previews). Matching is case-insensitive.

Install validation

When a Windows endpoint finishes installing a system update, TridentStack Control does not report the install as successful straight away. It first confirms that the update actually took effect, then reports the result.

While that confirmation is in progress, the install shows a Validating stage in the endpoint's Activity History tab. Expanding it shows what is being checked and how long each check took.

What the result means

Result	Meaning
Success	Every update in the install is no longer applicable to the endpoint. The patch is on the machine.
Partial	Some updates cleared and at least one is still applicable. The ones still listed did not take.
Failed	Nothing cleared, the endpoint did not come back from its reboot in time, or the endpoint never reported back so the result could not be confirmed. The expanded view names the reason.
Pending Reboot	The install needs a reboot before it can be confirmed. Nothing has failed.
Not applicable to this system	Windows itself reported that every update in the install does not apply to this endpoint in its current state. Nothing was installed and nothing failed.

Expanding the Validating stage lists each update individually, marked either as cleared or as still present. An update that was already waiting on a reboot from an earlier install, or that has been replaced by a newer update, is listed as excluded and is not counted either way.

Updates Windows reports as not applicable

Sometimes Windows refuses an update outright because it does not apply to the endpoint in its current state. The most common case is a .NET Framework update built for a different .NET Framework version than the one the endpoint runs, or one the endpoint already has under a different update number. TridentStack Control treats that answer as its own outcome rather than a failed install:

• In the endpoint's Activity History the install shows Not applicable to this system, with the refused updates listed individually. If other updates in the same install succeeded, the install is still reported as successful and the refused ones are shown separately.
• On the Rollout Status page the endpoint completes normally and the refusal does not count toward the ring's safety halt.
• In the endpoint's Pending System Updates panel the update is set aside with a grey Not applicable label and is not sent again until the endpoint's Windows build, installed updates, or .NET inventory changes. See Endpoints for the label and the Retry option.
• The Not taking effect list on the Update Problems tab lists these under their own Not applicable reason so they are easy to tell apart from updates that are looping.

Installs recorded before this behavior was introduced keep the status they were given at the time.

.NET updates

TridentStack Control is rebuilding how .NET updates are matched to each endpoint. This covers .NET Framework cumulative updates and the monthly updates for the .NET runtime, ASP.NET Core and the ASP.NET Core Hosting Bundle. Until a .NET version is verified end to end, its updates are not listed as pending, are not pre-staged and are not installed through TridentStack Control, whether by a deployment ring or by the Install button. Nothing on the endpoint is changed by this: Windows Update, WSUS, Intune and updates you install by hand continue to work, and an update installed that way is reflected in the endpoint's inventory as usual. A .NET installer you upload yourself as a custom package is deployed exactly as you configured it: custom packages are not affected. If a .NET update file was already downloaded to an endpoint for pre-staging, it stays on the endpoint and is not used or removed by TridentStack Control until that .NET version is verified. Ordinary Windows cumulative updates, including the ones that carry .NET Framework fixes for Windows Server 2016, are not affected.

Updates the endpoint never reported back on

An install sends a set of updates to an endpoint and the endpoint reports a result for each one. Occasionally an endpoint stops reporting partway through: it reboots at the wrong moment, loses its connection, or the install process is interrupted. TridentStack Control reports each of those updates from the install progress the endpoint sent before it went quiet, rather than assuming the install as a whole tells you what happened to every update in it:

• Installed, not verified if the endpoint reported the install finishing but never sent the final result. The update very likely installed; it just was not confirmed.
• Failed if the endpoint reported the install failing, or reported it starting and never getting past that.
• Not installed if the endpoint reported nothing at all about the update, so there is no evidence it was ever attempted.

Every one of these rows names the reason in the endpoint's Activity History. An update in this state does not count toward the install's success, and a rollout does not record it as deployed to that endpoint unless the endpoint confirmed it. An update that keeps being sent to the same endpoint without any result coming back is listed in the Not taking effect list on the Update Problems tab under its own Sent repeatedly with no result reported reason.

Before this behavior was introduced, an update in this state could be listed as installed successfully on an otherwise successful install, or shown as a blank row. Installs recorded then keep the status they were given at the time.

Updates that need a reboot

If an update requires a reboot, the install waits rather than being marked failed. It shows Pending Reboot until the endpoint reboots, whether that reboot comes from your reboot policy, from a maintenance window, or from someone rebooting the machine by hand. When the endpoint comes back, TridentStack Control picks the validation up where it left off and reports the result. This works no matter how long the wait is, including several days.

While the endpoint waits for that reboot, the install's vulnerability scan shows Waiting for reboot to validate successful update installation. TridentStack Control waits for the reboot before it judges the update for two reasons:

• Some of what an update changes cannot be detected until the endpoint has rebooted and the update has finished installing. Until then the endpoint still runs its previous build, so checking it early would report vulnerabilities the update has already fixed.
• Windows sometimes rolls an update back during the next boot. Checking the build the endpoint runs after the reboot confirms the update stayed installed.

If the first check after the reboot finds the update still finishing, the scan shows Validating successful update installation after the reboot and checks again a few minutes later before it records the result.

The vulnerability scan waits up to about three hours for the reboot. If the endpoint has not rebooted by then, that scan is skipped rather than failed, and the endpoint's Windows vulnerabilities are checked again within a few minutes of it coming back on the updated build. Install validation itself keeps waiting for the reboot, however long it takes.

The same check runs whenever a reboot moves a Windows endpoint to a newer build, including updates installed outside TridentStack Control. It appears in the endpoint's Activity History as a Vulnerability Scan, and vulnerabilities the new build fixes are marked resolved.

If your deployment ring is set to force a reboot at the end of its window, that reboot is treated as the reboot the install was waiting for. It never counts as a failure.

.NET runtime updates with several components

While .NET updates are paused (see .NET updates above), this section describes how they are installed once they resume.

A monthly .NET runtime update (for .NET 6 and later) is one entry in the catalog, but an endpoint can carry several separately installed components it applies to: the 64-bit and 32-bit runtimes, the desktop and ASP.NET Core runtimes, and on IIS servers the Hosting Bundle. TridentStack Control installs one component per maintenance window, choosing the installer built for exactly that component and, on servers with both architectures, starting with the one furthest behind. Until the last component is installed the update stays listed as pending and the endpoint's Activity History shows one successful install per window. That is expected progress, not a stuck update, and it does not count toward the ring's safety halt. An endpoint is not sent the next component until it has reported its updated .NET inventory after the previous install.

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

The classifications above describe Windows updates. Linux updates are organized by distribution security advisory instead, as described next.

Linux updates

The same policy framework deploys patches to your Linux fleet. Targeting by tag, maintenance windows, pre-staging, reboot behavior, deployment rings, and deployment monitoring all work the same way as for Windows. What differs is where Linux updates come from and how you approve them.

Supported distributions

TridentStack Control manages updates on:

• Ubuntu 20.04 LTS and later
• Debian 12 and later
• RHEL 8 and later, plus the RHEL-compatible Rocky Linux 8 and later and AlmaLinux 8 and later
• Fedora (latest stable)
• Amazon Linux 2 and later

The agent uses each system's native package manager (APT on Debian and Ubuntu, DNF on the RHEL family), so updates install exactly as the distribution intends.

Vulnerability detection covers Ubuntu, Debian, RHEL and its compatible rebuilds (CentOS Stream, Rocky Linux, AlmaLinux), and Amazon Linux. Fedora endpoints are patched and inventoried normally, but TridentStack Control does not currently ingest a Fedora security advisory feed, so Fedora endpoints do not report CVE matches.

How Linux updates are detected

The agent queries the system package manager for available package updates and reports them, flagging which ones are security updates. TridentStack Control enriches those against published distribution security advisories (Ubuntu Security Notices, Debian Security Advisories, and Red Hat advisories) to attach CVE references and severity. This lets you prioritize security-relevant updates consistently across a mixed Linux fleet.

TridentStack Control automatically re-checks each Linux endpoint on a recurring schedule, roughly every few hours, so newly available package updates and their security classifications appear without any manual action. Because Linux updates come from the endpoint's own package manager rather than a central catalog, this periodic re-check is what keeps Linux pending updates current.

Proxmox VE hosts

Proxmox VE hosts are managed like any other Debian-based endpoint, with one difference in how updates are applied. When you install a Proxmox host's pending updates, TridentStack Control applies the full set in a single operation using Proxmox's supported upgrade process. This keeps the kernel and Proxmox platform packages current together, rather than leaving them held back the way a plain package upgrade would.

TridentStack Control does not perform major Proxmox release upgrades (for example, moving a host from version 8 to version 9) as part of routine patching. A major release upgrade is a separate, deliberate procedure, so a normal patch run will never cross that boundary on its own.

Approving Linux updates

Linux updates use the same approval workflow described above: nothing installs until it is approved, and approved updates install during the targeted endpoints' next maintenance window. An install you start by hand, from the endpoint's page or the Endpoints bulk action, runs right away instead of waiting for the window.

Because distributions publish a continuous stream of updates, auto-approve rules are the practical way to manage Linux at scale. Linux auto-approve rules can match on:

• Distribution and release - for example, only Ubuntu 22.04, or every Debian release.
• Severity - for example, auto-approve advisories rated High or Critical.
• Update age - approve only after an update has been available for a set number of days, giving you a built-in soak period.

You can combine these conditions (for example, "Ubuntu 22.04, security advisories rated High or above, at least 3 days old") and apply different rules to different endpoint groups by using separate policies targeted at different tags.

Install all available updates

By default, a Linux system update policy assigned to a deployment ring automatically deploys only updates tied to a published security advisory. The Linux Update Behavior section of the policy editor includes an option, Install all available updates, that changes this: when it is turned on, the ring deploys every pending Linux package update instead, not just the security-advisory ones.

This option is off by default. Turning it on includes non-security updates and updates from third-party software repositories, applied automatically during deployment ring windows without security-advisory review. Enable it only when you want fully automated, comprehensive Linux patching and are comfortable with updates being applied without that review step.

Reboots and kernel updates

Most Linux package updates apply without a reboot. Kernel updates are the exception: the new kernel is installed but only takes effect after a reboot. The policy's reboot behavior, and for ring-driven rollouts the ring's automatic-reboot settings, control when that reboot happens, so kernel updates follow the same maintenance-window rules as the rest of your fleet.

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 msupdate at /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 reboot 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 reboot.

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.

Choosing a target version

The Target Version setting in a policy's Windows Feature Upgrades section is a ceiling: endpoints are never upgraded past it. The list shows each Windows version that TridentStack Control can currently deliver.

Some versions are delivered only by enablement package for now. When you select one, a note under the list names the versions that can move to it. Windows 11 26H2 is one of these: endpoints on Windows 11 24H2 or 25H2 move to 26H2 with an enablement package and one reboot, once they have KB5124010 (build revision 9546) or a later cumulative update installed. A 24H2 or 25H2 endpoint that has not reached that update yet shows 26H2 as pending, and it installs in the first maintenance window after the cumulative update is in place. Endpoints on older versions are not offered 26H2 and keep receiving their regular cumulative updates.

The Deferral Period counts from the date Microsoft released the target version. For example, Microsoft released Windows 11 26H2 on September 29, 2026, so with the default 30-day deferral it becomes eligible on October 29, 2026. Endpoints still inside the deferral period are not offered the upgrade, and a deployment ring does not wait on them before moving to its next phase.

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.

Reboot choice (enablement package)

When triggering an enablement-package upgrade from the agent detail page, you choose one of two reboot modes:

Mode	Behavior
Install Only	Installs the enablement package but does not reboot. The endpoint remains on the current build until you trigger the reboot later from the pending upgrade banner. Best for production systems where reboot timing is sensitive.
Install and Reboot	Installs the enablement package and reboots the endpoint automatically about 30 seconds after install completes. The full sequence (install, reboot, post-reboot verification) takes 2 to 3 minutes.

Full upgrades do not offer this choice because setup.exe manages the reboot 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, Reboot Required	The enablement package installed successfully. A reboot is required to activate the new version.	Reboot Now to reboot the endpoint
Upgrade Finalizing	Setup.exe or the enablement finalization is running on the endpoint.	None (waiting for completion)
Upgrade Rebooting	The endpoint is rebooting 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.

When a Windows feature update fails, TridentStack Control now shows the specific reason it did not complete (for example, a rollback caused by a device driver, an incompatible application, or insufficient disk space) directly in the agent's history, without needing to collect logs. If the same upgrade fails repeatedly for the same reason, it is automatically paused after two attempts to avoid re-downloading the multi-gigabyte installer on every maintenance window, and resumes on its own once the underlying issue clears.

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.

tip

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.

Endpoints column

The Endpoints column in the update catalog browser shows how many of your endpoints each Windows or macOS update is currently pending on. The catalog opens sorted by this column, so the updates your fleet needs most are at the top. Click the column header to sort it the other way, or pick another column.

Click the number to see those endpoints, with their online status and operating system. Each endpoint name links to its details page. The same list appears under Endpoints pending when you click an update to expand its details.

A dash ("-") means the count could not be determined for that update. The column does not appear for Linux advisories.

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
Reboot status	Whether a reboot 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.

warning

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.