Client Session Health Check - Diagnostics and troubleshooting guide

Rate this Article
Average: 3 (3 votes)

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 


Broker Certificate
Initiate session
Session authentication
Get a list of hosts
Is host ready?
Pre-session Completed

Tablet Info
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
Session 
Establish payload
Host Certificate
Disconnect 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

Broker Certificate Validation

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

 

Corrective Actions (if diagnostic does not pass)

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 (WindowsLinux, 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:test@mycompany.com
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

 

Session Initialization ("Hello" and  "Hello-resp")

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 via

Corrective Actions (if diagnostic does not pass)

Root Cause Remedy

Unable to connect
to .


 

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:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       Teradici Windows Soft Client
LVL:2 RC:   0          BROKER :XML:       20.10.2
LVL:2 RC:   0          BROKER :XML:       PCoIP
LVL:2 RC:   0          BROKER :XML:       en_US
LVL:2 RC:   0          BROKER :XML:       client.example
LVL:2 RC:   0          BROKER :XML:       xx:xx:xx:xx:xx:xx
LVL:2 RC:   0          BROKER :XML:       my-client
LVL:2 RC:   0          BROKER :XML:       xx:xx:xx:xx:xx:xx
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       CAP_DISCLAIMER_AUTHENTICATION
LVL:2 RC:   0          BROKER :XML:       CAP_NO_AUTHENTICATION
LVL:2 RC:   0          BROKER :XML:       CAP_DIALOG_AUTHENTICATION
LVL:2 RC:   0          BROKER :XML:       CAP_ALTERNATE_PROVISIONING
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       xx.xx.xx.xx
LVL:2 RC:   0          BROKER :XML:       my-client
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

Example (b) Hello Response (software client)

LVL:2 RC:   0          BROKER :Received XML: ------------------------
LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:         "PCoIP Broker"
LVL:2 RC:   0          BROKER :XML:         v30.844.0.2.8a7338d97b
LVL:2 RC:   0          BROKER :XML:         "Ubuntu 18.04 LTS";
LVL:2 RC:   0          BROKER :XML:         en_US
LVL:2 RC:   0          BROKER :XML:         CHANGE_ME
LVL:2 RC:   0          BROKER :XML:         Broker.example;
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       PCoIP Connection Manager
LVL:2 RC:   0          BROKER :XML:       UNKNOWN
LVL:2 RC:   0          BROKER :XML:       GNU/Linux x86_64
LVL:2 RC:   0          BROKER :XML:       xx.xx.xx.xx
LVL:2 RC:   0          BROKER :XML:       >cm1.example</hostname>
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:         AUTHENTICATE_VIA_PASSWORD
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:         test.domain
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

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.

 

Session Authentication ("authenticate" and "authenticate-resp")

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.

 

Corrective Actions (if diagnostic does not pass)  

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:

  1. 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.
  2. Password must also match.  Passwords are case sensitive.
  3. 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:   
LVL:2 RC:   0          BROKER :XML:      *****
LVL:2 RC:   0          BROKER :XML:      *****
LVL:2 RC:   0          BROKER :XML:     test.domain
LVL:2 RC:   0          BROKER :XML:   

Example (b) Authenticate Response Message (Soft Client)

LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       AUTH_SUCCESSFUL_AND_COMPLETE
LVL:2 RC:   0          BROKER :XML:       User authenticated successfully.
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

Example (c) authenticate Error Response (Soft Client)

LVL:2 RC:   0          BROKER :Received XML: ------------------------
LVL:2 RC:   0          BROKER :XML: 
LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       AUTH_FAILED_UNKNOWN_USERNAME_OR_PASSWORD
LVL:2 RC:   0          BROKER :XML:       User authentication failed. Please re-enter username, password, and/or domain.
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML: 
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)

LVL:2 RC:   0        TBD

Example (h) MFA enabled (Zero Client)

LVL:2 RC:   0        TBD

Get a list of hosts ("get-resource-list" and "get-resource-resp")

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

Corrective Actions (if diagnostic does not pass)

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 :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       PCOIP
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       DESKTOP
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

