Summary
To receive a detailed client diagnostic report, create a client support/log file bundle and then submit this bundle to the PCoIP health check tool. Once the files are submitted, it will take 5-10 minutes to produce a detailed report. The report will be sent to your registered e-mail address.
Client session health check are available for Zero Clients and PCoIP Software Clients (Mac, Windows and Linux).
Client Session Diagnostics Summary
Phase | Diagnostic | | Pre-Session | | Shows: - if the broker & connection manager hosts are trusted
- the time that the client starts to initiate a session
- the results of the user authentication validation
- the list of hosts that the client can connect to
- the host name that was selected for connection
- the time that the pre-session setup is complete
- the results after session initiation
- the tablet information
- the display configuration issue details
|
|
Session | | Shows: - the time that the PCoIP session was established with host
- if the remote host is trusted
- the time and reason for a session disconnect
|
|
Diagnostic Details
Shows the status of your client certificate check with the Broker or Connection Manager. Diagnostic returns:
Pass: | Certificate presented to the client was verified and is trusted |
Warning: | Certificate presented to the client failed the verification step. The CM/Broker is not trusted |
Fail: | Certificate was not presented to the client. |
Data Collected:
BROKER : verify_server_pbp result is PASSED BROKER : verify_server_pbp result is FAILED_BUT_WARNABLE |
Root Cause | Remedy | Root Certificate Authority (CA) is not installed on the client | Install your Root Certificate Authority (mandatory) and the Intermediate Certificate Authority (optional) certificates on the PCoIP client that will be used to verify the identity of the connection manager and broker. The Certificate Authorities` certificates on the client and CM/Broker must match . The administration guide has details on how to set the root certificate on the client (Windows, Linux, MAC). |
|
Certificate presented to the client is not trusted | Review the certificate to ensure that all these fields are set correctly: - Expiry Time: The Certificate MUST have a correct valid Time. The Not Before and Not After requirements MUST be satisfied.
- Key Usage: If an Enhanced Key Usage (EKU) extension has been provided, it MUST include Server Authentication usage.
- RSA Key Length: The length of the RSA public key MUST satisfy the minimum key length requirement. Must be at least 1024 bits or higher.
- Host Name Matches the Certificate Subject: The Broker/CM hostname MUST match the Subject Name (SN) or one of the Subject Alternative Names (SAN) of the certificate. When using an IP address, the client MUST ensure the host IP address is specified in one of the certificate name fields.
The client trusts the certificate presented by the broker/CM only if any one of these conditions are met: - The CA-signed certificate itself exists in the client's certificate store.
- The certificate Issuer is trusted by the client. The client trusts a received certificate/chain if it has been issued, directly or indirectly, by a trusted CA. A trusted CA is an intermediate or a root CA whose certificate has been installed in the client's certificate store.
- If the certificate is self-signed, then the self-signed certificate itself MUST exist in the client's certificate store.
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session time.
Once the first diagnostic is displayed, subsequent matches should only be displayed if the value changes from the previous displayed value.
Implementation Steps:
- Step 1: Find certificate result. See log pattern (a) or (b)
- Timeout: Not Applicable.
Time Period:
- The diagnostic starts time is associated with Step 1. The end time is associated with Step 1.
Example (a) The PcoIP logs will show the following when the client was able to successfully open a secure channel with the remote server/host:
LVL:2 RC: 0 BROKER :Status: Connecting
LVL:2 RC: 0 BROKER :verify_server_pbp result is PASSED, pre=TRUE sys=FALSE hn=TRUE kl=TRUE ocsp=TRUE sscl=FALSE error[1]=0
LVL:2 RC: 0 BROKER :verify_server_pbp result is PASSED, pre=TRUE sys=FALSE hn=TRUE kl=TRUE ocsp=TRUE sscl=FALSE error[0]=0
The PCoIP logs also show the certificate details as provided by the server/host:
LVL:2 RC: 0 CERTIFICATE :(scnet_client_open_ssl): Certificate sent by the Janus server to open the SSL connection:
LVL:2 RC: 0 CERTIFICATE : --> Signature Algorithm: sha256WithRSAEncryption
LVL:2 RC: 0 CERTIFICATE : --> Issuer: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=jt
LVL:2 RC: 0 CERTIFICATE : --> Not Before: May 13 04:30:19 2020 GMT
LVL:2 RC: 0 CERTIFICATE : --> Not After : May 13 04:30:19 2021 GMT
LVL:2 RC: 0 CERTIFICATE : --> Subject: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=*.domain.local
LVL:2 RC: 0 CERTIFICATE : --> Subject Public Key Info:
LVL:2 RC: 0 CERTIFICATE : --> Public Key Algorithm: rsaEncryption
LVL:2 RC: 0 CERTIFICATE : --> RSA Public-Key: (3072 bit)
LVL:2 RC: 0 CERTIFICATE : --> keyid:26:C5:60:A5:CA:C2:E4:8B:AD:22:40:BD:86:8A:59:A0:2E:F8:5E:32
LVL:2 RC: 0 CERTIFICATE : --> CA:TRUE
LVL:2 RC: 0 CERTIFICATE : --> Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
LVL:2 RC: 0 CERTIFICATE : --> email:<a href="mailto:test@mycompany.com" target="_blank" tabindex="-1">test@mycompany.com</a>
LVL:2 RC: 0 SCNET :(scnet_validate_by_thumbprint_hash): thumbprint hash comparison succeeded
LVL:2 RC: 0 SCNET :(scnet_client_open): Connected to 10.0.158.109:4172
Example (b) of the PcoIP logs when the client certificates are unknown or not valid:
LVL:2 RC: 0 BROKER :Status: Connecting
LVL:2 RC: 0 BROKER :Unknown CA detected in chain
LVL:2 RC: 0 BROKER :verify_server_pbp result is FAILED_BUT_WARNABLE, pre=FALSE sys=FALSE hn=TRUE kl=TRUE ocsp=TRUE sscl=FALSE error[0]=29
Shows when a session establishment is initiated. The diagnostic returns:
Pass: | Client initiates a session and successfully receives the expected response. |
Fail: | Client attempts to initiate a session but does not successfully receive a valid response. |
Data Collected:
Session Initialized by <hostname> via <brokername></brokername> </hostname> |
Root Cause | Remedy | Unable to connect to <hostname></hostname> | The client was not able to communicate with the indicated hostname or IP address. To fix, check the following items: | #1 | Did the user enter an incorrect IP or hostname when starting a connection? | | - Retry with a correct IP or hostname
| #2 | When doing a DNS lookup, does the IP address/hostname return a fully qualified domain name? | | - Review your DNS, LDAP and AD systems to ensure that the hostname or IP address can be resolved and is returning the expected fully qualified domain name.
| #3 | Is Port 443 open or is it blocked by the firewall or Anti-virus software? | | | #4 | Is the remote Hostname/IP machine powered down? | | - Power up the remote host and try again.
|
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1 (Start Pattern): Find the "Hello" message being sent out See log pattern (a) or (d) OR if the broker cannot be found. Log pattern (f)
- Step 2 (End Pattern): Find the "Hello" response being received. See log pattern (b) or (e).
- Timeout: Step 2 must be within 3 seconds of Step 1.
- Notes area should capture the name of the client and the name of the broker. See log pattern (a)/(d) and (b)/(e)
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found then the end time should be the same as found in step 1.
Example (a) Hello Message (software client)
LVL:2 RC: 0 BROKER :Sending XML: -------------------------
LVL:2 RC: 0 BROKER :XML: <hello>
LVL:2 RC: 0 BROKER :XML: <client-info>
LVL:2 RC: 0 BROKER :XML: <product-name>Teradici Windows Soft Client</product-name>
LVL:2 RC: 0 BROKER :XML: <product-version>20.10.2</product-version>
LVL:2 RC: 0 BROKER :XML: <platform>PCoIP</platform>
LVL:2 RC: 0 BROKER :XML: <locale>en_US</locale>
LVL:2 RC: 0 BROKER :XML: <hostname>client.example</hostname>
LVL:2 RC: 0 BROKER :XML: <serial-number>xx:xx:xx:xx:xx:xx</serial-number>
LVL:2 RC: 0 BROKER :XML: <device-name>my-client</device-name>
LVL:2 RC: 0 BROKER :XML: <pcoip-unique-id>xx:xx:xx:xx:xx:xx</pcoip-unique-id>
LVL:2 RC: 0 BROKER :XML: </client-info>
LVL:2 RC: 0 BROKER :XML: <caps>
LVL:2 RC: 0 BROKER :XML: <cap>CAP_DISCLAIMER_AUTHENTICATION</cap>
LVL:2 RC: 0 BROKER :XML: <cap>CAP_NO_AUTHENTICATION</cap>
LVL:2 RC: 0 BROKER :XML: <cap>CAP_DIALOG_AUTHENTICATION</cap>
LVL:2 RC: 0 BROKER :XML: <cap>CAP_ALTERNATE_PROVISIONING</cap>
LVL:2 RC: 0 BROKER :XML: </caps>
LVL:2 RC: 0 BROKER :XML: <server-address>
LVL:2 RC: 0 BROKER :XML: <ip-address>xx.xx.xx.xx</ip-address>
LVL:2 RC: 0 BROKER :XML: <hostname>my-client</hostname>
LVL:2 RC: 0 BROKER :XML: </server-address>
LVL:2 RC: 0 BROKER :XML: </hello>
Example (b) Hello Response (software client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------
LVL:2 RC: 0 BROKER :XML: <hello-resp>
LVL:2 RC: 0 BROKER :XML: <brokers-info>
LVL:2 RC: 0 BROKER :XML: <broker-info>
LVL:2 RC: 0 BROKER :XML: <product-name>"PCoIP Broker"</product-name>
LVL:2 RC: 0 BROKER :XML: <product-version>v30.844.0.2.8a7338d97b</product-version>
LVL:2 RC: 0 BROKER :XML: <platform>"Ubuntu 18.04 LTS";</platform>
LVL:2 RC: 0 BROKER :XML: <locale>en_US</locale>
LVL:2 RC: 0 BROKER :XML: <ip-address>CHANGE_ME</ip-address>
LVL:2 RC: 0 BROKER :XML: <hostname>Broker.example;</hostname>
LVL:2 RC: 0 BROKER :XML: </broker-info>
LVL:2 RC: 0 BROKER :XML: </brokers-info>
LVL:2 RC: 0 BROKER :XML: <pcm-info>
LVL:2 RC: 0 BROKER :XML: <product-name>PCoIP Connection Manager</product-name>
LVL:2 RC: 0 BROKER :XML: <product-version>UNKNOWN</product-version>
LVL:2 RC: 0 BROKER :XML: <platform>GNU/Linux x86_64</platform>
LVL:2 RC: 0 BROKER :XML: <ip-address>xx.xx.xx.xx</ip-address>
LVL:2 RC: 0 BROKER :XML: <hostname>>cm1.example</hostname>
LVL:2 RC: 0 BROKER :XML: </hostname></pcm-info>
LVL:2 RC: 0 BROKER :XML: <next-authentication>
LVL:2 RC: 0 BROKER :XML: <authentication-methods>
LVL:2 RC: 0 BROKER :XML: <method>AUTHENTICATE_VIA_PASSWORD</method>
LVL:2 RC: 0 BROKER :XML: </authentication-methods>
LVL:2 RC: 0 BROKER :XML: <domains>
LVL:2 RC: 0 BROKER :XML: <domain>test.domain</domain>
LVL:2 RC: 0 BROKER :XML: </domains>
LVL:2 RC: 0 BROKER :XML: </next-authentication>
LVL:2 RC: 0 BROKER :XML: </hello-resp>
Example (d) Hello Message (Zero Client)
LVL:2 RC: 0 MGMT_PCBCSI:build_hello_request: Organization ID string is empty!
Example (e) Hello Response (Zero Client)
LVL:2 RC: 0 MGMT_PCB:Expected hostname: 20.72.244.135
Example (f) Hello Error Response (Zero Client)
LVL:1 RC:-500 MGMT_PCBCSI:tera_socket_client_connect failed with addr=20.72.244.135:443!
LVL:1 RC: 260 MGMT_PCBCSI:socket error on connect: Operation timed out!
LVL:1 RC:-500 MGMT_SSL:tera_mgmt_ssl_close_connection: session_id(3) has no connections!
LVL:1 RC:-500 MGMT_PCBCSI:tera_mgmt_ssl_close_connection failed (ssl_session_id: 3)
LVL:1 RC:-500 MGMT_SSL:tera_mgmt_ssl_close_connection: session_id(3) has no connections!
Example (g) Broker Error Response (software client)
LVL:2 RC: 0 QUERYBROKER :No PCoIP broker found on port 443, retrying on port 60443.
Shows the results of the session authentication phase. If MFA is enabled, The diagnostic returns:
Pass: | Client user successfully authenticated. |
Warning: | Client user tried to authenticate but was denied. |
Fail: | Client user tried to authenticate but did not receive a response. |
Data Collected:
User authenticated successfully. |
Root Cause | Remedy | Authentication was not successful - User authentication failed. Please re-enter username, password, and/or domain.
| Authentication will fail if one of the following items is incorrectly entered: - Username must match to what is found in the AD/LDAP user database. On Windows and Linux, the username will not be case sensitive. On MAC the username is case sensitive.
- Password must also match. Passwords are case sensitive.
- Domain must also be incorrect. Domains are not case sensitive.
Most authentication issues are solved by having the user retype the username/password and domain. |
|
MFA authentication was not successful - MFA authentication failed.
| |
|
Authenticate Response timed out Unable to communicate with host | The authentication systems are not setup correctly, or the authentication check took to long to complete on either the connection manager or the remote host. - Ensure the user information is part of the AD domain identified in the test results.
- The authentication configuration is performed by the connection manager or if using the HP Anyware Service, then it is the HP Anyware Connector that performs this function.
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1 (start Pattern): Find the "Authenticate" message being sent out. See log pattern (a) or (d)
- Step 2 (end Pattern) : Find the "Authenticate" response being received. See log patten (b) or (e).
- Timeout: Step 2 must be within 5 seconds of Step 1.
- Notes area should show the result string of the Authentication step. See log pattern (b)/(e)
- Notes area should also show if "MFA" was used. See log pattern (f) or (g). If found, add text to the notes to indicate MFA is enabled.
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) Authenticate Message (Soft Client)
LVL:2 RC: 0 BROKER :XML: <authenticate method="password">
LVL:2 RC: 0 BROKER :XML: <username> *****</username>
LVL:2 RC: 0 BROKER :XML: <password> *****</password>
LVL:2 RC: 0 BROKER :XML: <domain>test.domain</domain>
LVL:2 RC: 0 BROKER :XML: </authenticate>
Example (b) Authenticate Response Message (Soft Client)
LVL:2 RC: 0 BROKER :XML: <authenticate method="password">
LVL:2 RC: 0 BROKER :XML: <username> *****</username>
LVL:2 RC: 0 BROKER :XML: <password> *****</password>
LVL:2 RC: 0 BROKER :XML: <domain>test.domain</domain>
LVL:2 RC: 0 BROKER :XML: </authenticate>
Example (c) authenticate Error Response (Soft Client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------
LVL:2 RC: 0 BROKER :XML: <pcoip-client version="2.1">
LVL:2 RC: 0 BROKER :XML: <authenticate-resp method="password">
LVL:2 RC: 0 BROKER :XML: <result>
LVL:2 RC: 0 BROKER :XML: <result-id>AUTH_FAILED_UNKNOWN_USERNAME_OR_PASSWORD</result-id>
LVL:2 RC: 0 BROKER :XML: <result-str>User authentication failed. Please re-enter username, password, and/or domain.</result-str>
LVL:2 RC: 0 BROKER :XML: </result>
LVL:2 RC: 0 BROKER :XML: </authenticate-resp>
LVL:2 RC: 0 BROKER :XML: </pcoip-client>
LVL:1 RC:-500 BROKER :Authentication: User authentication failed. Please re-enter username, password, and/or domain..
LVL:2 RC: 0 BROKER :Error: User authentication failed. Please re-enter username, password, and/or domain.
Example (d) Authenticate Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:mgmt_pcb_fsm_transition_next_auth:Transition into OPEN + AUTH_VIA_PASSWORD
Example (e) Authenticate Response Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:NOT_AUTHORIZED.PASSWORD_AUTH: Transition 41 into AUTHORIZED.RESOURCE_QUERY
Example (f) Authenticate error response (Zero Client)
LVL:3 RC: 0 MGMT_PCB:NOT_AUTHORIZED.PASSWORD_AUTH: Transition 44 into OPEN
Example (g) MFA enabled(Soft Client)
Example (h) MFA enabled (Zero Client)
Shows the results of the the client asking for the remote hosts that are configured as possible targets. The diagnostic returns:
Pass: | There are 1 or more hosts that are configured as available for the client. |
Fail: | There are 0 configured possible target host machines available to the client. |
Data Collected:
Resource List was retrieved successfully. | User has not been assigned any remote workstations |
Root Cause | Remedy | User has not been assigned any remote workstations | - If you are using the HP Anyware Manager, make sure the user is assigned to the remote host. See here for details on how to configure.
- If you are using a 3rd party broker, you will need to consult the administration guides for the broker.
- If the clients requested a direct connect session, then the host was unable to process the client request. Do a Session Health check on the requested host to get more information on why the entitlement was rejected. See: Host Session Health Check - Diagnostics and troubleshooting guide
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1 (start pattern): Find the "get-resource-list" message being sent out. See log pattern (a) or (d)
- Step 2 (end pattern): Find the "get-resource-list-resp" response being received. See log pattern (b) or (e).
- Timeout: Step 2 must be within 5 seconds of Step 1.
- Notes area should show the result string in the "get-resource-list-resp" message. See log pattern (b)/(e)
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) get-resource-list Message (Soft Client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------
LVL:2 RC: 0 BROKER :XML: <pcoip-client version="2.1">
LVL:2 RC: 0 BROKER :XML: <authenticate-resp method="password">
LVL:2 RC: 0 BROKER :XML: <result>
LVL:2 RC: 0 BROKER :XML: <result-id>AUTH_FAILED_UNKNOWN_USERNAME_OR_PASSWORD</result-id>
LVL:2 RC: 0 BROKER :XML: <result-str>User authentication failed. Please re-enter username, password, and/or domain.</result-str>
LVL:2 RC: 0 BROKER :XML: </result>
LVL:2 RC: 0 BROKER :XML: </authenticate-resp>
LVL:2 RC: 0 BROKER :XML: </pcoip-client>
LVL:1 RC:-500 BROKER :Authentication: User authentication failed. Please re-enter username, password, and/or domain..
LVL:2 RC: 0 BROKER :Error: User authentication failed. Please re-enter username, password, and/or domain.
Example (b) get-resource-list-resp message (Soft Client)
LVL:2 RC: 0 BROKER :XML: <get-resource-list-resp>
LVL:2 RC: 0 BROKER :XML: <result>
LVL:2 RC: 0 BROKER :XML: <result-id>LIST_SUCCESSFUL</result-id>
LVL:2 RC: 0 BROKER :XML: <result-str>Successfully retrieved the list of resources</result-str>
LVL:2 RC: 0 BROKER :XML: </result>
LVL:2 RC: 0 BROKER :XML: <resource>
LVL:2 RC: 0 BROKER :XML: <resource-name>Desktop_1</resource-name>
LVL:2 RC: 0 BROKER :XML: <resource-id>6043f61ff6cdce5b1437f0e8</resource-id>
LVL:2 RC: 0 BROKER :XML: <resource-type session-type="VDI">DESKTOP</resource-type>
LVL:2 RC: 0 BROKER :XML: <resource-state>UNKNOWN</resource-state>
LVL:2 RC: 0 BROKER :XML: <protocols>
LVL:2 RC: 0 BROKER :XML: <protocol is-default="true">PCOIP</protocol>
LVL:2 RC: 0 BROKER :XML: </protocols>
LVL:2 RC: 0 BROKER :XML: </resource>
LVL:2 RC: 0 BROKER :XML: <resource>
LVL:2 RC: 0 BROKER :XML: <resource-name>Desktop_2</resource-name>
LVL:2 RC: 0 BROKER :XML: <resource-id>6043f60d3837b460dc3c0ed7</resource-id>
LVL:2 RC: 0 BROKER :XML: <resource-type session-type="VDI">DESKTOP</resource-type>
LVL:2 RC: 0 BROKER :XML: <resource-state>UNKNOWN</resource-state>
LVL:2 RC: 0 BROKER :XML: <protocols>
LVL:2 RC: 0 BROKER :XML: <protocol is-default="true">PCOIP</protocol>
LVL:2 RC: 0 BROKER :XML: </protocols>
LVL:2 RC: 0 BROKER :XML: </resource>
LVL:2 RC: 0 BROKER :XML: </get-resource-list-resp>
Example (c) get-resource-list-resp Error Response (Soft Client)
LVL:2 RC: 0 BROKER :XML: <get-resource-list-resp>
LVL:2 RC: 0 BROKER :XML: <result>
LVL:2 RC: 0 BROKER :XML: <b> </b><result-id>LIST_FAILED_NO_ENTITLEMENT</result-id>
LVL:2 RC: 0 BROKER :XML: <result-str>User has not been assigned any remote workstations</result-str>
LVL:2 RC: 0 BROKER :XML: </result>
LVL:2 RC: 0 BROKER :XML: </get-resource-list-resp>
Example (d) get-resource-list Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:Called mgmt_pcb_fsm_transition_get_resource_list
LVL:3 RC: 0 MGMT_PCB:NOT_AUTHORIZED.PASSWORD_AUTH: Transition 41 into AUTHORIZED.RESOURCE_QUERY
Example (e) get-resource-list response Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:AUTHORIZED.RESOURCE_QUERY: Transition 51 into AUTHORIZED.RESOURCE_SELECT
Example (f) get-resource-list-resp Error Response (Zero Client)
LVL:1 RC: 0 MGMT_PCB:Error 21: User has not been assigned any remote workstations
Shows the results of the the client asking for to connect to a specific remote host. The diagnostic returns:
Pass: | Selected host is ready to accept a connection. |
Fail: | Selected host is not ready for a connection. |
Data Collected:
Resource was allocated successfully. Name Name=<hostname> </hostname> |
Root Cause | Remedy | Agent is not licensed - Failed to allocate host XX.XX.XX.XX
- PCoIP Agent has no available licenses to launch the remote session.
| Either the agent is not configured with a proper license or all licenses are in use.
Running the health check on the remote host will provide details on how to fix the licensing issue. The remote host agent has two diagnostics which are useful when dealing with licensing issues: - License Configuration: Show if the agent is properly configured for licensing.
- Checkout license: Shows the results of the agent trying to acquire a license.
To obtain a detailed host diagnostic report, create a host support/log file bundle and then submit this bundle to the PCoIP health check tool. Once the files are submitted, it will take 5-10 minutes to produce a detailed report. The report will be sent to your registered e-mail address. |
|
Agent is not ready - Failed to allocate host XX.XX.XX.XX
- Error 6405: PCoIP Agent failed to launch the remote session.
| The Agent is blocked and is not ready for the connection. This can be caused by - the GPU is not ready on the host
- Windows legal notice is enabled and Single Sign-on (SSO) is enabled.
- Virtual display device is not enabled in the GCP instance.
- Host is powered down.
Running the health check on the remote agent will provide additional details on how to fix this issue. The agent diagnostics to review are: - Display Driver Version: Shows if the GPU is ready and compatible with PCoIP.
- Prepare Host: Shows if the host is ready to accept the connection
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "allocate-resource" message being sent out. See log pattern (a) or (d)
- Step 2: Find the "allocate-resource-resp" response being received. See log patten (b) or (e).
- Timeout: Step 2 must be within 5 seconds of Step 1.
- In the notes area, the result of the response <result-str></result-str> and the <hostname>.</hostname> should be added. See log pattern (b)/(e)
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) allocate-resource Message (Soft Client)
LVL:2 RC: 0 BROKER :XML: <allocate-resource>
LVL:2 RC: 0 BROKER :XML: <resource-id>6043f60d3837b460dc3c0ed7</resource-id>
LVL:2 RC: 0 BROKER :XML: <protocol>PCOIP</protocol>
LVL:2 RC: 0 BROKER :XML: <client-info>
LVL:2 RC: 0 BROKER :XML: <time-zone-windows>Pacific Standard Time</time-zone-windows>
LVL:2 RC: 0 BROKER :XML: <ip-address>10.12.34.151</ip-address>
LVL:2 RC: 0 BROKER :XML: <mac-address>02:f0:1e:43:4d:68</mac-address>
LVL:2 RC: 0 BROKER :XML: </client-info>
LVL:2 RC: 0 BROKER :XML: </allocate-resource>
Example (b) allocate-resource-resp Message (Soft Client)
LVL:2 RC: 0 BROKER :XML: <allocate-resource-resp>
LVL:2 RC: 0 BROKER :XML: <result>
LVL:2 RC: 0 BROKER :XML: <result-id>ALLOC_SUCCESSFUL</result-id>
LVL:2 RC: 0 BROKER :XML: <result-str>Successfully allocated remote workstation</result-str>
LVL:2 RC: 0 BROKER :XML: </result>
LVL:2 RC: 0 BROKER :XML: <target>
LVL:2 RC: 0 BROKER :XML: <ip-address>20.72.244.135</ip-address>
LVL:2 RC: 0 BROKER :XML: <hostname>Desktop_1</hostname>
LVL:2 RC: 0 BROKER :XML: <sni>pcoip-default-sg-sni</sni>
LVL:2 RC: 0 BROKER :XML: <port>4172</port>
LVL:2 RC: 0 BROKER :XML: <session-id>2305843009213693952</session-id>
LVL:2 RC: 0 BROKER :XML: <connect-tag>SCS1*****o9+xsC22iJ0A</connect-tag>
LVL:2 RC: 0 BROKER :XML: </target>
LVL:2 RC: 0 BROKER :XML: <resource-id>6043f60d3837b460dc3c0ed7</resource-id>
LVL:2 RC: 0 BROKER :XML: <protocol>PCOIP</protocol>
LVL:2 RC: 0 BROKER :XML: </allocate-resource-resp>
Example (c) allocate-resource-resp Error Response (Soft Client)
LVL:2 RC: 0 BROKER :XML: <allocate-resource-resp>
LVL:2 RC: 0 BROKER :XML: <result>
LVL:2 RC: 0 BROKER :XML: <result-id>ALLOC_PENDING_TRY_AGAIN</result-id>
LVL:2 RC: 0 BROKER :XML: <result-str>Remote workstation swin-0 is starting, Please try to connect again in a few minutes</result-str>
LVL:2 RC: 0 BROKER :XML: </result>
LVL:2 RC: 0 BROKER :XML: </allocate-resource-resp>
Example (d) allocate-resource Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:AUTHORIZED.RESOURCE_QUERY: Transition 51 into AUTHORIZED.RESOURCE_SELECT
Example (e) allocate-resource response Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:AUTHORIZED.RESOURCE_SELECT: Transition 52 into AUTHORIZED.START_SESSION
Shows the results of the the client completing the pre-session phase. The diagnostic returns:
Pass: | Session setup was completed |
Data Collected:
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "bye" message being sent out. See log pattern (a) or (c)
- Step 2: Find the "bye-resp" response being received. See log patten (b) or (d).
- Timeout: Step 2 must be within 5 seconds of Step 1.
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) Bye message (Soft Client)
LVL:2 RC: 0 BROKER :XML: <pcoip-client version="2.1">
LVL:2 RC: 0 BROKER :XML: <bye></bye>
LVL:2 RC: 0 BROKER :XML: </pcoip-client>
Example (b) Bye message and bye-resp (Soft Client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------
LVL:2 RC: 0 BROKER :XML: <pcoip-client version="2.1">
LVL:2 RC: 0 BROKER :XML: <bye-resp>>
LVL:2 RC: 0 BROKER :XML: </bye-resp> </pcoip-client>
...
LVL:2 RC: 0 CLIENT :Pre-session processing complete-----------------
Example (c) Bye message and bye-resp (Zero Client)
LVL:3 RC: 0 MGMT_SSIG:Sending BYE APDU to peer
Example (d) Bye message and bye-resp (Zero Client)
LVL:3 RC: 0 MGMT_SSIG:NEGOTIATED: Received BYE_OK, resetting channel
Peripheral Device (Tablet Info) Shows the connected Wacom tablet model name and connection mode.
Pass: | Wacom tablet is connected with supported connection mode |
Note: | Wacom tablet is connected with unsupported connection mode/Partially supported connection mode |
Data Collected:
Wacom tablet model name and connection mode
Corrective Actions (if diagnostic does not pass)
Note:
1 | The Intuos Pro Medium PTH-660 and Intuos Pro Large PTH-860 models are connected in Bridged Mode, while they support Local Termination mode. |
2 | The PCoIP Graphics Agent for macOS does not support any Wacom Tablet models connected in Local Termination mode, except for the Intuos Pro Medium PTH-660 and Intuos Pro Large PTH-860. |
3 | The PCoIP Graphics Agent for macOS does not support Wacom Tablet models connected in Bridged Mode. |
Please find the below link for Wacom Tablet Support models for both Local Termination and Bridged Mode
Reference links: Which PCoIP products support Wacom devices?
Implementation Details
Category:
This diagnostic is checked at Pre-session.
Once the first diagnostic is displayed, subsequent matches should only be displayed if the value changes from the previous displayed value.
Implementation Steps:
Step 1. Look for the Wacom tablet is connected. See log pattern (a) and Pattern (b)
Time Period:
The Time Period for both the start and end of the diagnostic is the time found for step 1.
Example (a): If a Wacom tablet is connected with local Termination supported, logs will contain this line:
2023-06-22T09:57:30.885Z a63d7300-f310-103b-98da-000000000000 LVL:2 RC: 0 MGMT_USB :HoIP supported device detected (Vid: 0x056a, Pid: 0x0357), using HoIP protocol for local termination
Example (b): If a Wacom tablet is connected with Bridged mode supported, logs will contain this line:
2023-06-23T10:50:42.775Z b2ddcc00-f3e1-103b-a18a-000000000000 LVL:2 RC: 0 MGMT_USB :Device detected - HoIP not supported - (Vid: 0x056a, Pid: 0x0357), using URBoIP protocol for local termination
Display configuration
Shows the status after session initiation. Diagnostic returns:
Pass: | Session established successfully |
Fail: | The session failed to establish, displaying the error: "This desktop has no sources available or has timed out. Please try reconnecting to this desktop later." |
Data Collected:
2024-09-24T12:32:15.303Z 91ccf080-5ca0-103d-90ea-000000000000 > LVL:1 RC:-500 IMG_FRONTEND :<FE_ERROR_TRACE> (0x16fe8f000): no video modes found
2024-09-24T12:32:15.303Z 91ccf080-5ca0-103d-90ea-000000000000 > LVL:1 RC:-500 IMG_FRONTEND :Last message repeated 1 time
2024-09-24T12:32:15.303Z 91ccf080-5ca0-103d-90ea-000000000000 > LVL:1 RC:-500 IMG_FRONTEND :<FE_ERROR_TRACE> (0x16fe8f000): invalid rotation
Corrective Actions (if diagnostic does not pass)
Root Cause | Remedy |
The rotated display on the Windows client caused compatibility issues with the connection process. | |
Shows the status of your certificate. Diagnostic returns:
Pass: | Certificate was successfully verified |
Warning: | Certificate was not successfully verified |
Data Collected:
Root Cause | Remedy | Root Certificate Authority (CA) is not installed on the client | Install your Root Certificate Authority (mandatory) and the Intermediate Certificate Authority (optional) certificates on the PCoIP client that will be used to verify the identity of the remote host. The Certificate Authorities' certificates on the client and remote host must match . The administration guide has details on how to set the root certificate on the client (Windows, Linux, MAC). |
|
Certificate presented to the client is not trusted | Review the certificate to ensure that all these fields are set correctly: - Expiry Time: The Certificate MUST have a correct valid Time. The Not Before and Not After requirements MUST be satisfied.
- Key Usage: If an Enhanced Key Usage (EKU) extension has been provided, it MUST include Server Authentication usage.
- RSA Key Length: The length of the RSA public key MUST satisfy the minimum key length requirement. Must be at least 1024 bits or higher.
- Host Name Matches the Certificate Subject: The remote host hostname MUST match the Subject Name (SN) or one of the Subject Alternative Names (SAN) of the certificate. When using an IP address, the client MUST ensure the host IP address is specified in one of the certificate name fields.
The client trusts the certificate presented by the remote host only if any one of these conditions are met: - The CA-signed certificate itself exists in the client's certificate store.
- The certificate Issuer is trusted by the client. The client trusts a received certificate/chain if it has been issued, directly or indirectly, by a trusted CA. A trusted CA is an intermediate or a root CA whose certificate has been installed in the client's certificate store.
- If the certificate is self-signed, then the self-signed certificate itself MUST exist in the client's certificate store.
|
|
Implementation Details:
Category:
This diagnostic is checked at session time.
Once the first diagnostic is displayed, subsequent matches should only be displayed if the value changes from the previous displayed value.
Implementation Steps:
- Step 1: Find certificate result. See log pattern (a) or (b)
- Timeout: Not Applicable.
Time Period:
- The diagnostic starts time is associated with Step 1. The end time is associated with Step 1.
Example (a) The PcoIP logs will show the following when the client was able to successfully open a secure channel with the remote server/host:
LVL:2 RC: 0 SCNET :(scnet_validate_by_thumbprint_hash): thumbprint hash comparison succeeded
The PCoIP logs also show the certificate details as provided by the server/host:
LVL:2 RC: 0 CERTIFICATE :(scnet_client_open_ssl): Certificate sent by the Janus server to open the SSL connection:
LVL:2 RC: 0 CERTIFICATE : --> Signature Algorithm: sha256WithRSAEncryption
LVL:2 RC: 0 CERTIFICATE : --> Issuer: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=jt
LVL:2 RC: 0 CERTIFICATE : --> Not Before: May 13 04:30:19 2020 GMT
LVL:2 RC: 0 CERTIFICATE : --> Not After : May 13 04:30:19 2021 GMT
LVL:2 RC: 0 CERTIFICATE : --> Subject: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=*.domain.local
LVL:2 RC: 0 CERTIFICATE : --> Subject Public Key Info:
LVL:2 RC: 0 CERTIFICATE : --> Public Key Algorithm: rsaEncryption
LVL:2 RC: 0 CERTIFICATE : --> RSA Public-Key: (3072 bit)
LVL:2 RC: 0 CERTIFICATE : --> keyid:26:C5:60:A5:CA:C2:E4:8B:AD:22:40:BD:86:8A:59:A0:2E:F8:5E:32
LVL:2 RC: 0 CERTIFICATE : --> CA:TRUE
LVL:2 RC: 0 CERTIFICATE : --> Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
LVL:2 RC: 0 CERTIFICATE : --> email:<a href="mailto:test@mycompany.com" target="_blank" tabindex="-1">test@mycompany.com</a>
LVL:2 RC: 0 SCNET :(scnet_validate_by_thumbprint_hash): thumbprint hash comparison succeeded
LVL:2 RC: 0 SCNET :(scnet_client_open): Connected to 10.0.158.109:4172
Example (b) of the PcoIP logs when the client certificates are unknown or not valid:
LVL:1 RC:-500 CERTIFICATE :verify_certificate: Certificate 10.0.158.109 fails verification
Shows the results of the the client establishing a PCoIP connection with the host. The diagnostic returns:
Pass: | Selected host has accepted the connection. |
Fail: | Connection could not be established. |
Data Collected:
N/A | Session established successfully to <hostname></hostname> |
Root Cause | >Remedy | Session could not start - UDP Port 4172 is blocked or
- TCP Port 4172 is blocked
| If the remote host reported as ready and then the session could not be established, then it is likely that port 4172 is blocked for either UDP or TCP traffic. The traffic may be blocked due to the host configuration, client configuration or more likely a firewall issue in your network. |
|
Implementation Details:
Category:
This diagnostic is checked at session phase.
Implementation Steps:
- Step 1: Find the message being sent out. See log pattern (a) and (c)
- Step 2: Find the message being acknowledged. See lot pattern (e) and (g)
- Timeout: Step 2 must be within 5 seconds of Step 1.
- Notes should show the hostname of the session that was established (if established)
Time Period:
- The diagnostic starts time is associated with Step 1
- The diagnostic end time is associated with Step 2
Example (a) TCP-Handshake is successful (Soft Client)
LVL:2 RC: 0 CLIENT :Pre-session processing complete-----------------------------------
LVL:2 RC: 0 CLIENT :In-session processing begins -------------------------------------
Example (b) TCP Error Response (Soft Client)
LVL:2 RC:-500 SCNET :(scnet_client_open_ssl): tera_sock_connect failed to connect to 10.0.158.122:4172!
LVL:2 RC:-500 SCNET :(scnet_client_open_ssl): tera_sock_connect returned error 10060 - Connection timed out!
LVL:1 RC:-500 SCNET :(scnet_client_open): Failed to connect to 10.0.158.122:4172
LVL:1 RC:-500 MGMT_SCHAN :SCDAT: master_ready(): Failed scnet_client_open
Example (c) TCP-Handshake Successful (Zero Client)
LVL:3 RC: 0 MGMT_PCBCSI:create_socket_tcp succeeded
Example (d) Error Response (Zero Client)
LVL:2 RC: 0 MGMT_SSIG:Session timeout (192.168.1.95)!
LVL:1 RC: 260 MGMT_SCHAN:SCNET: master_ready(): Failed tera_socket_client_connect, will retry...
Example (e) UDP-Invite (Soft Client)
2021-02-17T23:18:40.589Z 5c40cd00-53a4-1039-a9e8-000000000000 LVL:0 RC: 0 MGMT_SYS:Session Port found as '4172'
2021-02-17T23:18:40.589Z 5c40cd00-53a4-1039-a9e8-000000000000 LVL:0 RC: 0 MGMT_SYS:Session Addr found as '10.0.158.45'
Example (f) UDP-Invite Response Error (Soft Client)
LVL:1 RC:-504 MGMT_PCOIP_DATA :Invite packet not acknowledged, aborting session
Example (g) UDP-Invite (Zero Client)
LVL:3 RC: 0 MGMT_SSIG:Sending INVITE APDU to peer
LVL:3 RC: 0 MGMT_SSIG:Received INVITE_OK APDU from: 20.72.244.135
LVL:3 RC: 0 MGMT_SSIG:Sending ACK APDU to peer
Example(h) UDP-Invite Response Error (Zero Client)
LVL:3 RC: 0 MGMT_SESS:(pcoip_data_cback): event: 0x4, PRI: 0 - queuing EVENT_PCOIP_DATA_OPEN_TIMEOUT
LVL:2 RC: 0 MGMT_SYS:Session unavailable reason: 0x00001002
When a PCoIP session disconnects, it is logged so that any spontaneous disconnects can be addressed and fixed.
Shows when and why a client disconnects from a PCoIP session. The note provided will explain how to interpret the disconnect cause.
Note: | Disconnection are normal events that are usually initiated by the user of the client. Disconnects can happen due to the user requesting a disconnect or due to a remote host powering down or the network disconnecting. This diagnostic will provide a reason code. To read more about different disconnect causes, refer to Meaning of disconnect causes |
>Root Cause | >Remedy | Session Disconnected | Disconnects can happen due to the user requesting a disconnect or due to a remote host powering down or the network disconnecting. This diagnostic code will be in the notes area. Detail on each disconnect code can be found in the following KB: Meaning of disconnect causes. |
|
Data Collected:
Implementation Details:
Category:
This diagnostic is checked during the session phase.
Implementation Steps:
- Step 1: Find the disconnect message. See log pattern (a) or (b)
- Step 2: If (a) or (b) cannot be found, then find the time when the session ID is no longer being used.
Time Period:
- The diagnostic starts time and end time is associated with the log found in Step 1 or the log associated with Step 2.
Example (a) Disconnect Message (Soft Client)
LVL:2 RC: 0 COMMON :TERA_PCOIP: SESSION_EVENT=TERA_MGMT_SYS_SESS_EVENT_RESET, disconnect cause: 768
Example (b) Disconnect message (Zero Client)