The Updates screen checks local or signed remote evidence for the VaultPilot server MSI and starts an eligible installation job. It tracks Windows Installer and service-restart progress.
Access, role, and license boundary
The Updates screen needs the auto-update license feature. With it, Owner, Admin and Auditor can view the screen and current server status; the User role cannot open it. A read-only license hides the screen.
Check live requires Owner or Admin, and repeated checks in a short time are refused for a while. The audit history records a check only when it returns a status; a check that fails to read the manifest records nothing.
Only the Owner can start a server MSI installation. An Admin cannot start it, even if a button or message suggests otherwise. A read-only license also blocks installation. Auditor is view-only and cannot run a live check or an installation.
What you can do here
- Review the current server version, target version, package name, size, SHA-256 and verification steps.
- Read Verification steps to understand why the package is Current, Ready or Action required.
- Use Check live to read the release manifest again and re-verify the signature and package.
- When the package is eligible, use Install server MSI as Owner.
- During installation, watch the percentage, Last record age, target version, steps and the Advanced technical log summary.
- After installation, confirm the running version matches the target and the console reconnects.
There is no cancel control and no general Retry action. A blocked job stays as evidence. After fixing the cause and verifying the package again, choosing install again creates a new job; it does not resume the old one.
Components and release surfaces
The only installation card here is the VaultPilot server MSI. It shows Artifact, Latest version, Package size and SHA-256 when available. Artifact is taken from the download address; without one it says Package path pending, even when the file name is known. Download MSI appears only when a download address is available.
Browser extension installs and updates come from the Chrome Web Store; this screen does not create an extension job. Offline Share Decrypter, DC Agent and other components can appear in Release notes, but they have no installation cards or jobs here.
The Release notes timeline is built into the current console and groups versions, components and notes. The topbar’s latest-release summary is informational. When the release host cannot be reached, the ticker can show the local version and still say released. A release note, the ticker or a Check live result alone does not prove that a newer release is available with every file.
Local status and live check
The screen first reads local server status:
- Without an eligible staged MSI, the running version is Current and no installation starts.
- A newer local MSI with a readable version has its size and SHA-256 calculated and can become Ready. This is a local pre-check only.
- A downgrade, an unknown-version package or a same-version package is Action required for automatic install. Same-version repair belongs to the manual MSI Repair path.
Check live reads the HTTPS release manifest from the server. A successful check means the signed manifest was verified and the server MSI was found and evaluated. If the verification key is missing or the signature fails, download addresses stay hidden and download is blocked. While the live check is blocked, the screen may mention a local package but shows no local package card or download link.
When the release host or the latest-release summary cannot be reached, the screen creates nothing and never treats a local package as remote evidence. A local package is checked separately: version and SHA-256 first, Authenticode inside the installation job.
Package and signature verification
Remote automatic installation follows this trust chain:
- Verify the manifest’s Ed25519 signature with the release public key.
- Match the server MSI to the allowed release address, file name, version and expected file size from that signed manifest.
- Download on the server and compare the SHA-256 with the manifest value.
- Read the MSI Authenticode signature on Windows. If the manifest names a signer, the MSI signer must match it. The published v3.0.3 MSI is unsigned and is accepted only from the official release after steps 1–3 pass; local and staged MSI packages still need a valid Authenticode signature.
- Start the quiet Windows Installer step only after those checks pass.
A local staged MSI card checks version, file presence, size and SHA-256 only. It does not verify a manifest signature, and Authenticode runs only after the job starts. There is no supported way to skip installer signature checks. Local Ready means only that the pre-check passed, not that signature verification or installation completed.
The card shows only the start of the SHA-256. Do not use that fragment as proof of a full match.
Package and job states
Package status
| State | Meaning |
|---|---|
| Current | No eligible newer local or remote MSI exists for the running version. |
| Ready | The signed manifest checks passed, or the local version and SHA-256 pre-check passed. For a local package, Authenticode is still checked during the job. |
| Action required | The verification key, manifest, package or version is missing or unsuitable. Read the blocked step. |
Update job status
| State | Meaning |
|---|---|
| Queued | Rarely shown by current versions; treated as active. |
| Running | Download, verification, MSI or restart work is in progress. |
| Blocked | A security, package, Windows Installer, UAC or reconnect step stopped progress. There is no separate failed state. |
| Completed | The running VaultPilot version meets the target version. |
If the request fails before a job is created, the screen says The update action could not be started; no job is recorded. The job list shows active jobs first, then the most recent finished jobs.
Steps and technical log
Each step is done, running, pending or blocked. Server MSI steps can cover:
- reading the installed version and accepting the target version,
- choosing a local package or downloading the verified MSI on the server,
- checking the downloaded SHA-256,
- checking and recording the MSI Authenticode signature,
- running the quiet Windows Installer,
- restarting VaultPilotServer and waiting for the target version.
Verification steps come from the package status or the selected job. While work is active, Advanced technical log lists every job step with its state and detail. It is not the raw PowerShell, MSI or Windows Event Log. Some details hide local paths, but read every line before sharing it.
Installation, UAC, and service restart
Server installation runs Windows Installer quietly without reboot prompts, then restarts VaultPilotServer. The browser can lose contact during that step. When the server is back on the new version, the console tries to reload.
If the installer needs administrator rights, Windows can show a UAC prompt. It appears in the Windows server session, not in the browser. If nobody approves it, the job becomes Blocked around the MSI step. Do not start installation without an authorized Windows administrator session and an approved maintenance window.
Updates does not schedule a maintenance window, take a backup or notify users. Prepare a backup, a short service interruption, user communication and a rollback path before starting.
Blocked-state recovery
Jobs are read again after a page reload or when the service returns. A running job is compared with the installer result and the running version:
- If the target version is already running, the job can become Completed.
- If the MSI finished but the service has not returned on the target version, the restart step stays active and eventually becomes Blocked.
- If the installer never started, the job can stop around
76%. - If the installer started but never reported that it finished, the job can stop around
82%. - If the MSI finished but the target version was not confirmed, the job can stop around
96%.
An unchanged percentage for several minutes does not by itself mean a stall. If Last record stays fresh, wait. After a page reload the job may stop refreshing on its own; click into the window or refresh the page to see the latest state. Check live checks the package, not the job. Before starting new work, confirm that neither Updates nor Executions shows an active job.
Do not edit the database, replace a package without verification or bypass signature checks. Keep the evidence, fix the cause, check again with Check live or trusted local evidence, and only then start a new installation job.
Recommended workflows
Verify and install a remote MSI
- Prepare the maintenance window, backup, rollback plan and Windows administrator access.
- Choose Check live and confirm the manifest signature and package steps are not blocked.
- Compare file name, target version, size and full SHA-256 with the official release; compare the signer too when the manifest names one.
- If the package is Ready, choose Install server MSI as Owner.
- Watch the download, SHA-256, Authenticode, MSI and restart steps.
- After reconnecting, confirm the running version, service health and final job state.
Investigate a blocked job
- Find the first blocked step and the Last record time.
- Separate manifest, signature or hash failures from Windows Installer, UAC or service failures.
- Keep redacted evidence before changing the package or trust settings.
- When relevant, use the 76-percent KB article and Windows Installer or VaultPilot service evidence.
- Do not start another job until the cause is fixed; run a fresh check afterward.
Screen states
| State | Operator response |
|---|---|
| Loading | Placeholder rows appear; do not treat the blank moment as the package status. |
| Update status could not be read | Check the session, role, auto-update license feature and server connection. |
| Current | There is no new MSI to install; release notes do not mean a newer MSI is available. |
| Ready | Confirm version, manifest, full SHA-256, signer when the manifest names one, and the maintenance window before the Owner starts it. |
| Action required | Resolve the first blocked verification step; do not force download or installation. |
| Check running | Do not start a second live check; wait for its result or warning. |
| Installing | Watch Last record as well as the percentage and expect a service disconnect. |
| Awaiting UAC | Handle the prompt in the Windows server session; do not accept an unexpected request. |
| Holding near 76/82 percent | Wait while fresh records arrive; if the job becomes Blocked, check the installer evidence. |
| Holding near 96 percent | Compare the MSI result with the running server version; do not call it complete before the target version is confirmed. |
| Blocked | Keep the blocked step and redacted detail; there is no automatic retry. |
| Completed | Treat it as complete only when the running version and service health meet the target. |
| Console disconnected | During the approved window, wait for the service to return; then refresh the page and do not start a second install right away. |
Before you act
- Confirm the Owner role, the auto-update license feature and a writable license.
- Prepare an approved maintenance window, current backup, rollback method and Windows administrator access.
- Do not mix local and remote evidence; confirm whether the package is local or from the official release, and the target version.
- For remote packages, check the manifest signature, allowed release address, file name and size, full SHA-256 and, when the manifest names one, the Authenticode signer together; for a local Ready package, remember that Authenticode runs during the job.
- Check Updates and Executions for a job that is already queued or running.
- A live check, release note or latest-release summary does not prove installation success.
Safe evidence
- Safe to share: local or official source, component, release version, package file name and size, whether the SHA-256 matched, Authenticode status or signer summary, step state, broad time window and the error message.
- Keep private: local download paths, server host and user name, job identifier, private support addresses, copied MSI files, raw PowerShell, MSI or Windows Event logs, support bundles, license data and signing keys or certificates.
- The full SHA-256 of an official release MSI is not secret; for any other package, confirm it matches the official release before sharing its hash.
- In screenshots, mask the Artifact text, step details and exact Last record time.
When to stop and escalate
Stop installation when the manifest signature cannot be verified, the SHA-256 or size differs, the Authenticode signer does not match, an unexpected UAC prompt appears, the MSI rolls back, the service does not return on the target version, or the job stays Blocked. Before replacing a package or starting a new job, email support@vaultpilot.io with the version, source, step name, broad time window, error message and redacted signature and hash result.
Operator notes
Updates verifies and installs the server MSI. It does not build or sign packages, and release notes are not a live view of available releases.