How To: Terminal Server Performance Tracking With Remote Desktop Reporter

In a previous blog post, we reviewed how the Remote Desktop Reporter Agent is able to track CPU and memory use by user session. With version 3.0 and later in Remote Desktop Reporter, performance reporting across RDS, Citrix XenApp, and other Server-Based Computing platforms has been expanded dramatically. So, here’s a how-to with some helpful tips on getting the most out of Terminal Server performance tracking using Remote Desktop Reporter.

Different Approaches to Terminal Server Performance Tracking

In a server based computing (SBC) environment, tracking performance is critical, as one wayward app consuming a lot of CPU cycles or memory in a single session can impact user experience severely across the other user sessions.

Peak Memory Use by Application Dashboard Screenshot
Screenshot of the Peak Memory Use by Application Dashboard in Remote Desktop Reporter.

Simple server-based monitoring tools may be able to tell you whether or not a server is experiencing high CPU or memory load, but they seldom can indicate what user session was experiencing the problem, and more importantly, how the problem initially developed for root cause analysis.

This is where Remote Desktop Reporter is different. Using the new Remote Desktop Reporter Agent, performance metrics are routinely gathered from all participating user sessions and stored centrally in a database.

Terminal Server Performance Tracking By User Session or Application

In the event of a server performance issue, it’s easy to very quickly zero in on the particular application or user session causing the problem. From there, an administrator can step through the session’s performance history to determine what led up to the problem.

Session Explorer Dialog Screenshot from Remote Desktop Reporter
Effective Terminal Server performance tracking requires visibility to CPU and memory use. With Remote Desktop Reporter, you can step through the entire CPU and memory consumption of a session.

The new Peak Memory Use By Application Dashboard in the Remote Desktop Reporter Analysis Client allows an admin to quickly see which applications were using the most memory across monitored Remote Desktop servers in a given timeframe.

More importantly, it shows the user associated with the session, as well as the server on which the session was running and the time when the application was using the greatest amount of memory.

If an admin selects an Application and clicks the “Open Selected Session” button, they can quickly step through the entire CPU and memory consumption of the Terminal Server session in the Session Explorer dialog.

Average Memory Use By Application

Screenshot of average memory use by application graph in Remote Desktop Reporter
Average memory use by application graphed in Remote Desktop Reporter.

In contrast, if admins simply want to see which applications consume the most memory on average in user sessions, they can use the new Average Memory Use By Application Dashboard.

This information can also be limited to a specific timeframe and to a specific group of terminal servers as needed. As we all know, cutting out noise to focus on the exact time of trouble or the specific group of culprits saves time and headaches.

Finally, keep in mind that this data is also accessible via ad-hoc or scheduled reports. Simply select the Performance – Average Memory Use By Application or Performance – Peak Memory Use By Application reports and pair them with any desired filters.

Screenshot of peak memory use by application graph in Remote Desktop Reporter - key for Terminal Server performance tracking.
Peak memory use by application.

What About VDI User Sessions and Physical Desktops?

While the above Terminal Server performance tracking examples were focused on diagnosing performance issues on terminal servers and Citrix XenApp servers, it’s worth mentioning that the Remote Desktop Reporter Agent can grab these same metrics from VDI user sessions and even physical desktop sessions.

As always, Remote Desktop Reporter – including the Remote Desktop Reporter Agent – is available for download as a free trial software.

Have more questions about Remote Desktop Reporter and performance tracking across your entire network, including on-premise, private cloud, and even MSP environments?

Contact us with your questions. Your insights might even inspire our next blog article!

Three New Ways to Report on Remote Desktop Performance

Last week we explored the addition of the Remote Desktop Reporter Agent and Analysis Client available in Remote Desktop Reporter 2.7. But wait! There’s more when it comes to this most recent release of Remote Desktop Reporter.

New Reports Target Remote Desktop Performance

We’ve also added three new – and frequently requested – reports to our stable of over 60 reports encompassing all aspects of user session activity and performance metric tracking. These three specifically focus on Remote Desktop performance.

Program Run Times By User

This report offers a breakdown of how long different applications are run by different users. Pairing this report up with filters on process names and users, you can quickly determine how long specific programs are being run in sessions compared to others. MSPs can also use this report to create metered billing solutions for the use of specific programs.

Program Run Times By User Report
Program Run Times By User report screenshot.

Session Reconnect Attempts

Now you can quickly highlight specific users from specific clients that have had frequent reconnection tries to servers in specific hours of the day. Review this report regularly can highlight connectivity issues either on specific servers, or more likely, on specific clients.

