BriForum Recap: Storm Clouds Over Citrix, Microsoft Rising

It’s been a little over two weeks since BriForum 2015 ended out in Denver, and as usual, it was a blast, filled with knowledgeable speakers and engaged attendees covering the entire gamut of virtualization and server-based computing.  This year, I had the privilege of being a BriForum speaker, focusing my talk on the hidden benefits provided by Version 8 of the Remote Desktop Protocol available in Windows 7, Windows 8, Windows Server 2012 and later operating systems.

One of the larger trends I’m seeing, which was echoed by many speakers at BriForum – at least in the server-based computing segment – is how Citrix’s star is fading as a viable solution for mid-market companies.  It’s gotten so bad that key shareholders in Citrix (e.g. Elliot) have effectively forced Citrix to start the spin off of some of its assets and have forced out Mark Templeton as CEO.  There’s a lot to this story, and Gabe Knuth has summed it up much more comprehensively than I can, so read his post for all of the gory details.

What is getting less press, but in my mind is just as or more important, is the fact that Citrix has made critical internal personnel decisions over the past few years leading to offshoring of certain departments with rather poor results.  I noticed the fruit of these decisions years ago when I merely attempted to get XenDesktop/XenApp 6.5 up and running in a lab environment.  A quality software product should not require multiple patches to fix critical issues just to get a solution installed.  And I’m sure CIOs continue to question a.) the high costs of the software itself combined with b.) the high costs of bringing in consultants or other hired guns just to keep their stuff running.  For a smaller or mid-market company without an unlimited budget, this creates a huge incentive to divest themselves of Citrix, and look towards other solutions like VMWare’s Horizon product and “Citrix-lite” alternatives that run on top of RDS.

Which leads me to Microsoft.  Fueled by their expansion of Azure as a comprehensive cloud computing platform, they have been investing *significantly* in remote desktop technologies, especially the latest Remote Desktop Protocol versions.  Their most recent version of the Remote Desktop Protocol, RDP 8, features incredible improvements over previous versions, primarily in the adaptive graphics department AND in the use of UDP as a transport protocol to vastly increase data throughput and responsiveness over less than reliable links (4G, WiFi, Satellite, etc).  While not as bleeding edge as Citrix’s emerging Framehawk technologies in extremely high loss networks, it’s simply *good enough* for the vast majority of corporate networks and teleworking scenarios.  And as we’ve seen in the past, once Microsoft gets *good enough* in a certain market / technology area, they tend to dominate.  Remember Novell, anyone? :)

As for us, we’re charting our path alongside Microsoft.  While our software continues to support Citrix and other configurations running on top of RDS, woe be to vendors who are “Citrix only” in their design focus, as I think they’re going to be competing for an ever shrinking piece of the pie.  There will be a lot of money to be made over the coming years on migrating people AWAY from Citrix on to pure Remote Desktop Services, and we will be a proud part of that vendor ecosystem.

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!

Want to monitor RDP bandwidth by user on Windows Server 2012? You’re out of luck…

One of the neatest things our Remote Desktop Reporter tool can report on is total RDP Bandwidth consumed in each user session.  Historically, Microsoft has made this data accessible in their operating systems one of two ways:

  1. Through queryable Performance Counters associated with a particular user session
  2. Through the underlying Terminal Services API, also queryable by individual user session

As a result, we gather this information routinely for storage in Remote Desktop Reporter’s database and offer a few out of the box reports to break it down for system administrators.  We also use it in our freeware RDP Bandwidth Monitor Tool, which is part of our complimentary Remote Desktop Admin Toolkit.

You can imagine our surprise when we discovered that these metrics are flat out gone in Windows Server 2012.  Gone, you say?  Yes, entirely.

Terminal Services Session Counters in Windows Server 2008

Let’s first look at the Terminal Services Session counters in Windows Server 2008:

Screenshot from Windows Server 2008
“Add Counters” in Windows Server 2008.

As you can see, we can get RDP Bandwidth oriented information, such as the input/output bytes of a particular RDS Session, with both the compressed and non-compressed variants available.

But, Look at Terminal Server Session Counters on Windows Server 2012 . . .

Now, let’s look at the Terminal Server Session counters from a Windows Server 2012 box:

"Add Counters" screenshot from Windows Server 2012
“Add Counters” in Windows Server 2012.
"Add Counters" screenshot from Windows Server 2012
And something seems to be missing from Windows Server 2012 . . .

The very same RDP Bandwidth counters that were present in Windows Server 2008, and many previous versions, are now gone.

What About the Terminal Services API?

Certainly we can get this sort of information from those functions, right?  Nope.  Calling the appropriate function to obtain these metrics results in the function returning successfully, but with all of these counter values now zeroed out.

It’s like Microsoft literally removed a significant chunk of Performance Counter plumbing out of the RDS subsystem in Windows Server 2012.  We’ve tested both Windows Server 2012 and Windows Server 2012 R2, with exactly the same results.

We have a support ticket open with Microsoft, and the only information we’ve received to date is that “they have researched this and unfortunately the values are no longer supported.  The documentation will be updated accordingly.”

What About an Upcoming Windows Service Pack?

