Patching

Tenvara patches Windows, macOS and Linux through the agent. It scans each device for missing updates, installs the ones that are approved inside the device's maintenance window, and restarts the way the device's policy says. On Windows the agent takes over Windows Update so only approved updates are installed, and only by the agent. On macOS it uses Software Update, and on Linux apt, dnf or yum.

Open Devices > Patches. The tabs across the top are Overview, Updates, Devices, Windows versions, Policies, Server sets and History.

Overview and compliance#

A device is compliant when every approved update is installed within its deferral and grace period, and no restart is past its deadline. When some devices have nobody saying who updates them, the overview opens with Who updates N devices?, the devices listed and ticked, any that look like they update themselves with the reason, and the answers Tenvara, The device itself and Nobody (see Who updates a device below). The overview shows:

• Compliance: the share of devices compliant, not compliant and unknown, with missing updates, failed installs, restarts pending (and overdue) and checks failing.
• Last 60 days: the share of devices compliant each day, against a 95% target.
• Needs attention: devices failing to install or check, Approved updates overdue, Restarts overdue, and Waiting for a decision, the updates no policy approves on its own. Approve or Decline them here, or use the Review updates button at the top of the page, which counts them. Approve and Decline ask who the decision is for: all devices, the devices of one patch policy, or one customer, each with how many devices are waiting. The message that follows says what was decided where, with Undo (or Ctrl+Z) and Decisions, which lists every decision on that update.
• By customer: every customer, least compliant first. On a phone each customer is a card.
• Installs: what is running now, what is scheduled and when the next maintenance window opens.
• Third-party apps: app updates waiting, linking to Software deployment.

Approving updates#

The Updates tab lists every update any device has reported, with its operating system, classification, severity, approval, release date and how many devices have it, are missing it or failed it. Filter by OS, Classification, Severity, Approval, Progress or Source.

Click an update to open it.

1. Click Approve or Decline, and add a note if you like. Decisions here apply to every customer, except customers with a decision of their own.
2. To decide for one customer only, pick the customer under For one customer and choose Approve, Decline or Hold back (for example while a software vendor certifies the update).

A decision for one patch policy's devices sits between a customer's own decision, which wins, and the one for every device. A device's update then reads Approved with Decided for the devices of its policy.

If nobody decides, the policy approves the update automatically after its deferral when its classification is set to approve automatically. Those show as Approved by policy.

Who updates a device#

Not every device is yours to patch. A phone system appliance or a Linux server running unattended-upgrades updates itself, and a sealed appliance cannot be patched at all. Updates handled by says who keeps each device up to date:

• Tenvara: approvals, maintenance windows and per-update alerts, as described on this page.
• The device itself: its vulnerabilities are still listed, with one alert only when its own updating fails or falls behind.
• Nobody: its vulnerabilities are one accepted risk with a note and a review date.

Set it on the device's Patches section (Change), on the overview's Who updates N devices?, or for a group or customer in a patch policy (Updates handled by). Devices that use WSUS, unattended-upgrades or their own updater are recognised and proposed, never assumed. Tenvara schedules no installs, restarts or app updates on a device updated by itself or by nobody, and installing by hand asks first with Install anyway. See Who updates a device: Tenvara, the device itself, or nobody.

Patch policies#

The Policies tab says what gets approved, when it installs and how devices restart. The most specific policy wins, setting by setting.

1. Default policy: what every device starts from.
2. Customers: change what they set for a customer's devices.
3. Device groups: when a device is in several groups with policies, the higher Priority wins.
4. Devices: one device's own policy, the most specific of all.

Click New policy, or a policy to edit it. A new policy Applies to a Customer, a Site, a Device group or a Device. Each setting is either Inherit (from the less specific policies, with the value it would get shown beside it) or Set here.