Example (b) get-resource-list-resp message (Soft Client)

LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       LIST_SUCCESSFUL
LVL:2 RC:   0          BROKER :XML:       Successfully retrieved the list of resources
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       Desktop_1
LVL:2 RC:   0          BROKER :XML:       6043f61ff6cdce5b1437f0e8
LVL:2 RC:   0          BROKER :XML:       DESKTOP
LVL:2 RC:   0          BROKER :XML:       UNKNOWN
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:         PCOIP
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       Desktop_2
LVL:2 RC:   0          BROKER :XML:       6043f60d3837b460dc3c0ed7
LVL:2 RC:   0          BROKER :XML:       DESKTOP
LVL:2 RC:   0          BROKER :XML:       UNKNOWN
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:         PCOIP
LVL:2 RC:   0          BROKER :XML:       
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

Example (c) get-resource-list-resp Error Response (Soft Client)

LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       LIST_FAILED_NO_ENTITLEMENT
LVL:2 RC:   0          BROKER :XML:       User has not been assigned any remote workstations
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

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

Is host ready? ("allocate-resource" and "allocate-resource-resp")

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= 

Corrective Actions (if diagnostic does not pass)

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:

  1. License Configuration: Show if the agent is properly configured for licensing.
  2. 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:
  1. Display Driver Version: Shows if the GPU is ready and compatible with PCoIP.
  2. 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  and the 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:   
LVL:2 RC:   0          BROKER :XML:     6043f60d3837b460dc3c0ed7
LVL:2 RC:   0          BROKER :XML:     PCOIP
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       Pacific Standard Time
LVL:2 RC:   0          BROKER :XML:       10.12.34.151
LVL:2 RC:   0          BROKER :XML:       02:f0:1e:43:4d:68
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

Example (b) allocate-resource-resp Message (Soft Client)

LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       ALLOC_SUCCESSFUL
LVL:2 RC:   0          BROKER :XML:       Successfully allocated remote workstation
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       20.72.244.135
LVL:2 RC:   0          BROKER :XML:       Desktop_1
LVL:2 RC:   0          BROKER :XML:       pcoip-default-sg-sni
LVL:2 RC:   0          BROKER :XML:       4172
LVL:2 RC:   0          BROKER :XML:       2305843009213693952
LVL:2 RC:   0          BROKER :XML:       SCS1*****o9+xsC22iJ0A
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:     6043f60d3837b460dc3c0ed7
LVL:2 RC:   0          BROKER :XML:     PCOIP
LVL:2 RC:   0          BROKER :XML:   

Example (c) allocate-resource-resp Error Response (Soft Client)

LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:       ALLOC_PENDING_TRY_AGAIN
LVL:2 RC:   0          BROKER :XML:       Remote workstation swin-0 is starting, Please try to connect again in a few minutes
LVL:2 RC:   0          BROKER :XML:     
LVL:2 RC:   0          BROKER :XML:   

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

Pre-Session Completed ("bye" and "bye-resp")

Shows the results of the the client completing the pre-session phase.  The diagnostic returns:

Pass: Session setup was completed   

 

Data Collected:

Pre-session completed

 

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: 
LVL:2 RC:   0          BROKER :XML:   
LVL:2 RC:   0          BROKER :XML: 

Example (b) Bye message and bye-resp (Soft Client)

LVL:2 RC:   0          BROKER :Received XML: ------------------------
LVL:2 RC:   0          BROKER :XML: 
LVL:2 RC:   0          BROKER :XML:   >
LVL:2 RC:   0          BROKER :XML: 
...
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

 

Tablet Info

 

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

 

Host Certificate Validation

Shows the status of your certificate.  Diagnostic returns:

Pass: Certificate was successfully verified
Warning: Certificate was not successfully verified  

 

Data Collected:

TBD

Corrective Actions (if diagnostic does not pass)

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 (WindowsLinux, 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:test@mycompany.com
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


Establish Payload

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

Corrective Actions (if diagnostic does not pass)

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

Disconnect session

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

 

Corrective Actions (if diagnostic does not pass)

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:

disconnect cause: X

 

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)

LVL:2 RC:   0 TBD