Install and manage a Windows host

This page is for the person who administers the Windows machine. If you only need to connect to a host someone else owns, use the first-connection guide instead.

Before installation

1. Check Windows compatibility, GPU encoding support and the Microsoft licenses required for your deployment. PrimalDesk does not supply Windows Server or RDS CALs.
2. Use a separate Windows account for each person who will have a separate session. Decide who can administer the machine and who should only connect.
3. Make sure the host can resolve api.primaldesk.com, reach it over outbound TCP 443, and send and receive permitted UDP traffic. See Firewall and ports.
4. Obtain the signed host setup package from your beta invitation or administrator. Public download and pricing pages are not available during this testing phase. Do not use an unsigned development build on a production server.

Install the host

Run PrimalDesk-Host-Setup.exe with administrator approval on the Windows Server that will host sessions. The bootstrapper installs missing Visual C++ and WebView2 runtimes before the per-machine MSI. The MSI installs the host service, Remote Desktop Services provider, display/input/audio drivers and local administrator application. The default directory is C:\Program Files\PrimalDesk\Host.

Allow Windows to finish driver installation and restart if setup requests it. Confirm the installer signature before granting elevation. Repair and uninstall are available in Windows Installed apps. Do not manually copy driver files or expose Windows RDP to the internet as an installation shortcut.

The first-run administrator flow is still being finalized. For now, follow the prompts in the installed PrimalDesk Admin application to authorize the machine in your browser and select an available subscription or the offered free mode. No screenshot of that provisional registration flow is included here, because its layout and wording are not stable. Closing it before completion should resume setup on the next launch.

Connect the host to your account

Use the same PrimalDesk identity in the browser and administrator flow. Complete the one-time device authorization shown by the host. The owner then sees the machine in the account; someone else’s host appears only after the owner grants access. A short code used for host enrollment is not the same as a device GUID used to save access to another person’s host.

The host must keep its connection to PrimalDesk’s servers after enrollment. That connection is used for license checks, remote configuration, active-session administration and security. It carries current access decisions and short-lived authorization; disconnecting the host from the service is not an offline mode. Keep account credentials and Windows administrator credentials separate.

Configure and verify

Open PrimalDesk Admin on the host to check service health, drivers, backend presence and sessions. The local configuration editor offers a property table and a JSON view. Review connection limits, display limits, GPU preference and sign-out behavior before admitting users. A setting saved in the web account is sent to the host through its control connection; changes to listener-related settings can require a host-service restart. Refresh the account view to confirm that the host acknowledged the latest revision.

The current media stack allocates UDP sockets as connections are established. Do not depend on the legacy port field in an older settings screen as a fixed public media port; follow the current firewall guidance instead.

Check the Windows Firewall rule for the host executable and any organization firewall in front of it. Then connect once from a second device, first on a trusted network and later from the real remote network. A service marked Running confirms local health, not external reachability.

Day-to-day operation

• Owners manage memberships, invitations and desired host configuration from their account. Review who has access when staff or device assignments change.
• The host administrator can inspect active sessions and disconnect or sign out a session when necessary. Disconnecting is not the same as signing out of Windows; unsaved work may remain in a disconnected session.
• Users open an authorized host from browser Workspace or the Desktop client. Each person should use their own Windows credentials. See Windows sessions for reconnection behavior.
• If a connection feels poor, compare host and local FPS, latency and discarded frames before changing resolution. The network quality guide explains what those readings mean.

Back up user data and test updates on a non-critical machine first. Beta availability, installer behavior and supported features can change; the Windows and GPU requirements on this page are the current deployment baseline, not a promise that every application works unchanged.