DeskVNC agent hub
Platforms / Windows

Windows: signed installer, SmartScreen first run, the same dvv binary on every other host

DeskVNC lands on Windows as a code signed installer for desktop users, and as an MSI for deployment tooling, with the same dvv MCP server that ships on macOS and Linux. Credential Manager holds every password, and the binary the agent spawns lives in one of two well known paths.

Signed installer, MSI for deployment

The release page lists two artefacts for Windows. The standard user installer is DeskVNCViewer_<version>_x64-setup.exe, code signed, with the publisher name shown in the SmartScreen prompt. For deployment tooling, the same release carries DeskVNCViewer_<version>_x64_en-US.msi, which integrates with whatever package manager the fleet uses.

Both files come from the same Rust source on Tauri 2 that builds macOS and Linux, so a team that builds DeskVNC on a Mac and lands it on Windows servers knows the loop and the lease behave the same on the other side of the wall.

To verify what you have matches the release:

PowerShell certutil
certutil -hashfile DeskVNCViewer_<version>_x64-setup.exe SHA256

The output should match the checksum published with the release. A mismatch is worth a redownload rather than a runs anyway.

SmartScreen, the first time

Microsoft SmartScreen builds reputation from a code signing certificate plus the download volume the certificate has accumulated. On a freshly installed Windows machine, or on a certificate that is still earning trust, SmartScreen shows its blue notice the first time the installer runs.

Two clicks take you through:

  1. Press More info.
  2. Press Run anyway.

The publisher line beneath that button is the field to read. It should name the signatory of the build. Subsequent launches on the same machine are quiet, because the certificate is now known.

The SmartScreen notice is a Windows behaviour, not a DeskVNC characteristic. It applies to every freshly signed installer that has not yet built reputation, and the response is the same in every case.

Where the agent binary lives

There are two paths for dvv.exe, and the right one depends on how DeskVNC was installed. Both paths hold the same binary, and the agent picks whichever the registration was written for.

The dvv binary, on Windows
Install shapePath
Per-user (no elevation)%LOCALAPPDATA%\DeskVNCViewer\dvv.exe
System-wide (elevated installer)C:\Program Files\DeskVNCViewer\dvv.exe

Worth knowing both, because the line you paste into your agent config depends on which one dvv setup wrote when you registered the MCP server:

Terminal dvv doctor
dvv doctor
# prints the exact path of the binary in use and the registration line for each agent

Saved hosts, in Credential Manager

When a host is saved with a password, the password goes to Windows Credential Manager rather than into a file next to the saved host list. Credential Manager is the same store Internet Explorer and Edge and Outlook use for remembered credentials, and it audits access through the usual Windows event channels.

DeskVNC keeps a per-host reference, and the username of each saved host, in the normal profile database. The secret that opens the host sits in Credential Manager, behind the user's sign-in. Saving a host writes nothing sensitive into the profile database, and there is a test in the project that asserts it.

An agent that opens one of your saved machines can drive the desktop, and it can never read or supply the password that opens it. The credential is applied on the far side of the same call your click goes through, and there is no method on the MCP server that returns a stored secret.

Day one on Windows

The bullets below are the things that work the moment the installer finishes, no configuration required:

  • Saved host library, with live thumbnails for every desktop you connect to.
  • Tabs and split panes, with the display and input controls already wired.
  • SFTP file transfer in both directions, over the machine's own SSH server.
  • Clipboard sync, with the direction you set on the session toolbar.
  • mDNS browsing, subnet scan with banner fingerprinting, name resolution over mDNS, LLMNR, NetBIOS and MS-RPC, and Wake on LAN.
  • The dvv MCP server, registered automatically with the agents DeskVNC finds on the machine.
  • A four-call loop in the agent, returning the same observation object on every host.
An agent holding control of two remote machines at once, seen from inside DeskVNC running on Windows, with the saved host library visible beside the session.
Agent holding the wheel on two machines at once, on Windows from the project README

Read more