Why XenApp Monitoring Is So $#%!?@ Expensive

This post is likely going to irritate some folks in our industry, and that’s OK. Frankly, that’s the point.

Let’s Pull Back the Curtain On How Server Based Computing (SBC) / End User Computing Software Is Sold

I’ve now been in the SBC industry for nearly 2 years. Prior to that, I was the CEO of Dorian Software, a Windows log management vendor that helped governments and businesses shore up their network security and compliance.

At Dorian, we sold some through the channel, but sold direct to the end user most of the time. Because of this, we we could deliver max value because we didn’t have to pad our pricing to leave tons of margin for channel partners. It was a win-win for everyone involved – we could close deals quicker, and our customers saved a ton of money and realized a quicker return on their investment.

The Citrix and Server Based Computing Markets Are Heavily Channel Driven. Which Means Businesses Of All Sizes Get Soaked By Higher Costs Down the Line.

In my two short years as RDPSoft’s CEO, I’ve been amazed by how insular the server-based computing / end-user computing market is. Big channel players effectively act as gatekeepers of the market, and unless you bring an expensive product to them from which they can extract healthy margins, they’re not going to talk to you.

When I’ve challenged them in conversations on why more customers don’t buy solutions directly from vendors, they speak with open contempt about how “businesses don’t have the skill or expertise to deploy these solutions on their own.” Given how complex, buggy, and temperamental SBC solutions have become, they may well have a point.

However, there are plenty of admins who deploy these products every day with nothing more than online E-Docs and message boards to guide them. I know, because I talk to them each and every week.

As a consequence of the above, most XenApp Monitoring solutions sold through the channel cost more than $600 per server or $50 per concurrent user. When compared to the nearly $300 difference per concurrent user between XenApp Advanced Edition and XenApp Platinum Edition (which ships with all the EdgeSight / Director monitoring goodies), I suppose $50-$100 per concurrent user becomes a relative bargain for larger enterprises. But it’s still out of reach for most SMB shops. And it’s a complete non-starter for Managed Service Providers.

Here’s What You Get To Pay For When You Buy a XenApp/XenDesktop Monitoring Solution From the Channel

Yes, let’s dissect this. It’s not pretty.

  • The portion of the sale paid to the channel partner by the vendor (typically anywhere from 20% to 50%)
  • All those steak dinners and “lunch and learns” the vendor gets to treat the channel partner to once a quarter, in the hope that the channel partner a.) actually knows how to sell their solution, and b.) doesn’t jump ship to a different vendor that’s promising higher margins.
  • All the “under the table” payments made by the vendor to those “independent” server-based computing / end-user computing “experts” you know and love, so said experts will hawk their products in blog articles, online reviews, and at trade shows. Yes, I know said experts have to eat too, but there’s an appalling lack of transparency about how prevalent this practice is in our industry. Could we have a little more voluntary disclosure, please??!!

The Net Result: SMBs Often Get Priced Out Of the XenApp Monitoring Market

Most of the channel fat cats described above (and by extension, the vendors they partner with) have no interest in dealing with Citrix and RDS deployments in organizations with fewer than 100 concurrent users. Many of them also don’t want to deal with shops that have fewer than 500 concurrent users. However, the irony in all of this is that the *vast majority* of Citrix and RDS farms feature fewer than 500 users. Because of this effective orphaning of the SMB market, admins in these smaller networks don’t have a lot of options in their budget range. They may cobble together some scripts, lean too heavily on traditional Network Monitoring Software that doesn’t have much depth when it comes to monitoring/reporting on SBC activity, or sadly, go without. This needs to change.

It’s Time To Disrupt This Industry To Benefit the SMBs and MSPs

Now that we’ve studied this market, and seen it for how it truly is, warts and all, we’re throwing down the gauntlet.

For only $9 per server per month, or $1 per workstation/virtual desktop per month, you can now acquire subscription licensing from us. Yes, you read that correctly.

Want to continually monitor 10 XenApp servers year around? No problem – that will cost you $1080 a year.

Want to do a simple 90 day assessment of remote worker productivity on your 5 RDS servers? Easy enough – just carry a subscription for 3 months, and pay only $135!

Have two RDS servers you need to check bandwidth consumption on for 30 days? We think you’ll find that $18 to be a bargain.

Now It’s Your Turn. Help Us Get the Word Out About Our New Flexible and Affordable Pricing.

Let your colleagues and friends know about our new offering, via social media, forum exchanges, trade shows, and simple word of mouth. As a token of our appreciation, if you send us a link to a post or share you made about our new pricing model and feature set, we’ll give you a 2-month subscription credit on monitoring in your own environment! Help us shake up this niche so that organizations of all sizes will benefit.