Setting	What it controls
Updates handled by	Tenvara, The device itself or Nobody (above), or Not said here.
Automatic installs	Install approved updates in the maintenance window without anyone asking.
Approval and deferral	For each classification (Critical, Security, Definitions, Update rollup, Feature pack, Driver, Other): whether it is approved automatically and how many days after release it waits.
Maintenance window	The days, start time, length and time zone when scheduled installs and forced restarts may happen (below). A window that crosses midnight belongs to the day it starts.
Restarts	Only if required, inside the window; Prompt the user, with a deadline (the user may snooze by the choices you set until the deadline); Restart when required (a minute after the install, signed in or not); or Never.
Exclusions	Updates never approved automatically nor installed, by KB number or title.
Compliance	Grace days after an approved update is due before a device missing it counts as not compliant.
Checking for updates	How often the agent checks on its own (every 6 hours by default). Your server also asks each device to check after it enrols, once a day and before each window, and the overview shows devices that are not checking.
Third-party apps	Update apps from the software catalogue in the same window.
Windows Update	Managed by the agent stops Windows installing updates on its own, so only approved updates are installed.
Maintenance mode while patching	Puts the device into maintenance mode while updates install and it restarts, so nobody is alerted about it going offline.
Windows version	Left to Windows Update, or a chosen Windows release to keep devices on or move them to (below).
Scripts before and after installing	A published library script to run before updates install and another after them (below).
Customer approves	Hold some classes of update until the customer approves them (below).
Wake before the window	Wake devices that are asleep or off through another online device on the same network, a set number of minutes before it opens (Minutes before the window to wake devices, 10 by default), so they are ready for it. See Wake-on-LAN and remote access rules.

The Preview at the bottom shows which devices use the policy and when the next window opens.

Note: With Prompt the user, the person signed in sees a restart prompt from the Tenvara tray icon and can snooze it until the deadline. If nobody is signed in the device restarts straight away, and a prompt left unanswered for 15 minutes counts as agreement.

A site can have its own patch settings too, between the customer and its device groups (from the site's Policies tab), and a device's Policies tab shows which patch policy reaches it and from where. See Policies and where settings come from.

While updates install and the device restarts, it is in maintenance mode, so its alerts are held until it is back online. A patch policy can turn that off for its devices.

Which days a window opens#

Under Maintenance window, Which days chooses how the window repeats:

Choice	What it means	Reads as
Every week	The weekdays you tick, every week.	Sat, 02:00 to 05:00
Weeks of the month	The weekdays you tick, in the weeks of the month you tick (the first to the fourth, or the last).	2nd and 4th Sat of the month
After Patch Tuesday	A number of days after Microsoft's Patch Tuesday, the second Tuesday of the month. Each number you add is a window, and 0 is the day itself.	Patch Tuesday + 4 and 11 days
Every other week	The weekdays you tick, every second week from a date you choose.	Every other week from 3 Oct: Sat

Software deployments set to install in the maintenance window, and the turns of a server set, follow the same windows.

How the restart is decided#

A job's restart follows the policy as it is when the job ends, not as it was when the job was queued. Change a policy to Never while a long install is running and the device is not restarted; change it to Only if required, inside the window and it restarts only inside the window. A restart you chose yourself in Install now is kept.

Scripts before and after installing#

Some servers need a little help around updates: stop a line-of-business service and take a snapshot first, start it again and run a health check after. Under Scripts before and after installing in a patch policy, choose a published script from the library for Before installing and another for After installing, with the values they need and how long each may run (10 minutes by default).

• If the script before fails or times out, nothing is installed: the updates are marked skipped (not failed, so no alert), and the install says The install was skipped: the script before installing failed.
• If the install restarts the device, the script after runs once it is back up.
• The install's panel shows both scripts with their exit codes and output.

Choosing these scripts needs permission to manage scripts as well as patching. Scripts with secret or credential parameters cannot be used here; read the secret from the vault inside the script instead.

Customer approval of updates#

Some customers want to approve their own updates before they install. Turn on The customer approves updates under Customer approves in their patch policy, and choose:

• Classes the customer approves (every classification except definitions, by default);
• how many days before they are reminded;
• whether your own approval applies after a number of days if they never answer.

Updates you approve in those classes then wait on the customer's devices as Waiting for the customer. Once a month (or as updates arrive) the customer's contacts with the Approves IT changes role get one request listing the updates by class, the computers and the proposed window. They approve with one click from the email, or open Updates to approve in the portal to approve everything, approve for a later date, or decline some with a reason. Declined updates are declined for that customer and hidden on their devices. The customer's Patches tab shows what you are waiting for and their last decision. See Approvals.

Cancelling a job#

A patch job can be stopped while it is queued or running.

1. Click Cancel on the job: on its row, on the device's Patches section where the running or scheduled job shows, or in the job's panel. On the Devices tab, Cancel patch work... in a row's menu cancels every open job on that device.
2. Read what cancelling does at this point, give a reason if you like, and confirm.

A queued job never starts, and each update in it is recorded as cancelled. A running job stops after the update it is on: that one finishes, the rest are skipped, and the job ends Cancelled, listing which updates installed and which were skipped. No restart follows a cancelled job; a device that needs one shows the pending restart as usual. The job records who cancelled it, when and why, and every cancel is in the audit log.

Server sets#

Servers that do one job, such as two domain controllers or the nodes of a failover cluster, should never patch or restart at the same time. Put them in a server set on the Server sets tab and Tenvara gives each member its own turn, checks its partners are online and healthy before it installs or restarts, drains a cluster node first, and holds patching while the set is degraded. See Server sets.

Removing an update#

When an update causes trouble, take it off again.

1. On the device page, the Patches section lists what is installed, newest first, with Remove on each update that can be taken off and the reason on the rest. For many devices, open the update on the Updates tab and use Remove from devices.
2. Choose how the device restarts, as for an install.
3. Under So it does not come back, choose Do not decline, Decline for the customer or Decline for every customer.
4. Confirm.

On Windows, Tenvara removes the update through Windows Update where it allows, otherwise by its KB number. Some cumulative updates are a permanent part of Windows and say so. Definition updates and drivers without a KB are not offered for removal. On Linux the package goes back one version, when the repositories still have it. Updates cannot be removed from macOS. Removals show as Removal in History, and a failed removal never raises an install failure alert.

Windows versions#

The Windows versions tab shows every Windows computer by release (Windows 11 25H2, 24H2 and so on, and Windows 10 22H2), with each release's end of support, red when out of support and amber within 180 days. Click a release to filter the list to it.

Keeping Windows on a version#

A patch policy's Windows version setting keeps Windows devices on a feature release (stay on 24H2) or moves them to a newer one, through Windows Update's own target release setting. Choose Left to Windows Update to let Windows decide, or pick a release from the list, which shows each one's end of support and warns when it is out of support or nearly so. Taking the setting away puts back whatever was there before.

Windows never goes back to an older release, so a target older than a device's current release leaves it where it is, and the device page says so. Windows Server is shown with its end of support but never given a target.

Windows 11 readiness#

Each Windows 10 computer reports whether it is ready for Windows 11: TPM 2.0, UEFI and Secure Boot, memory, disk size and free space, the processor, and Windows' own compatibility verdict. The list shows the reasons a device is not ready, with the values found, and the device page's Windows 11 card says the same. Check compatibility runs Windows Setup's own compatibility scan on the device, from the Windows 11 media you point to under Windows 11 upgrade media in Settings > Device management (or the customer's settings), without upgrading or restarting anything, and reports what would stop an upgrade.

