Table of contents Identify Remote Display Latency (Troubleshoot Remote Display) The Troubleshoot Remote Display dashboard highlights the delays to performance caused by remote display latency in virtualized environments, showing the delays in different locations or data centers. Use this dashboard to isolate the infrastructure issues which are causing the slowdowns in virtual deployments. The remote display latency is the average time taken for the round trip of a network data packet to travel between the front line user and a virtual server (both ways). Practically, it is the time between performing an action in a virtual session on the front line user's machine, then sending that action to the virtual desktop server (VDI) or virtual application server, and then viewing that action back on the front line terminal again. This does NOT measure the time for the application to respond. Remote display latency is the time in both directions from the front line user to the virtual server For example, if a user types the character 'g' in a text editor which runs on a virtual application server, when the remote session sends this action to the virtual server, the remote display latency is the lag time between typing 'g' to seeing the 'g' on the screen. Note By default, a virtual session only reports data to Aternity while a user is logged in to Windows, and stops when a user logs out. Aternity does not report boot times for virtual sessions. To report data even when a user is not logged in to Windows, select the Gear Icon > Settings > Advanced Settings > agent > configuration > overrideConfigurationParam > Citrix and VDI > SendMeasurementsOnUserNotLoggedOn > value and set it to True. Often high latency can result from the client and server being physically distant, like on different continents. If your users complain about latency performance, consider investing in a physically closer data center or hypervisor. This dashboard supports virtual application servers (like Citrix XenApp), virtual desktop servers (VDI like VMWare vSphere). The Troubleshoot Remote Display dashboard The latency has its own status derived from its own expected time (its baselines). This is separate from the activity response time, which also has its status depending on its own baselines. Note When you view an activity's response time in a VDI deployment, there are two separate times you must add: the regular application's response time on the VDI server itself (made up of the client time, server time and network time) and then add the remote display latency between the VDI server and the front line end user of the virtual desktop. For any given activity response, if we assume that there is only one round trip from the client to the VDI server for the activity and its response (which depends on the architecture of the application deployed in VDI), the total response time of an activity would be: VDI response time = (2 x remote display latency) + activity response time Typically, however, the virtualization platform would use more than one round trip to the virtual application server or VDI server for each activity, so it would be many more than 2 x remote display latency. Effective response time of a VDI end user Aternity monitors performance in a wide range of virtual applications and virtual desktops. The virtual servers must be housed in one of the following operating systems: Attribute Requirement Virtual server operating system Windows Server 2016, 2012 R2, 2012, or 2008 R2. The Windows Agent supports virtual devices and/or virtual applications with any of the following requirements: Attribute Requirement Citrix virtual application servers Citrix XenApp 6.5, 7.6, 7.8, 7.15. Citrix virtual desktop servers Citrix XenDesktop 6.5, 7.6, 7.15. VMWare Enterprise VDI VDI support is for VMWare Horizon View 6.x and 7.x up to 7.2 (certified support for version 6.2). Aternity does not monitor the ESXi hypervisor. VMWare ThinApp is NOT supported. Microsoft RDC Microsoft Remote Desktop Services 6.1, 8.1, 10.0. Microsoft virtual application servers Microsoft App-V 4.6 SP3, 5.0. ProcedureStep 1 Open a browser and sign in to Aternity. Step 2 Access the dashboard by typing its name in the search box in the top bar. Alternatively, access the Remote Display dashboard by selecting first Main Menu > Troubleshoot > Virtual Desktop. Accessing Troubleshoot Virtual Desktop Select the Remote display latency option in the pop-up window. Select to troubleshoot the remote display latency Step 3 See the clients with remote display latency problems which need your attention, their location, and their connected servers or virtual machines. The measurements show the percentage of latency times which have a status of normal, minor, major, sorted by the worst performers. Your goal is to have all the latency measurements as normal. Check where the latency issues in your company are concentrated Field Description Client Locations Check if the client devices with the slowest latency are concentrated in a certain location. Client Devices Check the users and client devices with the longest latency time. Cities Check if the problem impacts users working from a specific location (also collated by Cities, States, Countries, and Regions). You can also view this information on a map in the Geographies section. For example, if performance is poor only for users in the office in North London (a business location), check the networking infrastructure of that specific site. But if the problem affects all the offices in London (under Cities), you can check the wider infrastructure which is common to all those locations, like a data center. Servers/Virtual Desktops Check if the problem occurs for all users who connect to specific servers or virtual machine. Data Center Locations Data Center Locations in Aternity lists the locations of any virtual application servers (like Citrix XenApp) and VDI hypervisors (like in VMWare vSphere) which run the application. If the application is deployed both locally and virtually, one of the locations displays as Local. Latency Displays the average latency time (in seconds) during the timeframe of the dashboard. For further information, you can drill down to: The Activity Resource Analysis dashboard, to see the effects of an activity directly on the resources of the device. The Desktop Reliability dashboard, to view the stability of both client and server devices. The Device Health dashboard, to troubleshoot hardware, system, and application issues. The Monitor User Experience dashboard, to see the recent log of events performed on this device. The SLA dashboard, to view the occurrences when the performance is slower than your service level agreement (SLA) thresholds. The Troubleshoot Boot dashboard, to see the performance of different devices in terms of boot times. Step 4 See when the latency issues started in the Trends section. Change the dashboard's timeframe to extend the graph's time period if required. Hover over the graph to see the exact time of the measurement and the average latency time. Look at the recent statuses of latency over time, to see if it is improving or worsening. See the latency changes over the timeframe of the dashboard Field Description Time Presents the day and hour of the measurement. Score Presents the score for the statuses of all the latency times calculated by condensing all the latency statuses into a single value. Status Presents the score's status. A poor status is a sign you should troubleshoot this connection. To zoom in on the times with the worst latency, select a place of interest on the graph, and view a second graph which opens underneath showing one hour after the time you selected on the upper graph, so you can pinpoint the changes. Zoom on the latency peaks Step 5 Troubleshoot your latency problems by finding the common element where the performance problems are concentrated, by selecting that element and viewing other sections of the dashboard. You can investigate either the virtual servers or the front end clients: To investigate the server side, select the data center location with the slowest latency, and view the servers, devices, and trends concerning that location only, to assess possible correlations. You can then select the server with the slowest latency at that data center and view all the client devices remotely connected to that server. Verify the common attributes between those devices. Then you can drill down on a device for more information on their hardware or software issues. To investigate the front end clients, select the client location with the highest percentage of long latency times and then investigate the users connected from that location and to their servers or data centers. Isolate the view of your dashboard to the longest latency times Step 6 You can limit the display of this dashboard using the menus at the top of the window. Choose to display virtual application servers or virtual desktops, or choose to display specific protocols. Limit the view of the dashboard Field Description Timeframe Choose the start time of the data displayed in this dashboard.You can access data in this dashboard (retention) going back up to seven days. This dashboard's data refreshes every hour. Device Type Select one of the following: Virtual App Servers offer multiple users access to a single instance of an application, for example, with Citrix XenApp. Virtual Desktops offer the ability to run an application within a VDI environment, which is a virtual instance of the entire desktop operating system (usually Windows). Protocol Displays the remote display protocol: ICA, the protocol used by Citrix XenApp. RDP, the protocol used by Microsoft products like Remote Desktop Connection. It is also increasingly being adopted by newer versions of Citrix XenApp. PCoIP, the protocol used by VMWare's VDI systems. Status Select whether to display only the activities which are exceeding SLA thresholds. Select one of the following: Exclude Normal displays only activities which exceed their SLA thresholds. All does not exclude data. Parent topic Key Task: Troubleshoot Virtual Desktop SavePDF Selected topic Selected topic and subtopics All content Related Links
Identify Remote Display Latency (Troubleshoot Remote Display) The Troubleshoot Remote Display dashboard highlights the delays to performance caused by remote display latency in virtualized environments, showing the delays in different locations or data centers. Use this dashboard to isolate the infrastructure issues which are causing the slowdowns in virtual deployments. The remote display latency is the average time taken for the round trip of a network data packet to travel between the front line user and a virtual server (both ways). Practically, it is the time between performing an action in a virtual session on the front line user's machine, then sending that action to the virtual desktop server (VDI) or virtual application server, and then viewing that action back on the front line terminal again. This does NOT measure the time for the application to respond. Remote display latency is the time in both directions from the front line user to the virtual server For example, if a user types the character 'g' in a text editor which runs on a virtual application server, when the remote session sends this action to the virtual server, the remote display latency is the lag time between typing 'g' to seeing the 'g' on the screen. Note By default, a virtual session only reports data to Aternity while a user is logged in to Windows, and stops when a user logs out. Aternity does not report boot times for virtual sessions. To report data even when a user is not logged in to Windows, select the Gear Icon > Settings > Advanced Settings > agent > configuration > overrideConfigurationParam > Citrix and VDI > SendMeasurementsOnUserNotLoggedOn > value and set it to True. Often high latency can result from the client and server being physically distant, like on different continents. If your users complain about latency performance, consider investing in a physically closer data center or hypervisor. This dashboard supports virtual application servers (like Citrix XenApp), virtual desktop servers (VDI like VMWare vSphere). The Troubleshoot Remote Display dashboard The latency has its own status derived from its own expected time (its baselines). This is separate from the activity response time, which also has its status depending on its own baselines. Note When you view an activity's response time in a VDI deployment, there are two separate times you must add: the regular application's response time on the VDI server itself (made up of the client time, server time and network time) and then add the remote display latency between the VDI server and the front line end user of the virtual desktop. For any given activity response, if we assume that there is only one round trip from the client to the VDI server for the activity and its response (which depends on the architecture of the application deployed in VDI), the total response time of an activity would be: VDI response time = (2 x remote display latency) + activity response time Typically, however, the virtualization platform would use more than one round trip to the virtual application server or VDI server for each activity, so it would be many more than 2 x remote display latency. Effective response time of a VDI end user Aternity monitors performance in a wide range of virtual applications and virtual desktops. The virtual servers must be housed in one of the following operating systems: Attribute Requirement Virtual server operating system Windows Server 2016, 2012 R2, 2012, or 2008 R2. The Windows Agent supports virtual devices and/or virtual applications with any of the following requirements: Attribute Requirement Citrix virtual application servers Citrix XenApp 6.5, 7.6, 7.8, 7.15. Citrix virtual desktop servers Citrix XenDesktop 6.5, 7.6, 7.15. VMWare Enterprise VDI VDI support is for VMWare Horizon View 6.x and 7.x up to 7.2 (certified support for version 6.2). Aternity does not monitor the ESXi hypervisor. VMWare ThinApp is NOT supported. Microsoft RDC Microsoft Remote Desktop Services 6.1, 8.1, 10.0. Microsoft virtual application servers Microsoft App-V 4.6 SP3, 5.0. ProcedureStep 1 Open a browser and sign in to Aternity. Step 2 Access the dashboard by typing its name in the search box in the top bar. Alternatively, access the Remote Display dashboard by selecting first Main Menu > Troubleshoot > Virtual Desktop. Accessing Troubleshoot Virtual Desktop Select the Remote display latency option in the pop-up window. Select to troubleshoot the remote display latency Step 3 See the clients with remote display latency problems which need your attention, their location, and their connected servers or virtual machines. The measurements show the percentage of latency times which have a status of normal, minor, major, sorted by the worst performers. Your goal is to have all the latency measurements as normal. Check where the latency issues in your company are concentrated Field Description Client Locations Check if the client devices with the slowest latency are concentrated in a certain location. Client Devices Check the users and client devices with the longest latency time. Cities Check if the problem impacts users working from a specific location (also collated by Cities, States, Countries, and Regions). You can also view this information on a map in the Geographies section. For example, if performance is poor only for users in the office in North London (a business location), check the networking infrastructure of that specific site. But if the problem affects all the offices in London (under Cities), you can check the wider infrastructure which is common to all those locations, like a data center. Servers/Virtual Desktops Check if the problem occurs for all users who connect to specific servers or virtual machine. Data Center Locations Data Center Locations in Aternity lists the locations of any virtual application servers (like Citrix XenApp) and VDI hypervisors (like in VMWare vSphere) which run the application. If the application is deployed both locally and virtually, one of the locations displays as Local. Latency Displays the average latency time (in seconds) during the timeframe of the dashboard. For further information, you can drill down to: The Activity Resource Analysis dashboard, to see the effects of an activity directly on the resources of the device. The Desktop Reliability dashboard, to view the stability of both client and server devices. The Device Health dashboard, to troubleshoot hardware, system, and application issues. The Monitor User Experience dashboard, to see the recent log of events performed on this device. The SLA dashboard, to view the occurrences when the performance is slower than your service level agreement (SLA) thresholds. The Troubleshoot Boot dashboard, to see the performance of different devices in terms of boot times. Step 4 See when the latency issues started in the Trends section. Change the dashboard's timeframe to extend the graph's time period if required. Hover over the graph to see the exact time of the measurement and the average latency time. Look at the recent statuses of latency over time, to see if it is improving or worsening. See the latency changes over the timeframe of the dashboard Field Description Time Presents the day and hour of the measurement. Score Presents the score for the statuses of all the latency times calculated by condensing all the latency statuses into a single value. Status Presents the score's status. A poor status is a sign you should troubleshoot this connection. To zoom in on the times with the worst latency, select a place of interest on the graph, and view a second graph which opens underneath showing one hour after the time you selected on the upper graph, so you can pinpoint the changes. Zoom on the latency peaks Step 5 Troubleshoot your latency problems by finding the common element where the performance problems are concentrated, by selecting that element and viewing other sections of the dashboard. You can investigate either the virtual servers or the front end clients: To investigate the server side, select the data center location with the slowest latency, and view the servers, devices, and trends concerning that location only, to assess possible correlations. You can then select the server with the slowest latency at that data center and view all the client devices remotely connected to that server. Verify the common attributes between those devices. Then you can drill down on a device for more information on their hardware or software issues. To investigate the front end clients, select the client location with the highest percentage of long latency times and then investigate the users connected from that location and to their servers or data centers. Isolate the view of your dashboard to the longest latency times Step 6 You can limit the display of this dashboard using the menus at the top of the window. Choose to display virtual application servers or virtual desktops, or choose to display specific protocols. Limit the view of the dashboard Field Description Timeframe Choose the start time of the data displayed in this dashboard.You can access data in this dashboard (retention) going back up to seven days. This dashboard's data refreshes every hour. Device Type Select one of the following: Virtual App Servers offer multiple users access to a single instance of an application, for example, with Citrix XenApp. Virtual Desktops offer the ability to run an application within a VDI environment, which is a virtual instance of the entire desktop operating system (usually Windows). Protocol Displays the remote display protocol: ICA, the protocol used by Citrix XenApp. RDP, the protocol used by Microsoft products like Remote Desktop Connection. It is also increasingly being adopted by newer versions of Citrix XenApp. PCoIP, the protocol used by VMWare's VDI systems. Status Select whether to display only the activities which are exceeding SLA thresholds. Select one of the following: Exclude Normal displays only activities which exceed their SLA thresholds. All does not exclude data. Parent topic Key Task: Troubleshoot Virtual Desktop
Identify Remote Display Latency (Troubleshoot Remote Display) The Troubleshoot Remote Display dashboard highlights the delays to performance caused by remote display latency in virtualized environments, showing the delays in different locations or data centers. Use this dashboard to isolate the infrastructure issues which are causing the slowdowns in virtual deployments. The remote display latency is the average time taken for the round trip of a network data packet to travel between the front line user and a virtual server (both ways). Practically, it is the time between performing an action in a virtual session on the front line user's machine, then sending that action to the virtual desktop server (VDI) or virtual application server, and then viewing that action back on the front line terminal again. This does NOT measure the time for the application to respond. Remote display latency is the time in both directions from the front line user to the virtual server For example, if a user types the character 'g' in a text editor which runs on a virtual application server, when the remote session sends this action to the virtual server, the remote display latency is the lag time between typing 'g' to seeing the 'g' on the screen. Note By default, a virtual session only reports data to Aternity while a user is logged in to Windows, and stops when a user logs out. Aternity does not report boot times for virtual sessions. To report data even when a user is not logged in to Windows, select the Gear Icon > Settings > Advanced Settings > agent > configuration > overrideConfigurationParam > Citrix and VDI > SendMeasurementsOnUserNotLoggedOn > value and set it to True. Often high latency can result from the client and server being physically distant, like on different continents. If your users complain about latency performance, consider investing in a physically closer data center or hypervisor. This dashboard supports virtual application servers (like Citrix XenApp), virtual desktop servers (VDI like VMWare vSphere). The Troubleshoot Remote Display dashboard The latency has its own status derived from its own expected time (its baselines). This is separate from the activity response time, which also has its status depending on its own baselines. Note When you view an activity's response time in a VDI deployment, there are two separate times you must add: the regular application's response time on the VDI server itself (made up of the client time, server time and network time) and then add the remote display latency between the VDI server and the front line end user of the virtual desktop. For any given activity response, if we assume that there is only one round trip from the client to the VDI server for the activity and its response (which depends on the architecture of the application deployed in VDI), the total response time of an activity would be: VDI response time = (2 x remote display latency) + activity response time Typically, however, the virtualization platform would use more than one round trip to the virtual application server or VDI server for each activity, so it would be many more than 2 x remote display latency. Effective response time of a VDI end user Aternity monitors performance in a wide range of virtual applications and virtual desktops. The virtual servers must be housed in one of the following operating systems: Attribute Requirement Virtual server operating system Windows Server 2016, 2012 R2, 2012, or 2008 R2. The Windows Agent supports virtual devices and/or virtual applications with any of the following requirements: Attribute Requirement Citrix virtual application servers Citrix XenApp 6.5, 7.6, 7.8, 7.15. Citrix virtual desktop servers Citrix XenDesktop 6.5, 7.6, 7.15. VMWare Enterprise VDI VDI support is for VMWare Horizon View 6.x and 7.x up to 7.2 (certified support for version 6.2). Aternity does not monitor the ESXi hypervisor. VMWare ThinApp is NOT supported. Microsoft RDC Microsoft Remote Desktop Services 6.1, 8.1, 10.0. Microsoft virtual application servers Microsoft App-V 4.6 SP3, 5.0. ProcedureStep 1 Open a browser and sign in to Aternity. Step 2 Access the dashboard by typing its name in the search box in the top bar. Alternatively, access the Remote Display dashboard by selecting first Main Menu > Troubleshoot > Virtual Desktop. Accessing Troubleshoot Virtual Desktop Select the Remote display latency option in the pop-up window. Select to troubleshoot the remote display latency Step 3 See the clients with remote display latency problems which need your attention, their location, and their connected servers or virtual machines. The measurements show the percentage of latency times which have a status of normal, minor, major, sorted by the worst performers. Your goal is to have all the latency measurements as normal. Check where the latency issues in your company are concentrated Field Description Client Locations Check if the client devices with the slowest latency are concentrated in a certain location. Client Devices Check the users and client devices with the longest latency time. Cities Check if the problem impacts users working from a specific location (also collated by Cities, States, Countries, and Regions). You can also view this information on a map in the Geographies section. For example, if performance is poor only for users in the office in North London (a business location), check the networking infrastructure of that specific site. But if the problem affects all the offices in London (under Cities), you can check the wider infrastructure which is common to all those locations, like a data center. Servers/Virtual Desktops Check if the problem occurs for all users who connect to specific servers or virtual machine. Data Center Locations Data Center Locations in Aternity lists the locations of any virtual application servers (like Citrix XenApp) and VDI hypervisors (like in VMWare vSphere) which run the application. If the application is deployed both locally and virtually, one of the locations displays as Local. Latency Displays the average latency time (in seconds) during the timeframe of the dashboard. For further information, you can drill down to: The Activity Resource Analysis dashboard, to see the effects of an activity directly on the resources of the device. The Desktop Reliability dashboard, to view the stability of both client and server devices. The Device Health dashboard, to troubleshoot hardware, system, and application issues. The Monitor User Experience dashboard, to see the recent log of events performed on this device. The SLA dashboard, to view the occurrences when the performance is slower than your service level agreement (SLA) thresholds. The Troubleshoot Boot dashboard, to see the performance of different devices in terms of boot times. Step 4 See when the latency issues started in the Trends section. Change the dashboard's timeframe to extend the graph's time period if required. Hover over the graph to see the exact time of the measurement and the average latency time. Look at the recent statuses of latency over time, to see if it is improving or worsening. See the latency changes over the timeframe of the dashboard Field Description Time Presents the day and hour of the measurement. Score Presents the score for the statuses of all the latency times calculated by condensing all the latency statuses into a single value. Status Presents the score's status. A poor status is a sign you should troubleshoot this connection. To zoom in on the times with the worst latency, select a place of interest on the graph, and view a second graph which opens underneath showing one hour after the time you selected on the upper graph, so you can pinpoint the changes. Zoom on the latency peaks Step 5 Troubleshoot your latency problems by finding the common element where the performance problems are concentrated, by selecting that element and viewing other sections of the dashboard. You can investigate either the virtual servers or the front end clients: To investigate the server side, select the data center location with the slowest latency, and view the servers, devices, and trends concerning that location only, to assess possible correlations. You can then select the server with the slowest latency at that data center and view all the client devices remotely connected to that server. Verify the common attributes between those devices. Then you can drill down on a device for more information on their hardware or software issues. To investigate the front end clients, select the client location with the highest percentage of long latency times and then investigate the users connected from that location and to their servers or data centers. Isolate the view of your dashboard to the longest latency times Step 6 You can limit the display of this dashboard using the menus at the top of the window. Choose to display virtual application servers or virtual desktops, or choose to display specific protocols. Limit the view of the dashboard Field Description Timeframe Choose the start time of the data displayed in this dashboard.You can access data in this dashboard (retention) going back up to seven days. This dashboard's data refreshes every hour. Device Type Select one of the following: Virtual App Servers offer multiple users access to a single instance of an application, for example, with Citrix XenApp. Virtual Desktops offer the ability to run an application within a VDI environment, which is a virtual instance of the entire desktop operating system (usually Windows). Protocol Displays the remote display protocol: ICA, the protocol used by Citrix XenApp. RDP, the protocol used by Microsoft products like Remote Desktop Connection. It is also increasingly being adopted by newer versions of Citrix XenApp. PCoIP, the protocol used by VMWare's VDI systems. Status Select whether to display only the activities which are exceeding SLA thresholds. Select one of the following: Exclude Normal displays only activities which exceed their SLA thresholds. All does not exclude data. Parent topic Key Task: Troubleshoot Virtual Desktop