Windows - Configuration - Disable TightVNC Service at Startup

What the TightVNC startup blocker does

This Automox Worklet™ prevents the TightVNC tvnserver service from launching at Windows boot. A default TightVNC Server install registers tvnserver with a StartType of Automatic, which means the VNC listener binds to TCP 5900 on every reboot whether an administrator is actively using it or not.

The Worklet flips that StartType to Manual so the service is available on demand but is no longer a persistent network-facing listener. Endpoints without tvnserver installed are skipped, and endpoints already set to Manual or Disabled are left alone, so the policy is safe to run across a mixed Windows fleet.

Active VNC sessions are not interrupted. The change is written through the Service Control Manager and takes effect at the next reboot, so any administrator currently connected over VNC keeps their session through the remediation window.

Why block automatic TightVNC startup

A tvnserver service set to Automatic is a persistent listener on TCP 5900 that survives every reboot. Port 5900 is a known target for credential stuffing, brute force against weak VNC passwords, and lateral movement once an attacker is inside the network. Ransomware operators routinely scan internal ranges for 5900 after compromising a single endpoint.

TightVNC has also shipped with its own CVEs, including CVE-2019-15679 and CVE-2019-15680, that are only reachable when the listener is actually running. Switching tvnserver to Manual removes the persistent listener without uninstalling the tool, so the endpoint stops advertising VNC on TCP 5900 between support sessions while administrators retain the ability to start the service on demand.

Running this Worklet on a recurring schedule also catches the case where a help desk technician reinstalls TightVNC on a problem endpoint and the installer silently re-enables Automatic start. The Automox activity log captures the prior StartType per host, which gives auditors a per-endpoint trail of the change.

How TightVNC startup blocking works

1. Evaluation phase: The Worklet runs Get-Service -Name tvnserver to confirm the service exists. If the service is missing, the endpoint exits 0 and is treated as compliant, because there is no TightVNC listener to harden. If the service exists, the script reads its StartType. A StartType of Automatic triggers a non-zero exit, and Automox schedules remediation. A StartType of Manual or Disabled exits 0 and the endpoint is left alone.

2. Remediation phase: The remediation script re-reads the StartType inside a try/catch and calls Set-Service -Name tvnserver -StartupType Manual when the value is still Automatic. Set-Service writes the change through the Service Control Manager, which updates the underlying registry value at HKLM:\SYSTEM\CurrentControlSet\Services\tvnserver\Start. On failure, the catch block emits the exception message and the failing script line number to the Automox activity log and exits 1, so a permissions error never fails silently. On success the script exits 0 and the change applies at the next boot.

TightVNC startup hardening requirements

• Windows 10 or later workstation endpoints, or Windows Server 2016 or later (the source Worklet is marked WORKSTATION and SERVER compatible)

• TightVNC Server installed and registered as the tvnserver service; endpoints without tvnserver are skipped automatically

• PowerShell 5.1 or later, available on every supported Windows build by default

• Permissions to modify service configuration under HKLM:\SYSTEM\CurrentControlSet\Services\tvnserver; the Automox agent runs as SYSTEM, which already has this access

• No external PowerShell modules required

• FixNow compatible, so an administrator can run the hardening on demand against a single endpoint, a group, or the full fleet without scheduling a policy

Expected TightVNC service state after remediation

After remediation, Get-Service -Name tvnserver | Select-Object Name, Status, StartType reports StartType as Manual. The service is no longer started during boot, which means TCP 5900 stops listening on the endpoint after the next reboot. Administrators can still launch the service on demand from Services.msc, or by running Start-Service -Name tvnserver from an elevated PowerShell session, when a support session is actually required. Stopping the service at the end of the session restores the hardened state.

For audit evidence, capture the output of sc.exe qc tvnserver and reg query "HKLM\SYSTEM\CurrentControlSet\Services\tvnserver" /v Start. A Start value of 3 corresponds to Manual; a value of 2 is Automatic and would indicate the change has not yet applied. This Worklet aligns with CIS Windows Benchmark guidance on disabling unneeded services and with the broader NIST 800-53 CM-7 principle of least functionality. Pair it with a companion Worklet that uninstalls TightVNC outright on endpoints where remote support has been migrated to a different tool, so the catalog covers both the harden case and the remove case.