The remote access capabilities in Arcus have been utilized by users around the globe with great success, delivering simple, browser-based remote desktop like performance without the need for plugins or tunnels. With that said, connections pass through a complext ecosystem. If you are having trouble with your remote access sessions, the source of the problem could be in one or more these areas:

1. User’s system (e.g. policies, tabs, training, etc.)
2. User’s network connection (e.g. internet connection, VPN)
3. DoD network operations
4. Program infrastructure (e.g. RDS, servers in the cloudspace)
5. Arcus infrastructure
6. Arcus application

We are always collecting data and listening to feedback. When connectivity issues do arise, we will endeavor to assist all users to isolate the problem(s) in any or all of these areas. If we suspect network/NOC performance issues, we need to collect as much data as we can before such an issue can be isolated. We appreciate all users’ willingness to work with us to maintain appropriate service and connectivity to Arcus.

In the areas of items 1 & 2, a user’s system or network, users can consider these more specific areas to investigate:

Can’t Connect

• Stale cache/cookie/connection: Sometimes the browser will attempt to “help” and the cached session information interferes with new connections. This can also happen if your current session expires and you attempt a connection without logging in first. Try refreshing the browser window or attempt a connection in incognito/safe/private mode.
• Pop-up Blocker: As with all software, web browsers update frequently and these updates occasionally block the Arcus remote access window. If you experience a situation where you click a remote access button (RDP, VNC, or SSH) and nothing happens, it is very possible that you need to allow pop-ups for Arcus in your browser.
• Black Screen after SSH: If you enter your SSH credentials then see a black screen (without a disconnection error) you may have entered the wrong username or password. Please close the Remote Access Connection tab, and click the SSH button to try again, and ensure your credentials are correct.
• Receiving a VNC Connection Error but still have SSH access: For Red Hat 7 and CentOS 7, x11vnc may be having trouble connecting to the display. You can try restarted the system. If you are unable to restart the system or the restart doesn’t work, you can login via SSH and manually restart the required services by running the following:
  • Restart GDM systemctl restart gdm
  • Restart VNC systemctl restart x11vnc

Poor Performance &/or Dropped Connections

• Multiple Remote Access Connections: Multiple remote access windows can be opened simultaneously. However, this is limited by your browser’s settings for number of sessions and connections. In order to optimize performance, it is recommended to have no more than three windows open at a time.
• Session Conflict: The deployed operating system may limit the number of simultaneous sessions and/or same-user sessions. Windows will only allow the same user to be logged in once, so the second user kicks off the first. In addition, Windows RDP only supports two simultaneous remote sessions at a time (unless an RDS license has been applied to the VM). If you attempt to connect to a Windows VM with 2 existing RDP sessions, your new session will kick one of them off. The Arcus Deployment Run page has an indicator if there is someone else connected along with the number of active connections and will warn you before connecting. Project managers can disable this warning if desired on the project management page.
• Bandwidth: Limited or restricted bandwith on the user side could affect performance. With that said, this feature is utilized everyday over cell phone hotspots with great success. Please check your network speeds.
• User-side Network Issues: Some proxy configurations can interfere with the remote access traffic. Double check that with your network admin that your web proxy has been properly configured. Alternately, allow traffic to go direct to the specific site. An IPS can also interfere if it is configured to strictly limit traffic types.

Specifically in the area of item 4, program infrastructure, users can investigate:

• Deployed System Size: If the deployed system is underpowered (too few CPUS, too little RAM), it may struggle to provide a useful desktop experience, regardless if it is in the cloud or local. For example, if all the resources are being used to render a complex 3D model, the remote connection may perform poorly and/or drop. Ensure that deployed systems have sufficient CPU & RAM to support your application and a desktop session simultaneously. Users generally find that 2-4 CPU and 4-8 GB RAM works best for simple Windows RDP and Linux VNC desktop sessions. Click here for instructions to adjust RAM or CPU on your deployed system.
• Application Configuration: The configuration of an asset (e.g. firewall, group policy, ACLs) may close or prevent remote access connections. Review the behavior and configuration of all the assets you applied to your system to ensure not conflicts are created.
• Undersized Remote Access Server: As projects grow larger, they may need more resources for their remote access connections. The default for a project typically handles 25-30 simultaneous users without issue. If your team is larger and experiences slowness or disconnects, please submit a support request for larger Remote Access resources. It can be upgraded within an hour.