Session Reconnect Attempts Report
Frequent reconnection attempts are a Remote Desktop performance red flag. This is a screenshot from the Session Reconnect Attempts report.

CPU and Memory By Session

Ever need to quickly highlight CPU and memory consumption by user session on each server? If not, you will. This report mimics a dashboard in the new Analysis Client, which shows average, maximum, and minimum CPU and memory usage for each recorded session. Use this report to spot outliers (such as high CPU or memory use), which you can further investigate in the Analysis Client to find out what behaviors or applications caused high utilization of CPU and/or memory, in order to prevent them from taking place in the future.

CPU And Memory Use By Session Report
Screenshot from the CPU And Memory Use By Session report.

See These Reports in Action For Yourself

In addition to these three Remote Desktop performance reports, there is so much more now appearing in Remote Desktop Reporter 2.7 and later. Free trial software is available for download from our web site, and pricing remains highly competitive. Do you have a question about other reports available in Remote Desktop Reporter? Just ask below.

About Our Remote Desktop Reporter Agent and Analysis Client

The centerpiece of Remote Desktop Reporter 2.7 is the addition of the brand new Remote Desktop Reporter Agent, coupled with the new Analysis Client. Past versions of the software have been agentless, and that capability is preserved in the new release for those who do not need the new expanded feature set.

What the Addition of the Remote Desktop Reporter Agent Means

In the past, with its agentless architecture, Remote Desktop Reporter collected and warehoused user session information from Remote Desktop servers, VMWare Horizon View servers, and Citrix XenApp servers.

But, the Remote Desktop Reporter Agent enables the gathering of an enhanced set of metrics as well as collecting the same types of metrics from physical desktops and any desired virtual desktops.

For Example, Remote Desktop Reporter Can Now . . .

The new capabilities made possible by both the Remote Desktop Reporter Agent coupled with the Analysis Client are expansive.

CPU and Memory

Remote Desktop Reporter can now show administrators how much of the CPU and memory individual sessions are consuming. This can be shown both in aggregate and by the minute.

Memory and CPU By Session Dashboard
Memory and CPU By Session Dashboard as shown in Remote Desktop Reporter.

 

Recorded Session Memory and CPU Slices
Recorded Session Memory and CPU Slices

Screen Captures

Periodic screen captures can be recorded for later review, so that administrators can see what programs in sessions are connecting to what sites and over what ports they are connecting.

Recorded Session Screenshots
Recorded Session Screenshots

TCP/UDP Connections By Session and By Process

The Remote Desktop Reporter Agent can be configured to capture all open TCP/UDP connections made by applications running in user sessions. Administrators can then search for sessions with activity over a specific port number, and find out exactly what application was the culprit.

Session Search By Port Activity
Session Search By Port Activity

Tested, Reliable Database Storage

All of this data is indexed in a database so administrators can search for sessions that match chosen criteria – application name, port usage, or application window title, for example. And just like previous versions, you can leverage the free, built-in Microsoft SQL Server Express DB instance for smaller deployments or scale up to limitless data retention with the full version of Microsoft SQL Server.

Time Tracking Data

Management can get valuable time tracking information based on computing resources that are being used – whether on-premises or cloud.

Root Cause Performance Analysis

Administrators can quickly prepare a root cause analysis on problems that crop up on multiple SBC platforms – enabling them to drill down to a specific program in a user session.

Remote Desktop Reporter Capabilities Expand While Pricing Stays Within Reach

RDPSoft remains committed to putting quality tools in the hands of the SMB community. All the while, pricing remains well within reach. And, free trial software is always available.

Have you worked with the new release of Remote Desktop Reporter yet? Do you have questions about what Remote Desktop Reporter can do for you? Share your thoughts with us . . . 

Tracking RDP Bandwidth on Windows Server 2012: An Update . . . Is a Hotfix On The Way?

A few weeks ago, in a blog post titled Want to monitor RDP bandwidth by user on Windows Server 2012? You’re out of luck…, we exposed the fact that the API function calls and Performance Counter metrics that used to provide per session RDP bandwidth consumption no longer worked and/or had gone missing.  At that time, we speculated that this was a result of “plumbing changes” to the Remote Desktop Services code base to add greatly enhanced RemoteFX support in Windows Server 2012.

We finally have more information, and if you need to reliably track RDP bandwidth consumption by client or by session, you’ll want to read on . . .

RemoteFX Plumbing Woes

It turns out, we were right. :)

Windows Server 2012 Plumbing Changes Affect Tracking RDP Bandwidth
The plumbing changes that occurred in the Remote Desktop stack in Windows Server 2012 dramatically impacted the ability to track RDP bandwidth.

