Diagnosing Remote Control connection issues

Use this article to identify and resolve issues that prevent a Remote Control session from launching or connecting successfully in VSA 10. This article covers prerequisite failures, SSL/TLS certificate validation errors, peer-to-peer (P2P) connectivity problems, and how to collect diagnostic logs for Kaseya Support.

Problem statement

What: A Remote Control session fails to launch, does not connect, times out, or the remote control window does not appear after selecting a connection method from the Remote Control launchpad.

Where: The issue appears in Modules > Devices > Device List > [device] > Manage > Remote Control in VSA 10. It may affect console sessions, Remote Desktop sessions, or peer-to-peer connections established via the VSA X Agent.

Who: Any VSA 10 technician with the Remote Control > Use IT Glue Passwords or Remote Control > Allow 1-Click access permission attempting to connect to a managed Windows or macOS device.

When: The issue occurs when initiating a remote session from the Device List page, typically when one or more prerequisites on the source or destination machine are not met, or when network conditions prevent the connection from being established.

Why: Remote Control failures most commonly result from one of the following root causes:

  • The Remote Desktop Client application is not installed on the technician's local computer.
  • Remote Control is not enabled on the managed device at the agent or policy level.
  • The managed device is offline or not checking in to the VSA 10 platform.
  • Windows cannot reach the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) endpoints required to validate SSL/TLS certificates, causing the connection to fail or time out.
  • Network conditions — such as symmetric NAT, double NAT, or firewall rules blocking peer-to-peer traffic — prevent a direct P2P connection from being established.
  • The target device is a headless machine with no active virtual monitor, which prevents Remote Desktop takeover.
  • The managed device is hosted on Azure Cloud, which is not a supported environment for Remote Control tools.

Resolution

To resolve Remote Control connection issues, work through the following checks in order.

Check 1: Verify prerequisites on both machines

Before attempting a remote session, confirm that both the source and destination machines meet all requirements.

  1. On your local computer, confirm that the Remote Desktop Client application is installed. If not, navigate to Onboarding > Downloads in VSA 10 and download and install it.
  2. Confirm that the managed device is powered on and actively checking in to your VSA 10 platform. A device that is offline will not accept remote connections.
  3. Confirm that the managed device is not hosted on Azure Cloud. Remote Control tools do not support Azure Cloud-hosted devices.
  4. If the target is a headless Windows device (a physical device with no attached monitor), confirm that an active virtual monitor is present. If none is available, use a third-party video adapter or display emulator to generate a virtual display before attempting a Remote Desktop session.

Check 2: Confirm that Remote Control is enabled on the managed device

Remote Control must be enabled on the managed device before a session can be established. You can enable it at either the policy level or the agent level; policy settings always take precedence.

To enable Remote Control at the policy level:

  1. Create a Remote Desktop Device Configuration profile with Enable Remote Desktop selected. Refer to the Remote Desktop profile documentation for details.
  2. From the left navigation menu, navigate to Configuration > Policies.
  3. Select or create a Device Management policy and assign the Remote Desktop profile to it.
  4. Target the policy against all applicable devices.

To enable Remote Control at the agent level:

  1. On the managed device, launch the VSA X Manager application.
  2. Navigate to System > Remote Control.
  3. Select the Enable Remote Control option.
  4. In the Remote Control Settings section, configure the agent's response to remote control requests.
  5. Click Apply.

Check 3: Resolve SSL/TLS certificate validation failures (Windows devices)

When VSA Remote Control establishes a TLS/SSL connection, Windows validates the certificate chain by contacting CRL and OCSP distribution points. If the managed device cannot reach these endpoints, certificate validation fails and the connection fails or times out.

Confirm that the managed Windows device has outbound HTTP access to all of the following URLs:

  • http://crl.usertrust.com/TrustedSecureCertificateAuthorityDV.crl
  • http://crt.usertrust.com/TrustedSecureCertificateAuthorityDV.crt
  • http://ocsp.usertrust.com

If any of these URLs are blocked by a firewall or proxy, add them to the device's allowlist and attempt the remote session again.

NOTE  These CRL and OCSP checks are performed by Windows itself, not by Kaseya. Contact your network administrator to update firewall or proxy rules as needed.

Check 4: Resolve peer-to-peer connectivity issues

VSA 10 attempts to establish a direct P2P connection during Remote Desktop sessions between Windows machines where network conditions allow. If the P2P connection cannot be established, the session falls back to a relay connection, which may result in higher latency. If sessions are failing entirely, verify that your network meets the following P2P requirements:

  • For on-premises customers: UDP port 443 inbound connectivity to the VSA server is enabled.
  • Both the endpoint and the technician machine have outbound connectivity to the VSA server (on-premises) or Kaseya's cloud infrastructure (cloud customers) on UDP port 443.
  • Neither machine is behind a firewall with application-layer rules blocking P2P traffic.
  • Neither machine is behind a network device configured with symmetric NAT or double NAT.
  • The technician machine's firewall permits all outbound ports, as P2P connections use a temporary random high-numbered ephemeral port as the source port.

To verify the current P2P connection state during an active session, enable Session Health in the Settings menu of the Remote Desktop client. You can also manually disable P2P connectivity from that menu if needed.

Check 5: Collect diagnostic logs and contact Kaseya Support

If the issue persists after completing the checks above, collect diagnostic logs from both the source and destination machines and submit them to Kaseya Support. The log collection process varies depending on the operating systems of both machines.

Before collecting logs, gather the following information:

  • A detailed description of the issue, with screenshots of any errors or unexpected behavior.
  • Steps to reproduce the issue, along with a short screen recording if possible.
  • A screenshot of the Administration > Server Admin > Overview page.
  • The number of managed endpoints affected.
  • Operating system details for both the source and destination devices.
  • The version of the Remote Control application on the source machine.

Then collect logs using the scenario that matches your environment. For detailed steps, refer to Remote Control log files.

Tips and tricks

  • If no browser prompt appears and the remote control window does not open after selecting a connection method, verify that both the managed device and your local computer meet all prerequisites described in Check 1 and Check 2 above before escalating to Support.
  • Use policy-level Remote Desktop profiles rather than agent-level settings when managing Remote Control access across multiple devices. Policy settings always take precedence over individual agent settings and are easier to maintain at scale.
  • During an active session, use Session Health in the Settings menu of the Remote Desktop client to monitor round-trip time (RTT) and confirm whether P2P or relay mode is in use. This helps diagnose latency issues without collecting full diagnostic logs.
  • The Remote Control Client automatically detects and installs updates on first launch. If a session pauses briefly with a message stating that a new update is available, allow the update to complete — the session will continue without interruption once the update is applied.
  • When enabling diagnostic logging to reproduce an issue, enable it only for as long as needed. Extended logging periods can cause performance degradation on the affected devices.