Summary
To receive 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.
The host session health check is compatible with HP Anyware Standard Agent and the HP Anyware Graphic Agent. Sequence diagrams that provide details on the message exchanged are described here.
Host Session Diagnostics Summary
Host Session Diagnostics Details
Initiate session ("Hello" and "Hello-resp")
Shows when a session establishment is initiated. The diagnostic returns:
Pass: |
Host has accepted a session initialization request. |
Data Collected:
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "Hello" message being sent out. See log pattern (a)
Time Period:
- The diagnostic starts time and end time is associated with Step 1.
Example (a) Hello Message
LVL:2 RC: 0 AGENT : Received hello command!
Session authentication ("authenticate" and "authenticate-resp")
Shows the results of the host session authentication phase. The diagnostic returns:
Pass: |
Host was able to successfully authenticate the user on the host |
Fail: |
Host was unable to successfully authenticate the user on the host |
Data Collected:
Received authenticate-password command. |
Failed to authenticate user |
Corrective Actions (if diagnostic does not pass)
Root Cause |
Remedy |
Authenticate was not successful
- Password and username could not be validated
|
If the authenticate message could not be validated on the host itself. Either the password and username were typed in incorrectly or the Active Directory system is not configured for the username/password combination.
- Ensure the username, password and domain name is correct.
- Ensure the AD info does contain the user information.
|
|
Authenticate response timed out
- Unable to communicate with the AD
|
The authentication systems are not setup correctly, or the authentication check took to long to complete.
- Ensure the user information is part of the AD domain identified in the test results.
- Ensure that the user information can be accessed in less than 2 seconds.
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "Authenticate" message being received by the host. See log pattern (a).
- Step 2: Find the "Authenticate" message being processed by the host. See log pattern that shows success (b) or failure (c)
- 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.
If the authenticate steps fails, then 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 username, password and domain name is correct.
- Ensure the user information is part of the AD domain identified in the test results.
Example (a) Authenticate Message received.
LVL:2 RC: 0 AGENT : Received authenticate-password command
Example (b) Authenticate Message processed.
LVL:2 RC: 0 AGENT : Received allocate-resource command.
Example (c) authenticate Message did not succeed
LVL:1 RC:-500 AGENT :Failed to get SID for user t*****1
LVL:1 RC:1326 AGENT :LogonUser failed: username: t*****1, domain: t*****a
LVL:2 RC: 0 AGENT :Failed to authenticate user 't*****1' with domain 't*****a'
Resource Allocation
Shows if the session that is being requested is a brokered connection or a direct connection. The diagnostic returns:
Pass: |
Session is proceeding |
Fail: |
Allocate-resource was not received. |
Data Collected:
Received get-resource-list command; Received allocate-resource command. |
Corrective Actions (if diagnostic does not pass)
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "get-resource-list" message. See log pattern (a).
- Step 2: Find the "Allocate-Resource" message. See log pattern (a)
- If both step1 and 2 find the expected message then it is a "direct connect" session.
- If the get-resource-list is not found but an allocate-response message is found, then it is a "brokered" session.
- If a get-resource-list is found and a allocate-response message is not found, then the diagnostic should be marked as a Failed.
- 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.
If the authenticate steps fails, then 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 username, password and domain name is correct.
- Ensure the user information is part of the AD domain identified in the test results.
Example (a) get-resource-list Message
LVL:2 RC: 0 AGENT : Received get-resource-list command.
Example (b) allocate-resource command Message
LVL:2 RC: 0 AGENT : Received allocate-resource command.
Prepare Host ("Allocate-resource" followed by a Starting PCoIP session indications)
Shows if the host is prepared to accept the connection. The diagnostic returns:
Pass: |
Host is finished preparing for the connection. |
Fail: |
Host is not ready for the connection. |
Data Collected:
Received get-resource-list command; Starting PCoIP session. |
Corrective Actions (if diagnostic does not pass)
Root Cause |
Remedy |
Host is not ready for the connection. |
TBD
|
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "Allocate-Resource" message. See log pattern (a)
- Step 2: Find the "PCoIP Session Started" message. See log pattern (b)
- 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.
Example (a) allocate-resource command Message
LVL:2 RC: 0 AGENT : Received allocate-resource command.
Example (b) allocate-resource response Message
LVL:2 RC: 0 AGENT : Starting PCoIP session.
Checkout license ("checkout-license", "checkout-license-resp")
Shows if a license was successfully acquired for the session. The diagnostic returns:
Pass: |
License acquired. |
Fail: |
License not acquired. |
Corrective Actions (if diagnostic does not pass)
Root Cause |
Remedy |
Licensing has not been configured
Could not launch a remote
session because there are no configured license servers
|
The agent can be configured to use either Cloud Licensing or a local License server.
If you are using Cloud licensing, the each agent needs to be registered once the agent has been installed.
If you are using a local license server, then the Connection Manager needs to be configured to point each agent at the license server
|
|
|
No available licenses
Could not launch a remote session
because no software licenses are available on your cloud license server (https://teradici.compliance.flexnetoperations.com/
instances/XXXXXXXXXXXX/request)
|
The system was able to communicate with the license server however no licenses were found. Verify that you have installed enough licenses to meet your ongoing need. See here for an article on how to determine if you have enough licenses licenses.
|
|
Implementation Details:
Category:
This diagnostic is checked at session phase.
Implementation Steps:
- Step 1: Find the "license acquired" message. See log pattern (a) or (b)
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 1.
Example (a) of a successful license acquisition when using the Cloud licensing service.
The XXXXXXXXX will be your license server id that is located in the cloud. The log events are found the pcoip_agent log:
LVL:2 RC: 0 AGENT :License acquired; source: https://teradici.compliance.flexnetoperations.com/instances/XXXXXXXXXX/request; time: 2.88 s; origin: registration; remaining: 165 days;
Example (b) of a successful license acquisition when using a local license server.
The log events are found the pcoip_agent log:
LVL:2 RC: 0 AGENT :License acquired; source: http://192.168.0.23:7070/request; time: 0.70 s; origin: local-settings; remaining: 290 days;
Example (c) of a unsuccessful license acquisition when licensing not configured.
The log events are found the pcoip_agent log:
The log events are found the pcoip_agent log:
LVL:2 RC: 0 AGENT :Could not launch a remote session because there are no configured license servers
LVL:2 RC: 0 AGENT :License denied
Example (d) error logs
: Powershell command stderr: Cloud License Server: fail, no licenses were available from 'https://teradici.compliance.flexnetoperations.com/instances/XXXXXXXXXX/request';
No license available.;
Example (e) if licensing is configured to use either Cloud or Local Licenses but no licenses are found.
The entry will be found in the control panel log.
: Powershell command stderr: Cloud License Server: fail, no licenses were available from 'https://teradici.compliance.flexnetoperations.com/instances/XXXXXXXXXX/request';
No license available.;
Accept Payload
Shows the result of the client/host establishing the TCP/UDP connection over port 4172. The diagnostic returns:
Pass: |
Client/Host were able to communicate over port 4172 on both UDP and TCP |
Fail: |
Client/Host were not able to communicate over port 4172 on both UDP and TCP |
Corrective Actions (if diagnostic does not pass)
Root Cause |
Remedy |
Port 4172 is blocked |
If the session could not be established. Port 4172 is blocked for either UDP or TCP traffic. The traffic may be blocked on host or client or more likely due to a a firewall setting on your network.
|
|
Implementation Details:
Category:
This diagnostic is checked at session phase.
Implementation Steps:
- Step 1: Find "start session" item. See log pattern (a)
- Step 2: Find the TCP message. See log pattern (b)
- Step 3: Find the UDP message. See log pattern (c)
- Timeout: Step 3 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 3.
Example (a) Item to look for to start the accept Payload diagnostic.
LVL:2 RC: 0 AGENT :Starting PCoIP session.
Example (b) TCP-Handshake response received
LVL:2 RC: 0 SCNET :(scnet_open_accepted_socket): Server accepting connection from 10.12.34.151:54039.
LVL:2 RC: 0 SCNET :(scnet_open_accepted_socket): Server connecting on address 10.0.158.40:4172.
Example (c) UDP-Invite responses received
LVL:1 RC: 0 AGENT :transition from CONNECTING --(CONNECTION_COMPLETE [102])--> CONNECTED
Disconnect session
Shows when and why a host 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 |
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)
Time Period:
- The diagnostic starts time and end time is associated with the log found in Step 1.
When a PCoIP session disconnects, it is logged so that any spontaneous disconnects can be addressed and fixed. The diagnostic will provide a note on how to analyze the disconnection cause
Example (a) Disconnect Message (Host)
LVL:2 RC: 0 TBD