User Experience (UX) Factors
The UX Factors page provides an insight into the factor and subfactor level experience of the set of users you select in the UX dashboard.
Click any of the Excellent, Fair, or Poor UX category in the UX dashboard to open the UX Factors page. It quantifies the effect of factor and subfactor metrics on the user experience. This page classifies the selected set of users based on their experience concerning the factors - Session Availability, Session Responsiveness, Session Resiliency, and Session Logon Duration. Further, the selected users are also classified based on their experience concerning the subfactors within these factors. This drilldown enables you to identify the actual subfactor responsible for the poor experience of users in your environment.
How to use the User Experience (UX) Factors page?
To drill deeper into the factor metrics affecting the user experience, click the number in any of the Excellent, Fair, or Poor category in the UX dashboard.
Consider the scenario, where all Sites had 5 users with excellent experience, 841 with a fair experience and 25 users with a poor experience during the last month. To understand the reason for 25 users facing a poor user experience, click the number 25 from the User Experience dashboard.
The User Experience (UX) factors screen shows a drilldown of the factors affecting the poor experience of users in all the Sites during the last month.
The left panel displays the selection filters for the User Experience and the factors.
Click the Selected users number to access the Self-Service Search page for the specific set of users.
The sections in the UX factors page classify the selected set of users further based on the factors Session Availability, Session Responsiveness, Session Resiliency, and Session Logon Duration. Expand (click >) each factor section to see the user classification based on experience across the respective subfactors. The factors are sorted based on the number of users with poor factor experience.
The overall user experience classification might not match with the user count at the factor level. And, a poor experience across one or more factors might not necessarily mean an overall poor user experience.
Similarly, the user count at individual subfactor levels might not add up to the user count at the factor level. For example a user with high GPOs might not necessarily have a poor logon experience as the user’s experience with other subfactors might have been excellent.
The classification of users at factor and subfactor levels helps identify and troubleshoot the precise cause of poor overall user experience.
Not Categorized users
Not Categorized classification refers to the count of users whose experience cannot be classified under any of the Excellent, Fair, or Poor categories. This might happen at the factor or subfactor levels when the corresponding measurement is unavailable.
Apart from system errors in obtaining the measurements, a user experience might be not categorized due to the following reasons.
- In case a user fails to establish the session, this user is not categorized with respect to all factors except Session Availability.
- Session Responsiveness subfactor measurements are available only when the user connects through a Citrix Gateway version 12.1 or later, configured with Citrix Analytics for Performance. For more information, see Configure on-premises Citrix Gateway.
- To specifically understand the reasons for a user’s Session Logon Duration subfactor experience being not categorized, see the Session logon Duration subfactors section.
Session Logon Duration
Session Logon Duration is the time taken to launch a session. It is measured as the period from the time the user connects from the Citrix Workspace app to the time when the app or desktop is ready to use. This section classifies users based on the session logon duration readings. The logon duration thresholds for classification of the experience as Excellent, Fair, or Poor are calculated dynamically. For more information on the Dynamic thresholds for Session Logon Duration, see the Dynamic Thresholds section.
Clicking the classified user count numbers lead to the Self-Service screen displaying the actual performance factor measurements for the selected set of users.
Session Logon Duration is broken down into subfactors that represent individual phases in the complex launch sequence. Each row in the Session Logon Duration drilldown table represents the user categorization for the individual phases occurring during session launch. This helps troubleshoot and identify specific user logon issues.
The user counts for Excellent, Fair, and Poor category related to each subfactor experience are displayed. Use this information to analyze specific subfactor phases that might be contributing to longer logon duration.
For example, if GPOs show the highest number of users facing poor experiences, review the GPO policies applicable for these users to help improve logon duration experience.
The last Not Categorized column displays the number of users for whom specific subfactor measurements are not available for the selected time period. Specific reasons are elaborated with individual subfactor descriptions.
Session Logon Duration subfactors
It is the time taken to apply group policy objects during logon. GPOs’ measurement is available only if the Group Policy settings are configured and enabled on the virtual machines.
GPO Insights displays client-side extensions in the environment taking the longest processing time during the selected time period. To see the insights, click the Possible Reasons link in the Insights column of GPOs in the Session Logon Duration subfactor table. GPO Insights are based on the analysis of user sessions having poor experience in GPO execution.
A client-side extension (CSE) is a dynamic-link library (DLL) that implements the Group Policy on the client machine. CSEs with long processing time increase GPO execution times and optimizing CSE processing improve the overall session logon experience of the user.
Average CSE execution time depends on the number and type of policies applied with it. Use the following pointers to improve the processing time of CSEs.
Folder Redirection: CSE execution time depends on the number of folders redirected and the contents of each folder. The system can have a wait configured that gets applied after every folder redirection. Optimize the number of folders, to achieve lower CSE execution time.
Drive Mapping: Logon scripts can try to map drives to non-existent target servers resulting in a higher execution time. Make sure the server addresses are correct and available.
Review and tune policies associated with CSEs taking the longest processing time as indicated in the GPO insights. Further, consider deleting the ones that are not required.
Profile load is one of the most critical phases of logon duration. It is the time it takes to load a user’s profile, which includes the registry hive (NTUser.dat) and the user files. Optimizing the profile load time can help improve the overall logon duration experience.
Profile load measurement is available only if profile settings are configured for the user on the virtual machine.
Profile Load Insights
The Insights column in the Session Logon Duration subfactor table displays insights into the profile size being the contributing factor to long profile load times.
Clicking the Possible Reasons link in the Insights column of the Profile Load row displays the number of users having a profile size larger than the average profile size of users with excellent and fair profile load experience. Use these insights to recommend users to reduce large files in their profile.
Insights are not displayed if the profile size measurements or the average profile size are not available.
Profile size measurement requires Citrix Profile Management to be installed on the VDAs.
Profile size measurement is supported on VDA versions 1912 and later.
Profile size measurements of users with fair and excellent profile load experience over the past 30 days are used to calculate the average profile size. The insights are not derived if no data points are available for this duration.
Profile load insights are derived only in cases where profile size causes slow profile load. Other reasons for slow profile load might be the presence of many profile files.
The time taken to “hand off” keyboard and mouse control to the user after the user profile has been loaded. It is normally the longest duration of all the phases of the logon process.
The time taken to decide which desktop to assign to the user.
If the session required a machine start, it is the time taken to start the virtual machine. This measurement is not available for non-power managed machines.
The time taken to complete the steps required in setting up the HDX connection from the endpoint to the virtual machine.
The time taken to complete authentication to the remote session.
It is the time taken for the logon scripts to run. This measurement is available only if logon scripts are configured for the session.
Once a session is established, the Session Responsiveness factor measures the screen lag that a user experiences while interacting with an app or desktop. Session Responsiveness is measured using the ICA Round Trip Time (ICA RTT) that represents the time elapsed from when the user pushes down a key until the graphical response is displayed back.
ICA RTT is measured as the sum of traffic delays in the server and endpoint machine networks, and the time taken to launch an application. ICA RTT is an important metric that gives an overview of the actual user experience.
The Session Responsiveness thresholds for classification of the experience as Excellent, Fair, or Poor are calculated dynamically. For more information on the Dynamic thresholds for Session Responsiveness, see the Dynamic Thresholds section.
The Session Responsiveness Drilldown represents the classification of users based on the ICA RTT readings of the sessions. Clicking these numbers drills down to the metrics for that category. The users with excellent Session Responsiveness had highly reactive sessions while the users with poor Session Responsiveness faced lag in their sessions.
While the ICA RTT readings are obtained from the Citrix Virtual Apps and Desktops, the subfactor measurements are obtained from the Citrix Gateway. Hence, the subfactor values are available only when the user is connecting to an app or a desktop via a configured Citrix Gateway. For steps to configure Citrix Gateway with Citrix Analytics for Performance, see Configure on-premises Citrix Gateway.
Further, these measurements are available for sessions,
- launched from VDAs enabled for NSAP
- new CGP (Common Gateway Protocol) sessions, and not reconnected sessions.
The rows in the Session Responsiveness drilldown table represent the user categorization in the subfactor measurements. For each subfactor, the number of users in each category is displayed in the Excellent, Fair, and Poor columns. This information helps analyze the specific subfactor that is contributing to poor user experience.
For example, the highest number of Poor Users recorded for Data Center Latency indicates an issue with the server-side network.
The last Not Categorized column displays the number of users for whom the specific subfactor measurement was not available during the selected time period.
Session Responsiveness subfactors
The following subfactors contribute to the Session Responsiveness. However, the total ICA RTT is not a sum of the subfactor metrics, as the subfactors of ICA RTT that occur until Layer 4 only are measurable.
Data Center Latency: This subfactor is the latency measured from the Citrix Gateway to the server. A high Data Center Latency indicates delays due to a slow server network.
WAN Latency: This subfactor is the latency measured from the virtual machine to the Gateway. A high WAN Latency indicates sluggishness in the endpoint machine network. WAN latency increases when the user is geographically farther from the Gateway.
Host Latency: This subfactor measures the Server OS induced delay. A high ICA RTT with low Data Center and WAN latencies, and a high Host Latency indicates an application error on the host server.
A high number of users facing poor experience in any of the subfactors helps understand where the issue lies. You can further troubleshoot the issue using Layer 4 delay measurements. None of these latency metrics account for packet loss, out of order packets, duplicate acknowledgments, or retransmissions. Latency might increase in these cases.
Session Availability is calculated based on the failure rate. It is the rate of failed session connections with respect to the total number of attempted session connections.
The Session Availability experience is categorized based on the session failure rate as follows:
Excellent: Failure rate is less than 10%. An excellent Session Availability factor indicates the users being able to successfully connect to and use the app or desktop.
Fair: Failure rate is 10–20%.
Poor: Failure rate is more than 20%. Many users with poor Session Availability experience indicate inability to connect and use sessions.
Since failure to launch sessions disrupts user productivity, it is an important factor in quantifying the overall user experience.
The rows in the Session Reliability drilldown table display the failure types categorized with the number of users and the number of failures in each category. Use the listed Failure types to further troubleshoot the failures.
For more information about the possible reasons within an identified failure type, see the Failure Reasons Troubleshooting document.
Session Resiliency indicates the number of times the Citrix Workspace app auto reconnected to recover from network disruptions. Auto reconnect keeps sessions active when network connectivity is interrupted. Users continue to see the application they are using until network connectivity resumes. An excellent Session Resiliency factor indicates a smooth user experience and lesser number of reconnects due to network disruptions.
Auto reconnect is enabled when the Session Reliability or the Auto Client Reconnect policies are in effect. When there is a network interruption on the endpoint, the following Auto reconnect policies come into effect:
- Session Reliability policy comes into effect (by default in 3 minutes) where the Citrix Workspace app tries to connect to the VDA.
- Auto Client Reconnect policy comes into effect between 3 and 5 minutes where the endpoint machine tries to connect to the VDA.
For each user, the number of auto reconnects are measured during every 15 min interval across the selected time period. Based on the number of auto reconnects in most of the 15 min intervals, the experience is classified as Excellent, Fair, or Poor.
The Session Resiliency experience is categorized based on the reconnect rate as follows:
Excellent: In most of the 15 min intervals in the chosen time period, there were no reconnects.
Fair: In most of the 15 min intervals in the chosen time period, there was one reconnect.
Poor: In most of the 15 min intervals in the chosen time period, there were more than 1 reconnects.