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. 🙂

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.