Resolve: jobs, restarts and approvals

How Resolve freezes, approves, runs and verifies each change on a host, how it handles restarts and silent agents, and how approval governance decides who signs off per environment.

WASViking Resolve is the remediation side of Infrastructure Defense. Every change it makes on a host, from a security update to a restart, is a job with the same contract: a frozen scope, an approval under your rules, a maintenance window, and a verdict from the next inventory. This page follows a job from the recommendation to the verdict.

From recommendation to verdict

1. Recommended actions group the pending security updates of each host, ranked by the score reduction they are expected to deliver.
2. Scheduling an action freezes it as a job with the exact package list, so the approver signs off on a concrete change. Open Review and untick the updates you want to leave for later: the job only touches what stays ticked, and the vulnerabilities closed and the expected score are recomputed for that selection. Updates left out stay recommended for the next job.
3. The job is approved under the rule of the host's environment (see Approval governance). Unless the approver picks Run now, it starts only inside the maintenance window of the host policy (see Policies). Nothing installs on its own unless an automatic deployment rule your approvers signed covers the host, and automatic reboot is off by default.
4. The agent runs pre-checks, applies the updates through the native mechanism of each platform (the system package manager on Linux, the update service on Windows, software updates on macOS), and reports the outcome per item.
5. The next inventory is the verdict: the job completes only when the reassessment shows which vulnerabilities closed and how far the score dropped. The before and after numbers are measured, and when a restart is still pending the job says so instead of declaring the work done.

Each asset has its own view of Resolve. Deploy through Resolve on the asset page and Schedule remediation on the Command Center open Resolve narrowed to that asset, with its recommended actions, approvals and jobs only. Schedule asks for a confirmation that names every update the job installs and who approves it next. When the rule of the environment lets the requester sign off, the job waits under Awaiting your approval at the top of Resolve, which lists what each job installs: nothing runs until it is approved.

When Resolve cannot schedule the fix

Resolve installs what the host's own update channel offers. When a finding has a published fix that the channel does not offer, the asset page says why: Software at Risk lists each package with How it gets fixed, and the Vulnerabilities card opens with what to do. On Windows, the findings of the operating system close with the monthly cumulative update of its release, and Resolve lists the hosts whose Windows Update does not offer it under Windows hosts missing their cumulative update, with the reason:

• Out of support. The Windows release or edition no longer receives security updates, for example a Home or Pro edition past the end of servicing of its version. Only an upgrade to a supported release closes these findings, done through Windows Update or your device management tool; Resolve does not upgrade the Windows release.
• Restart pending. The cumulative update may be installed and waiting for the restart. Schedule the restart; the next inventory reads the new build and closes what the update fixed.
• Not offered. Updates are paused or deferred by a policy, an update server has not approved the update, or Windows Update fails on the host. Once the host offers it, it appears as an update to schedule.

Patch Management: hosts and decisions

Patch Management lists every update the hosts report pending, one row per update. A Windows update is its KB number, whatever language each host titles it in; any other update is its package and target version. The Assets count opens the update's own page: every host that misses it, the version installed there now, and where the update stands on each host. It can be ready to install, in a Resolve job, failed on the last attempt (with a link to the job and what the host reported), installed with a restart pending, waiting behind another change on the host, paused after a rollback, or out of Resolve's reach, with the reason. The Failed column counts the hosts where the last Resolve job that carried the update did not install it.

The Resolve installs column says whether Resolve carries the update:

• Security updates are offered on every host that can take a job.
• Regular updates (drivers, platform components, definitions) are offered only after someone allows them.
• Windows updates without a KB number, mostly drivers, are not installed by Resolve yet: the agent addresses Windows updates by their KB number. Windows Update or the vendor's tool installs them.

A decision applies to the whole organization:

• Allow. Resolve offers the update on every host that can install it, regular updates included.
• Decline. Resolve stops offering it on every host, and the risk after the security updates leaves it out. A reason is required. Its findings stay open: declining an update is not accepting the risk of its findings, which is a separate decision on the findings themselves.
• Clear decision. Back to not reviewed: security updates are offered, regular ones are not.

Every decision records who made it, when and why, and lands in the audit log. It covers one release, so next month's update is a new row to review. It governs what WASViking offers; the operating system's own automatic updates are outside it.

Select updates and choose Schedule on the hosts that miss them to create one Resolve job per host, carrying only those updates. Each job follows the governance of its host's environment. The approvers of a formal environment get one request for the whole group, and the wave approval on Resolve decides them together. Hosts with another change in flight, no agent, a policy that blocks patch jobs, or a required back-out plan left empty are skipped and counted.

Automatic deployment rules