Currently we are requesting possible workarounds from Microsoft to get at this type of information in Windows Server 2012, and/or a possible commitment to add those counters back in an upcoming Service Pack.  We’ll update you with anything we hear in a subsequent blog post.

In the meantime, great RDS community, what’s your theory as to why these counters are missing?  Did the “plumbing changes” to RDS to add/expand RemoteFX in Windows Server 2012 cause the removal of these counters?  Was it a simple development oversight that slipped through QA?

Weigh in with your theories below or tweet us @RDPSoft.

Terminal Server Monitoring

At RDPSoft, we have the pleasure of talking to many different folks from organizations around the globe about the challenges they face while managing Terminal Server and Citrix XenApp farms.  One thing we’ve noticed from those conversations is how the concept of Terminal Server Monitoring means many different things to many different people, depending on the industry they work in.  The purpose of this post is to flesh out the two most common things that individuals want Terminal Server Monitoring software to do on their networks.

Question – How can I monitor Terminal Server User Session Activity?

Answer – Broadly speaking, monitoring Terminal Server User Session Activity falls into two different sub-categories.  The first category is monitoring Terminal Server logons, logoffs, idle session time, and programs run inside sessions.  We like to call this sort of remote desktop user activity monitoring “soft auditing.” This is the core type of agentless, user session monitoring that our Remote Desktop Commander Suite performs.  We continually poll user session information from Remote Desktop Session Hosts and Citrix XenApp servers into a central database.  By doing so, our software can evaluate the changes that take place over time in any given user session, and build comprehensive reports that show how long users are connected, how productive (e.g. their ratio of idle time to active time) they are in certain periods of time (e.g. by hour or by day), and the programs they run inside their sessions. A terminal server monitor configured as described above is a great way to make sure that teleworkers are honoring the remote work agreements and policies established by management.

The second RDS monitoring category is often referred to as Terminal Server session recording.  Session recording is a more “intense” form of monitoring than the first category.  Session recording essentially captures the on-screen activity of one or more users on a Remote Desktop Session Host, for review and playback later. Some RDP session recording applications, like our Remote Desktop Commander Suite, capture more than just session screenshots, and can show CPU/memory usage by user over discrete time periods, as well as the network connections they establish.  While not necessary or desired by every industry, certain highly regulated industries (e.g. like finance, areas of the government) require this heightened level of monitoring for legal and compliance purposes.  One challenge inherent to this category is that it is much more resource intensive than the former;  users typically run agent processes in their sessions and the amount of screen data captured over time can be rather voluminous.

Question – How can I monitor Terminal Server Performance?

Answer – In addition to user session activity monitoring, network administrators often want to know about performance issues that could be sneaking up on them, and ultimately affecting user experience on one or more of their servers.  Typically, this area falls into two different sub-categories as well.  Preventative Terminal Server Performance Monitoring, and Post-Mortem Performance Monitoring.  The most effective type of Performance Monitoring uses both of these sub-categories in conjunction with one another.

Preventative Performance Monitoring typically entails looking at daily or weekly trends on your Remote Desktop Session Host Servers.  For instance, our Remote Desktop Commander solution can build daily, weekly, or monthly reports regarding items like Max Concurrent Sessions, Peak Active and Disconnected Sessions, Currently Disconnected Sessions, Most Contrained Load Factor (e.g. CPU or Memory), etc, CPU/Memory Usage Statistics by Session, RDP Bandwidth Usage by User, and RDP Latency by User Session and/or By Server.  Spotting trends early is the key to this form of monitoring.

Post-Mortem Performance Monitoring involves investigating WHY a Terminal Server became unresponsive or sluggish AFTER the fact.  In a scenario like this, it is critical to have a “drill down” capability to diagnose the problem. We provide this capability in Remote Desktop Commander by providing dashboards that show all user sessions that were running on a server in a the time window just before a Terminal Server had an issue, as well as how much memory and CPU each session was using around that time. Such dashboards make it easy to find the “problem sessions” that were using too much memory or CPU. From there, leveraging the detailed session performance data collected by the Remote Desktop Reporter Agent, an administrator can pull up the full historical performance record of the problem session to see exactly which programs in the session were the root cause.  By sifting through this rich historical data, an admin can hopefully put new policies into affect or increase capacity in the farm to prevent the incident from happening in the future.

Get Both Kinds of Terminal Server Monitoring – For Only $9 Per Terminal Server Per Month

Our Remote Desktop Commander Suite software continually gathers the live session state data from all of your Citrix and Remote Desktop Servers on a recurring basis (e.g. whether or not a user is idle, how long they’ve been idle, how many resources they’ve consumed (CPU/Memory/Bandwidth), the quality of their connection (RDP latency), etc), and stores that data into a central SQL database. By doing so, we are able to generate dozens of reports and dashboards that show you exactly what users were doing in their sessions, their individual performance impact on the servers, and so much more.

Even with the tremendously powerful feature set described above, you can implement this monitoring for only $9 per terminal server per month. So, please review our sample reports, demonstration videos, and feature listing now. Then, consider starting your subscription with us. With a 30-day money back guarantee and free initial support, you have absolutely nothing to lose.