Avoiding UDP Transport Gotchas With RDP 8

I’ve been writing and speaking a lot lately about the improvements found in version 8 of the Remote Desktop Protocol, which is used in Windows 8 and Windows Server 2012. Version 10 of RDP was just introduced in Windows 10, and it soon will be implemented in Windows Server 2016, adding some new enhancements over Version 8 which we’ll talk about soon. But back to the topic at hand…

UDP Transport in RDP 8 Boosts Throughput And Enhances User Experience

RDP version 8 is the first generation of the Remote Desktop Protocol that uses UDP alongside TCP for data transmission. Provided the RDP client supports RDP 8 (e.g. Windows 7 with RDP 8 Update, Windows 8, or Windows 10), the Windows 2012 RDSH server can transmit data using both UDP and TCP. This is a big deal, because UDP doesn’t suffer from TCP’s enforcement of its congestion-avoidance algorithm, so RDP 8 can push more data across the wire in a selected chunk of time via UDP (e.g. 2x to 8x more compared to TCP transport only), even over high latency links. Couple that with some nifty forward error correction techniques, and RDP 8 is able to boldly go into sketchy network conditions that previous versions would run screaming from.

But Watch Out For the Following Gotchas That Can Block UDP in RDP 8

Believe it or not, there are several common “gotchas” that can conspire against you to prevent UDP transport use with an RDP 8 or later Remote Desktop Connection. Let’s look at them in order:

Using a Windows Server 2008 Remote Desktop Gateway With Windows Server 2012 Remote Desktop Session Hosts

The Remote Desktop Gateway Role Service in Windows Server 2008 does not support UDP transport, so all connections via this legacy gateway will be forced to use TCP only. Not good. Make sure you upgrade your Windows 2008 server running the Remote Desktop Gateway Role Service to Windows Server 2012.

Forgetting to Explicitly Add an Endpoint For UDP in Windows Azure

This one is BIG if you are hosting your Remote Desktop Session Hosts in Windows Azure (or any other cloud service provider for that matter). By default, when you create a new Windows Server 2012 instance (with or without the RDSH role implemented), only the TCP endpoint for RDP will be created. See below:

RDP UDP Endpoint Missing

You’ll need to go back behind any newly provisioned RDSH servers in Azure and remember to explicitly define a UDP endpoint for RDP like so:

RDP UDP Endpoint Defined

Accidentally Disabling UDP Transport Via Server Side Group Policy Objects

One other potential problem is incorrectly setting the “RDP Transport Protocols” Group Policy setting, located under Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections. By default, both UDP and TCP will be used if the client supports it, but administrators can explicitly disable the use of UDP transport in this area.

So, there you have it. UDP transport in RDP 8 opens up so many possibilities in terms of user experience an overall Remote Desktop performance. However, you have to double check and make sure that it’s not being restricted right out of the gate.

Want to find out more about what transport protocols your clients use, bandwidth consumption, and connection quality? Click here to learn more about the Remote Desktop Commander, and start a $9 per server per month subscription to profile all of the above, plus much more.

Special Holiday Offer – RDS/XenApp Monitoring For $7 Per Server Per Month!

Back in September, we launched our new flexible month-to-month subscription licensing program for our Remote Desktop Commander Suite, in direct challenge the traditional channel-driven, expensive perpetual licensing models used by our competition. We now offer month-to-month licensing for only $9 per RDS/XenApp server per month, and $1 per virtual desktop/physical workstation.

A little more than two months in, and the results have been phenomenal. Small and medium sized businesses who run server based computing farms designed around Microsoft Remote Desktop Services or Citrix XenApp have been embracing our model, thrilled to finally have monitoring and reporting insight into their Terminal Server session activity, connection quality, and so much more, with so little additional cost.

To celebrate the great success of our subscription based licensing, we’re offering a special promotion through the end of this month (December 31st, 2015). Here are the details:

> Click here to learn more about our Remote Desktop Commander Suite and its many features.

> Click here to start your subscription.

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.

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.