A rule installs pending updates on its own, in each host's maintenance window, within what it allows. Open Patch Management, Automatic deployment, and choose New rule. A rule answers four questions:

• Which hosts. Servers, workstations or both; the environments; optionally some policies, sites or tags (only hosts carrying one of the ticked tags, or never hosts carrying one of the excluded tags); never the hosts you exclude. Only hosts with an agent count. A host belongs to one rule only: the oldest rule that takes it.
• Which updates. Security updates by the worst severity of the findings they close on the host (critical, high, medium, low, or no known severity for a security update matched to no finding), and optionally the regular updates the organization allowed and third-party applications on Windows. A rule can wait a number of days after the platform first saw an update in the fleet.
• When. Always inside the maintenance window of each host's policy, read in the host's own clock; a policy window can open on several days of the week. Every window, or once a month: the first window a set number of days after Patch Tuesday.
• How. Restart when an update asks, where the host policy allows automatic restarts; at most a number of hosts at the same time; pilot hosts first, the rest only after the pilots succeed; and a pause when more than a set share of a window's jobs fail.

The agent tells a server from a workstation by the operating system edition on Windows (Windows Server against Windows 10 and 11), by the graphical desktop or an active graphical session on Linux, and every Mac is a workstation. The asset page can pin a host to either type ("Treat as server" or "Treat as workstation"); the pin decides whether a restart asks the signed-in person first and which rules take the host. Tags are added on the asset page or, for many hosts at once, on the Assets list: tick the hosts, type the tag and choose Add tag to selected.

Never in a rule's job: a declined update, an update held after a rollback on the host, an update that failed twice on the host in 30 days, and an update not yet tested in a lower environment when the approval governance of the environment asks for it (it waits for a later window). Third-party applications go in a window with no operating system update pending for the host, since a host takes one job at a time.

Approval. Saving a rule asks the approval governance of every environment it reaches: an automatic environment signs at once, a one-person environment needs one approver, and a formal environment needs its quorum and never counts the person who saved the rule. The rule then stays approved for 90 days; after that it creates nothing until every environment signs again. Changing its hosts or its updates asks for the signatures again and cancels the jobs no host picked up yet; changing its name, restart or rollout does not.

At each window. Thirty minutes before a host's window opens, the rule creates the host's job with what it allows on that host and approves it in the name of the environment's approver, with a decision record that names the rule. The job carries the Automatic badge on Resolve and follows the window like any job: a host off for the whole window gets it in the next one. The rule page tells each window in words: a status (All good, With failures, In progress, Hosts missed the window, Cancelled, Nothing to install) and a sentence such as "2 hosts: installed on srv-a, 1 with nothing to install". Open a window to see every host with what happened to it, the updates it installed, the risk before and after, the last line of the log when it failed, why it got nothing (for example, pending updates that are regular or third-party while the rule takes only security updates) and a link to the job; the numbers filter the list. Pauses, resumptions and changes of the rule appear between the windows. The Hosts of this rule block lists the hosts the rule installs on, each with its policy window and its last outcome, and the hosts with an agent it leaves out, with the reason (type, environment, tags, an older rule). Needs attention stays on the page and says so when nothing needs a person. Preview host by host shows what the rule would install now. After each window, the person who saved the rule and the people who signed it get a summary by e-mail; each job's outcome also reaches the organization's alert channels.

Hosts outside every rule keep working as before: Resolve recommends and a person schedules.

Patch Management opens on an Overview: the next recommended action (a failed install, a rule waiting for a signature, a regular update waiting for a decision, a host of a rule without a window, in that order), six KPIs that open their own cut of the list (updates waiting for a decision, updates that close findings, hosts waiting for a restart, jobs deployed through Resolve since the beginning, active rules with what they installed in 30 days, and what needs a person), the state of the rule with its last window, the recent activity of the rules, and the last risk drop the reassess confirmed. Updates and decisions keeps every count, the chart, the list and the Allow, Decline, Clear and Schedule actions, now in three parts: system updates (with a search box and a decision filter, the risk impact, the decision and the deployment of each package in words), third-party applications and the Resolve history; a View package button opens each update. Automatic deployment has the rules and, beside them, Executions and results: one line per host and window across every rule, filtered by rule, outcome or host, with a CSV. The rule page has four tabs (Summary, Hosts and eligibility, Windows and jobs, Approval and record) and the rule form is a six-step assistant whose last step sums the rule up in words and previews it host by host before anything is saved.

Third-party applications on Windows