Linux#

On Linux the agent uses the distribution's own package manager: apt on Debian and Ubuntu, dnf or yum on Fedora, RHEL and their relatives. A scan lists the pending package updates and marks the ones the distribution flags as security updates, so the Security classification in a policy covers them. Approved packages are installed in the window like any other update, and each install appears in History.

One device#

The Patches section on a device page shows who updates it (Updates handled by, with Change), its compliance, when it last checked, the next window, the missing updates with their approval and due date, and recent installs.

• Check for updates asks the agent to scan now.
• Install now installs straight away (it is not offered on a device that updates itself or that nobody has decided about), without waiting for the window. Approved updates are ticked; anything you tick is installed. Choose how to restart: As the policy says, Do not restart, Ask the user or Restart when needed.
• Each update shows its real download size, what the device actually downloads rather than the size of the full package.
• On Windows, the section also shows the release, edition and build, its End of support, and the Target version with what it means for this device.
• A server in a server set shows the set, its partners and its next turn. Restarting or installing by hand while a partner is down or patching asks you to tick Go ahead anyway and say why.

Devices and history#

• Devices lists every device with the agent, whether it is compliant and why not (for example 3 approved updates overdue or 2 updates failed to install), the last signed-in user, what is missing, what failed and what is running. Each row has its own actions menu.
• History lists every install attempt and removal on every device, newest first: the update, the result (with the error code when it failed) and what triggered it, such as Maintenance window.

Patch problems also raise alerts with the source Patch management, and the monitoring threshold Critical updates pending for 30 days alerts on devices that fall far behind. See Alerts.