RDP Latency – Yes, Virginia, You Can Track It Now…

RDP Latency IS Now Trackable in Windows Server 2012

Several weeks ago, I gave a really fun talk at BriForum about the hidden benefits found inside Version 8 of the Remote Desktop Protocol – specifically, the fact that for any given RDP 8 connections to a Windows Server 2012 (or Windows 8) system, you can now track things like session latency, data throughput, assessed bandwidth, error rates, and much more. Provided you know which performance counters to query and how to query them.

The big catch here is not on the client side – you can get Windows 7 updated to use RDP Version 8, and Windows 8 and Windows 10 already run it natively. Plus, most thin clients (the good ones anyway) now support RDP 8.

No, the challenge is on the server side. Each week I talk to evaluators of our tools and ask them what server platform they’re running. Inevitably, the majority seem to answer Windows 2008 R2. Yes, I get it. Windows 2008 still gives you that nice Start Menu that your users know and love. But, to be frank, RDP Version 7 (which is what Windows 2008 uses) stinks when compared to RDP 8.

Why is Version 8 So Awesome For Higher RDP Latency Connections?

Two words: UDP transport. Yep, Microsoft’s RDS gurus REALLY did things right in RDP 8. By default, unless you disable it intentionally or unintentionally (more on that in a later blog article), RDP 8 uses both TCP AND UDP to serve up remote desktops to your clients. I won’t bore you to tears with the internal mechanics, but the key takeaway is this – on marginal, high latency connections (e.g. spotty Wifi, 4G mobile hotspots, overseas WAN links, or satellite), adaptive UDP transport overcomes much of the inherent “guaranteed delivery” limitations of TCP. In doing so, it effectively can increase data throughput from 3x to 10x over previous RDP versions, all while improving the responsiveness experienced by clients interacting with their sessions.

So Beyond Improved RDP Throughput and Responsiveness, Why Should I Upgrade to Windows 2012 Server?

Good question. Because once you do, you can use our software to track every aspect of network connection quality between your RDS servers and your client sessions, whether you want to do it in realtime, or via leveraging the ever expanding set of reports we’re creating. Seriously, what we can do with this information is awesome – it lets you, the admin, get in front of those annoying damn calls from users kvetching about how the connection is dropping, or their screen updates are too slow – etc. See for yourself by watching this video we just recorded showing these features in action:

Tracking RDP Latency and Connection Quality With Remote Desktop Commander


That is really awesome stuff. And I have some Windows 2012 servers already deployed. How can I get a copy of your software to profile my users’ RDP latency and connection quality?

That’s super easy – simply start a monthly subscription of our Remote Desktop Commander Suite for only $9 per server per month. For this extremely affordable monthly rate, you can track RDP latency, RDP bandwidth consumption, CPU and memory consumption by session, plus review detailed session recordings for root cause RDS performance problem analysis and/or terminal server user auditing.

We haven’t rolled on Windows Server 2012 yet. We may wait for Windows Server 2016 next year. Is there anything in the meantime we can do to get some of this information?

Absolutely. Stand up at least one Windows Server 2012 instance in your farm, populate it with the same apps/desktop environments your users need, and then send your “problem children” clients directly over to the Windows 2012 server. If you do that, you can use our software to keep tabs on their connection quality, PLUS they’ll be able to leverage the awesome UDP transport offered by RDP 8.

How To: Monitoring RDP Bandwidth In Real Time and Session By Session

We’ve written at length about how the Remote Desktop Reporter component of our Remote Desktop Commander Suite excels at tracking RDP bandwidth consumption over time and how it is capable of generating many different reports to track this consumption by user or by computer. We’ve also mentioned how crucial it is to apply the recently released Microsoft Hotfixes so that bandwidth data is queryable on a Windows 2012 server.

But, is there an easier way to at least keep an eye on RDP bandwidth without the reporting?

The Growing Importance of RDP Bandwidth Monitoring

It is imperative that admins do something – even if it doesn’t involve reporting – before bigger problems crop up. Now that more and more shops are migrating to Windows Server 2012, it is all the more important to start monitoring RDP bandwidth. Why? Due to vast improvements in the RDP 8.0 protocol, such as adaptive graphics and combined UDP/TCP transport of data, remote desktop data throughput has been greatly enhanced.

And, what does that mean? Much larger amounts of data transferred on average. Therefore, it’s perhaps more important than ever before to stay on top of it.

Reviewing RDP Bandwidth Data In Real Time

In many cases, admins may want to simply review this data in real time, to see on a day-to-day basis which users are transferring the most data. If this is the case, our Remote Desktop Commander Suite offering (at least at first glance) might appear to be overkill.