After much back and forth with a highly professional Microsoft support representative, it was determined that the plumbing changes in the Remote Desktop stack to enhance RemoteFX in Windows Server 2012 were so massive (including moving whole chunks of code out of kernel mode into user mode), they effectively nuked the old API calls and Performance Counters.

Now, as has been mentioned by the distinguished Shawn Bass of the RDS MVP community, there are some new RemoteFX related performance counters that look at bandwidth.  However, these counters look at rate only, and only at bytes transferred/received in the last second.

Therefore, they do not function as before, nor are they a substitute for the old “total bytes transferred/received” counters, because they are not stateful over the life of a particular RDS user session.

Potential Pitfalls Polling Stateless RemoteFX Performance Counters For Bandwidth Data

In order to get anything approaching a total bytes transferred/received count, you literally would have to poll these counters every second, which presents many pitfalls.

  • Dependence on WMI for this data.  Not highly scalable, nor particularly reliable, in our opinion.  Don’t just take our word for it though.
  • Significantly increased bandwidth required during polling.  Pulling multiple performance counters every second over the network adds up quick.
  • No tolerance for any missed polling of data.  Miss a few seconds here or there due to a blip on the network, or the inability to access the counters for whatever reason?  That stateless data is gone, forever, and now your bandwidth tally is inaccurate.  Bad, bad news if you’re an MSP or SaaS provider actually trying to bill or meter users based on bandwidth transfer.

Of course, this doesn’t even cover the tedium of trying to match up the underlying user with a particular Winstation name.

A Hotfix On The Way?  You Might Want To Wait On The Windows Server 2012 Upgrade If You Wish to Track RDP Bandwidth Consumption

Fortunately, there is some good news (for now).  To their credit, Microsoft’s support department has agreed to file for a Hotfix to restore stateful, per-session aggregation of bandwidth metrics back through the API.  The actual release of a Hotfix is by no means assured, as it has to go through multiple levels of approval by the folks in Redmond.

In conclusion:  If you are an MSP or SaaS provider that needs to reliably track RDP bandwidth consumption by client or by session, stay at Windows Server 2008 R2 for a little longer.  This issue, in our opinion, combined with some continued challenges around RemoteFX (which we will write about later), warrants a period of watchful waiting as the Windows Server 2012 offering fully matures.

As soon as we receive word on whether or not the Hotfix will actually be developed, we will update our readership promptly.

In the meantime, if you are an MSP or SaaS over Remote Desktop vendor and would like to find out more about how our Remote Desktop Reporter tool can help you, click on the links above for more details, or contact us by phone to discuss your needs in more depth.

SaaS Over Remote Desktop: License and Resource Metering Techniques

Believe it or not, there’s a nice sized portion of SaaS vendors in the marketplace that are delivering their SaaS applications to clients over RDS (Remote Desktop Services) as opposed to the Web.

Why Remote Desktop and RemoteApp?

There are several reasons many software vendors choose remote desktop (or RDS) and RemoteApp as the mechanism by which to provide their software as a service over the Internet. Here are the big reasons:

  • Inherent limitations in building a web application with a consistent, rich, and responsive user interface.
  • Additional development and QA costs associated with web apps.
  • The costs to migrate an existing non-Internet based application.
  • Security considerations.

But Don’t Forget License and Resource Metering

As we do more and more business with “Saas over Remote Desktop” vendors, one of the biggest problems we see them experience is license and resource metering.

SaaS vendors using remote desktop have some numbers to crunch.
If you’re an SaaS vendor using Remote Desktop to deliver your application, you’ve got some numbers to crunch when it comes to license metering.

It’s one thing to develop and bring a SaaS application to market.  It’s quite another to figure out how to:

  • Capacity plan for additional hardware / virtualized servers in your server farm as your client base grows.
  • Attribute costs of business to specific clients (How much bandwidth/memory do they use?).
  • Reliably meter client usage of your application for billing purposes . . . and to know when to bump your clients up to the next subscription level based on that usage.

. . . or the Bottom Line

We then help SaaS vendors solve those very problems. As an aggregator of Remote Desktop Session metrics, our Remote Desktop Reporter solution is being used to produce lots of different reports that help a SaaS vendor stay on top of client license and resource usage, and in turn, significantly improve their bottom line.

Some of those metrics include:

  • RDP bandwidth by user.
  • Peak concurrent sessions by server and/or by user.
  • Distinct RDS users by time period.
  • Total time by RDS user.
  • Specific application use by user.

Are You a SaaS Vendor in a Similar Situation?

We can provide a web demonstration of how to configure our software and establish these reports. Reach out to us here or message us on Twitter @RDPSoft.

Or, post a question below and continue the discussion!