Browsers, readers, runtimes and other applications get their own action, "Upgrade third-party applications", fed by the upgrades the winget channel offers on that host. It follows the same freeze, approval and per-item outcome, and the agent upgrades each application by its channel id and nothing the job did not name. For the applications the detection engine maps (browsers, mail clients, editors, runtimes and other common desktop software), the installed version is matched against the NVD by product and version, so the action shows the vulnerabilities the upgrade closes and the expected score, like a security update does. An application without a mapping keeps the "app currency" label, and the job keeps it on the vendor's current version. The verdict is the next inventory no longer offering the upgrade, with the findings it closed.

Restarts

One change at a time. Right before installing, the agent reads the host's own restart signals: the servicing stack, Windows Update and pending file renames on Windows; the reboot-required marker or needs-restarting on Linux. When a restart from an earlier change is still pending, the job is held instead of stacking a second change on an unfinished one. The Resolve screen shows "Held, restart pending" with the reason, the asset shows since when and after which change the restart is due, and the job resumes on its own the moment the host reports the restart done.

The policy decides the exception: restart the host first (only when the approver also granted the reboot) or install anyway. On Windows, security updates and rollbacks still wait on the servicing stack and Windows Update signals, since Windows Update refuses installs while they are set. Pending file renames are a weak signal: endpoint protection and installers write them constantly and a restart does not always clear them, so they do not hold a third-party application upgrade, and a job held only by them runs once the host has restarted. A "Restart host" action on the held job, on the asset and on the Agents screen clears the wait with one click, for people with the Remediate permission. An approver can also run a held job without the restart, with a stated reason kept in the approval record of the job and in the audit log. A job still waiting after a day raises an alert in your channels.

A restart can also be scheduled as a job of its own. The Resolve screen recommends "Restart host to finish pending changes" for every host with a restart pending, and the "Hosts waiting for a restart" report lists them oldest first with the cause, the host role, the signed-in sessions and the policy that applies, with a CSV export and a "Schedule restart for all" action. A restart job follows the same contract as any change: approval under the policy, the maintenance window, and a verdict from the next inventory, which proves the restart by the boot time the host reports. The agent tells servers from workstations on its own. A server restarts after the countdown the policy sets; a workstation with a person signed in is asked first and may postpone as many times as the policy allows, after which the countdown runs without a question. A host whose restart stays pending for seven days raises its own alert, job or no job.

Reboot Pending, in the Infrastructure Defense menu, lists every host waiting for a restart on its own screen: what caused it, since when, who is signed in, the last boot and contact, what the host's policy does and the risk score, with counters for the overdue ones, the ones with signed-in users, the ones holding Resolve jobs and the ones already scheduled. Tick hosts and Schedule the restart to preview the change host by host (approval, window, prompt, or why a host is skipped) and create one restart job per host; Restart now sends the agent an immediate restart command, outside any window or approval, for the moment a person has decided it cannot wait.

Following a job

Every job in progress says where it is and what comes next: waiting for the next check-in of the agent (with its last contact), waiting for the maintenance window, held for a restart (the signal, how many checks so far, the next check and when the hold expires), running on the host or confirming the result.

While a job runs, the agent reports each step as it happens: the phase (checking the host, refreshing the package sources, downloading, applying, checking the result), the package or application it is on, how many are done with a progress bar when the package manager tells the total, how long the job has been running and when the agent last reported. Windows Update reports its download and install phases; winget, apt and dnf report item by item. A job whose agent keeps reporting is not failed by the result window, however long the transaction. The Resolve table refreshes on its own while jobs are in progress, and the running step updates in place.

A job approved for a host whose agent stopped checking in, for example because endpoint protection removed it, shows the agent offline since its last contact, raises one alert after a day and fails after seven days with a note that says what to do. The waiting jobs of a host whose agent is removed are cancelled at once, and a cancelled job keeps what it was waiting on.

The Jobs table of Resolve is built for volume. Chips on top filter by situation (waiting for a decision, in progress, completed, failed or partial, rejected or cancelled), each with its count; next to them a host, a type of job (security updates, third-party applications, restarts, rollbacks, mitigations, automatic rules), a period and a free search (host, package, job id or batch) narrow the list. The filters live in the page address, so a filtered view can be shared or bookmarked. The table shows 25 jobs per page, newest first, and says how many match. Jobs waiting for your decision stay on top of the page whatever the table shows, and the summary tiles count every job, not only the page. The note under a job's status, what the reassess verified, why a job is held, who cancelled it, reads in the portal's language.

The risk column reads as a sentence, not a pair of numbers. Before is the host's score when the job was created (Now, on a recommended action); Expected is the score the change should reach; After is the score the reassess measured once the job ran, and the one that counts. The difference comes in words: a green drop in points, "No change", or a red rise for a rollback, which raises the score on purpose. When the score did not move, a line under the numbers says why: the finding the score follows, or the fact that what the job closed does not set the score. "What is the VES score?" next to the tables opens the explanation.

