Why am I unable to access my PCoIP-based WorkSpace using the WorkSpaces client?

Short description

The WorkSpaces client depends on special services and network settings. When the client fails to load the WorkSpace, it's typically because a service or setting is incorrectly configured or unavailable.

Resolution

The following information describes common errors, the cause of these errors, and troubleshooting guidance to resolve the errors.

After authentication, the WorkSpaces client is stuck on a WorkSpaces launch screen. After a few seconds, the following error displays: "Unknown error Occurred. We couldn't launch your WorkSpace. Please try again. If you need help, contact your administrator."

This error typically indicates that the WorkSpaces client can authenticate over port 443, but can’t establish a connection over TCP port 4172. This might happen when network prerequisites aren’t met. Issues on the client side might cause the network check for the client to fail. Choose the icon in the top-right corner to see which health checks are failing.

Note: A client-side firewall or proxy might cause a health check failure by preventing access over TCP port 4172. If this health check fails, check your local firewall settings.

If the network checks are passing on the client, then it indicates a problem with the WorkSpace network configuration. For example, a Windows Firewall rule that's applied locally or through a group policy object (GPO), or an antivirus check might block TCP port 4172 on the management interface. Connect to the WorkSpace using the Remote Desktop Protocol (RDP) client to verify that the WorkSpace meets the same port requirements.

After authentication, the WorkSpaces client displays a "Launching Session" screen. The client window expands and displays a white screen before displaying a "Disconnected" message. No other error message appears.

This error typically indicates that the WorkSpaces client can authenticate over port 443, but can’t establish a streaming connection over UDP port 4172. This might happen when network prerequisites aren’t met. Issues on the client side might cause the network check of the client to fail. Choose the icon in the top-right corner to see which health checks are failing.

Note: A client-side firewall or proxy might cause a health check failure by preventing access over UDP port 4172. If this health check fails, check your local firewall settings.

If the network checks are passing on the client, then it indicates a problem with the network configuration on the WorkSpace. For example, a Windows Firewall rule that's applied locally or through a group policy object (GPO), or an antivirus check might block UDP port 4172 on the management interface. Connect to the WorkSpace using an RDP client to verify that the WorkSpace meets the same port requirements.

After authentication, the WorkSpaces client displays a "Launching Session" screen, but after a few seconds, the client displays one of the following error messages.

• Unable to connect. Your WorkSpace is not reachable at the moment. You can try and reconnect anytime.
• Unable to connect. We couldn't launch your WorkSpace. Please try again. If you need help, contact your administrator.
• Unable to login. We couldn't launch your WorkSpace. Please try again. If you need help, contact your administrator.

These errors typically indicate that the SkyLightWorkSpacesConfigService or the PCoIP Standard Agent for Windows services aren’t responding to health checks. If either of these services aren't running, then the status of the WorkSpace on the WorkSpaces console typically displays Unhealthy. Usually, rebooting the WorkSpace from the WorkSpaces console or the WorkSpaces client resolves the issue.

However, sometimes rebooting the WorkSpace doesn't help.

To resolve the issue, check the status of the WorkSpace on the WorkSpaces console. If it shows Rebooting or Starting for a long time and then changes to Unhealthy, then verify the following settings for the SkyLightWorkSpacesConfigService and PCoIP Standard Agent for Windows services:

• They're running.
• They're set to start automatically.
• They can communicate over the management interface (eth0).
• They aren't blocked by any third-party antivirus software.
• The Windows Firewall or group policy settings aren't blocking communication on the management interface.

To verify that the SkyLightWorkSpacesConfigService and PCoIP Standard Agent for Windows services meet the preceding requirements, follow these steps:

1.    Connect to the WorkSpace by using RDP.

2.    Open Windows PowerShell as an administrator by choosing Run as administrator.

3.    Run the following command to enable all network adapters for the WorkSpace:

Get-NetAdapter | Where status -ne Up | Enable-NetAdapter

4.    Run the following command:

Get-Service -Name SkyLightWorkspaceConfigService, PCoIPAgent | Select-Object -Property Name, DisplayName, Status, Starttype

5.    In the output of the preceding command, usually the Status displays Running and StartType displays Automatic. However, if the status displays Stopped, then run the following commands to start the service:

Get-Service -Name SkyLightWorkspaceConfigService | Start-Service
Get-Service -Name PCoIPAgent | Start-Service

6.    If the Status displays Stopped and StartType displays Disabled or Manual, run the following commands to change StartType to Automatic first. Then, start the service:

Get-Service -Name SkyLightWorkspaceConfigService | Set-Service -StartupType Automatic
Get-Service -Name SkyLightWorkspaceConfigService | Start-Service
Get-Service -Name PCoIPAgent | Set-Service -StartupType Automatic
Get-Service -Name PCoIPAgent | Start-Service

For more information about troubleshooting unhealthy WorkSpaces, see How do I troubleshoot a Windows WorkSpace that's marked as unhealthy?

Unable to register. This device is not authorized to access the WorkSpace. Please contact your administrator for assistance.

There are few reasons for this error. Any combination of one, two, or all the causes might result in this error:

• IP access control groups are configured on your WorkSpace directory, but the client IP address isn't on an allow list.
• Trusted device-based access is turned on in the directory, and the certificate is missing on the client device, isn't valid, or isn't meeting security requirements.
• Device access is turned off in the WorkSpaces directory.

Check the settings in your directory. If the IP access control group is turned on, then confirm that the public IP address the user is connecting from allows access to the WorkSpace.

If the trusted device setting is turned on under Access Control Options and displays Valid, then make sure that you have the correct leaf, intermediate (optional), and root certificates installed on the client machine.

Make sure that the client device that you're accessing the WorkSpace from is allowed under Access Control Options. By default, WorkSpaces Web Access and Linux clients are turned off.

Related information

Troubleshoot WorkSpaces issues