Not a problem. Our Remote Desktop Commander Lite is perfect for this purpose.

RDP Bandwidth
RDP bandwidth by session, viewed in Remote Desktop Commander Lite

When in session view, Remote Desktop Commander Lite automatically displays total RDP bandwidth transferred in each user’s session. If you click on the RDP bandwidth column, users are grouped sorted from greatest consumption to least consumption.

When arranged in this fashion, it’s easy to spot the outliers. From there, you can message the user to find out what they’re doing and disconnect or reset their session.  You can also jump into process view to see what programs they’re running that could be the culprit.

Happy hunting of your bandwidth hogs – please be merciful to your users!

Do you have questions about how Remote Desktop Commander Lite can assist with your RDP bandwidth monitoring needs? Contact RDPSoft or start a conversation below.

Calculating RDP Bandwidth on Windows Server 2012

As we’ve discussed previously on this blog, we discovered a bug in Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 some time ago that prevented our software from being able to calculate RDP bandwidth used per RDS user and per RDS session on these operating systems. We kept an eye on it and along the way provided an update on the issue with calculating RDP bandwidth.

A Hotfix From Microsoft

Microsoft worked diligently with us in 2014, and by the end of that year, had released two hotfixes (one for Windows 8 and Windows Server 2012, the other for Windows 8.1 and Windows Server 2012 R2).  These hotfixes are now available for download.

UPDATE: Now, in 2016, these hotfixes have been incorporated into updates for the above operating systems, particularly Windows Server 2012 R2. So, provided your systems are being routinely updated, these bandwidth counters should be functioning again.

Once you apply the above appropriate hotfixes (and/or updates) to your Terminal Server farm, you can then start leveraging Remote Desktop Reporter to track RDP bandwidth consumption in a variety of ways.

A New Family of Reports Targeting RDP Bandwidth

With the release of Version 3.0 of Remote Desktop Reporter, we offer a new RDP Bandwidth report family – Bandwidth Consumption By User.

Remote Desktop Reporter RDP bandwidth report
Report in Remote Desktop Reporter showing bandwidth transferred by user.

This new class of reports can aggregate all of the RDP bandwidth usage by individual users across multiple servers by day, by week, or even by month.  It’s great to quickly pinpoint users that are most expensive in terms of the bandwidth they consume. This information also can be useful for MSPs who need to meter bandwidth usage by their clients.

As with all Remote Desktop Reporter reports, it’s easy to filter by user(s), server(s), and/or date and time.

Get Started Today Tracking RDP Bandwidth

So, what are you waiting for?  Apply the hotfixes/updates to your Windows 2012 servers, and then start a monthly subscription of our Remote Desktop Commander Suite for only $9 per server per month. In addition to the RDP bandwidth reports above, you will have complete visibility into user activity on your terminal servers, whether it be CPU consumption, memory consumption, session recordings, user time tracking, or even RDP latency/connection quality.


Tracking RDP Bandwidth on Windows Server 2012: First Hotfix Released!

In two previous posts this year (Part 1 and Part 2), we disclosed that due to the integration work related to RemoteFX technologies in Windows Server 2012, it was no longer possible to obtain RDP bandwidth information on a session by session basis on Windows Server 2012, Windows Server 2012 R2, Windows 8, and Windows 8.1.

Microsoft Generates Two Hotfixes

Fortunately, after our identification of this bug and follow-on advocacy, Microsoft agreed to generate two Hotfixes to restore this functionality. Today, with much happiness, we can announce that the first Hotfix has been released and is available for download!

Note well that this first Hotfix only will work on the Windows Server 2012 and Windows 8 codebase. There will be a subsequent hotfix released later this year for the Windows Server 2012 R2 and Windows 8.1 codebase.

The Symptoms . . .

In the article ID, Microsoft explains the symptoms corrected by this hotfix:

When you try to use the WTSQuerySessionInformation Remote Desktop Services API function to obtain information about incoming bytes (WTSIncomingBytes) or outgoing bytes (WTSOutgoingBytes) for a Remote Desktop session on Windows 8 or Windows Server 2012, the return value is always zero bytes.

Thanks Microsoft Support and Development Teams!

We’d like to give a hearty thanks to the support and development teams at Microsoft that made this happen. Good job, guys!

Remote Desktop Reporter Helps Gain Insight On RDP Bandwidth Consumption With Windows Server 2012

Now, since this hotfix is available, wouldn’t now be a great time to deploy our Remote Desktop Reporter tool to gain insight on RDP bandwidth consumption in your RDS farm, and find out which users are the heaviest consumers of it?