Rolling back a change

A completed security update job on a Linux or Windows host offers "Roll back this change": a rollback job for the same packages, each one returned to the exact version it had before, with a mandatory reason, the back-out plan carried over, and the approval, window and restart rules of any other change. Linux downgrades through the package manager and leaves the kernel alone; Windows removes each update by its KB through Windows Update and reports the ones the platform does not allow removing; macOS has no uninstall path, and the screen says so. The reassessment measures the result as it is, for example "VES 70 to 88, 3 of 3 packages returned, 17 vulnerabilities open again", and the returned updates stay held out of the recommendations for the days the job asked, visible on the host and released early with one click. See Roll back a change that misbehaved.

Applied patches, a tab of Patch Management, lists every update Resolve installed per patch and per host, with the version it replaced, when, the job that proved it and whether it can go back. Tick packages on one or many hosts and Roll back the selection: the preview shows, host by host, exactly what returns, the findings that open again, the expected score and the approval of the environment, with every pick that cannot go back explained (a kernel, an update with no previous version, a package updated again later, a job in flight). Creating the jobs makes one rollback job per host carrying only the packages picked, with a mandatory reason and a hold that keeps them out of Resolve for the days chosen. Updates installed outside Resolve are not listed, because the platform does not know the version to return to. Each host that can go back also carries a Roll back button that previews that one package on that one host, and the job page of any finished update offers the same two paths: roll back the whole job, or choose the packages on Applied patches.

Mitigating without a patch

Not every finding is closed by an update. The Mitigation screen changes the host itself when a patch is not the answer: a registry value, a service state, a Linux kernel parameter, an approved script from your own library, or a software install or removal. Built-in mitigations fix the failing posture controls they name, and documented workarounds contain well-known Windows vulnerabilities that have no fix applied yet; a verified workaround marks the finding "Mitigated, no fix applied", which leaves the score like an accepted risk and opens again the moment the change is reverted. The same actions run before and after the updates of a patch job, for example a service stopped first and started again after.

Every change is a job under the approval governance of the host's environment. A script or software change is not approved automatically, scripts are off until your organization turns them on and need a second person's review, and a host can refuse them in its local configuration. The agent records what each change replaced so it can be undone, the next inventory proves it held, and a change that something puts back shows as Reverted with an alert. See Mitigate a finding without a patch.

Approval governance

Approval governance decides who signs off, per environment. Each host carries an environment (production, staging, development or other), and the Approval Governance screen sets a rule for each one: follow the host policy, approve automatically, let one person approve (the requester included), or require a formal approval. A formal rule says how many approvals a job needs and, optionally, who may give them, by name or by role; the person who scheduled the job does not count.

Every decision is recorded with who decided, when, the stated reason and the change reference, and the approval records export as CSV: the evidence a change control audit asks for. A production rule can also require the same packages to have completed in staging or development within a window before production accepts them; a job that arrives untested says so, and an approver has to waive it on purpose. The person scheduling a change can state why it is needed and how it is undone, and a rule can refuse a change scheduled without that back-out plan; both stay in the approval record and the export.

Approvals that wait past the window set in the rule are cancelled, formal approvals waiting are announced to your alert channels and to the approvers by e-mail, and the requester hears the decision. When the rule allows it, an emergency approval runs the job without the quorum, with a stated reason; every approver is notified and the job stays flagged until another approver reviews it. When the rule names its approvers, the emergency path belongs to that list too.

A job answers to the environment it was created in. Moving a host to a less guarded environment afterwards changes nothing for jobs already waiting, and the move itself needs the Approve permission, is recorded with the before and after, and raises an alert on your channels.

Policies

Policies decide how far the platform may go on each group of hosts: what gets assessed, whether jobs need manual approval where the governance follows the policy, and when changes are allowed. The same policy sets how much of each machine the agent may use, described in Sentinel Host agent: requirements and operations. Every action lands in the audit trail, and the outcome of a patch job can notify your Slack, Teams, email or webhook channels.

The maintenance window is one or more days of the week with a start and an end, read in each host's own clock: a 22:00 window opens at 22:00 where the host is. A window may cross midnight (22:00 to 02:00 ends the next day). A job approved without Run now is handed to the host only while the window is open, and the job line in Resolve says when it closes. When the host is off or offline for the whole window, the job moves to the next one, so a change never starts outside it. A job with signed steps that would expire before the next window is cancelled with a note instead, to be scheduled again. Run anyway on a job held for a restart lifts the hold, not the window.