UltraVNC is a remote-control system for viewing and operating a Windows computer across a network. UltraVNC Server runs on the computer that will be shared, while UltraVNC Viewer runs on the computer used for control. The viewer sends keyboard and mouse input and receives screen updates. File transfer and remote-support components sit beside the desktop session, but UltraVNC does not create an Internet account or automatically find a computer through its name.
Server and viewer
The server can run as a normal application in the signed-in user’s session or as a Windows service. Service mode starts before an interactive login and can support unattended access. Application mode follows the current user’s session and permissions. UltraVNC keeps separate property contexts for these modes, so changing a password or port in one context may not change the service that actually accepts connections.
This mismatch explains a common failure: a connection works while the configuration window is open under one user but fails after restart. Confirm whether the service is installed and running, then edit the settings for that same mode. Restart the service after changing properties that it reads only at startup.
Ports and reachability
The normal VNC socket uses port 5900 by default, while the web viewer uses a separate port. A connection inside one local network usually needs only the server address and open firewall rule. A connection across the Internet also meets the router’s NAT boundary. Port forwarding, a VPN, or a repeater must create a path back to the server.
Opening the default VNC port to the public Internet exposes a remote-control service to password guessing and automated scans. A VNC password authenticates the viewer, but it does not by itself encrypt all session traffic. Put the connection behind a VPN or configure a supported encryption plugin, and limit firewall access to the networks that actually need it.
Consent on screen
UltraVNC can ask the person at the remote computer to accept or reject an incoming session. It can also display a notification balloon or draw a border around the shared screen. These signals make attended support visible instead of leaving the connection hidden in the background.
The query dialog has a timeout action. If the timer defaults to Accept, an unattended machine can admit a connection after nobody answers. If it defaults to Reject, legitimate support fails whenever the user cannot reach the dialog in time. Choose the timeout and default action for the actual support policy rather than leaving an unexplained preset.
Crossing difficult networks
The UltraVNC Repeater handles connections when a direct route is inconvenient. In Mode I, the viewer contacts the repeater and asks it to forward the session to a server. In Mode II, both endpoints make outgoing connections to the repeater and identify the session through matching information. Mode II can avoid an inbound server port at the remote site, but it still needs a reachable repeater and correctly opened repeater ports.
A repeater is part of the trust path because it carries every screen update and input event for the session. Protect its administration, restrict who can reach it, and keep connection identifiers difficult to guess. Repeater availability also becomes a dependency: when it stops, remote sessions that rely on it stop even though both endpoint computers remain online.
Support handoff
UltraVNC Single Click can package a small support server that an end user starts to contact a predefined helper. This reduces router work for a one-time session, but the generated package still needs a current destination and trusted distribution path. After the session, close the support component and verify that no unattended server or firewall exception remains when the user did not request permanent access.
