admin – Page 10

Tracking Citrix XenApp Concurrent Licensing

April 10, 2014 By admin Leave a Comment

If you maintain Citrix XenApp server farms, you are no doubt keenly aware of challenges inherent in keeping tabs on concurrent licensing growth in an organization. Except for the base level of XenApp Fundamentals, licensing is enforced by peak, distinct concurrent user connections to servers throughout the farm.

RDS Licensing

This is different than Microsoft Remote Desktop Services licensing. RDS is licensed per user or per device. Most modern organizations in the Bring Your Own Device (BYOD) era opt for per user licensing, as most users will be connecting to RDS sessions from multiple devices such as tablets, phones, or desktops.

Citrix XenApp Licensing

In contrast, Citrix’s concurrent licensing model is based on the peak number of distinct users who establish XenApp sessions on any Citrix XenApp server in the farm at the same time. So, you could have a scenario where you have 15 users who could potentially access XenApp services, but only have purchased 8 concurrent user licenses, as you figure that no more than 8 of those 15 will be connected to the farm at any one time.

In order to contain cost, but also see how usage is growing, it is very important to both keep routine track of how your concurrent licenses are being allocated, and if you’re starting to bump up against the maximum in your farm.

Reports to Help With Tracking

Reporting on Max Distinct Concurrent User Sessions Across a Citrix XenApp Farm — Screenshot from the RDPSoft report on max distinct concurrent user sessions across a Citrix XenApp farm.

All of this is why we’ve added a new report family in Remote Desktop Reporter 1.9.4 called “Max Distinct Concurrent User Sessions Across The Farm.” This report can help you track peak distinct concurrent users over various time intervals such as monthly, daily, or even hourly.

Schedule it on a recurring basis, and you’ll never have to worry about keeping tabs on your Citrix XenApp concurrent license usage ever again.

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

January 28, 2014 By admin Leave a Comment

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

December 30, 2013 By admin Leave a Comment

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…

December 20, 2013 By admin Leave a Comment

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:

Through queryable Performance Counters associated with a particular user session
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.

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.

Windows Azure RDP Monitoring, Cloud RDP Monitoring

November 1, 2013 By admin Leave a Comment

More and more frequently, we’re hearing from clients who need to RDP Monitoring and Terminal Server Monitoring on their virtual servers located in the cloud. When a company elects to adopt Infrastructure-as-a-Service (IaaS), making sure that activity on the virtual server gets monitored is paramount.

For new and startup businesses, IaaS makes a lot of sense, as it allows them to effectively lease at a low rate both the hardware and personnel required to service the machines running their mission critical applications and services, freeing them up to focus on expanding their core business. It also lessens the pain of making their workforce truly global; they can quickly spin up a few virtual machine images, load critical software on the virtual machines, and provide access to offshore workers as needed.

One of the key facilitating technologies that allows this all to happen is the Remote Desktop Protocol (RDP). As not all businesses can leverage web-based access to their products and services, RDP becomes very important, as it allows access to rich-client applications over the Internet. Therefore, it’s no surprise that one of the default protocols enabled on a freshly provisioned Windows Azure virtual machine is in fact RDP. RDP has become the de facto method of administering and working inside cloud-based Virtual Machines.

Having a reliable way to measure how employees and customers connect, work, and interact in their remote desktop sessions is vital. Sadly, most “cloud-based monitoring” vendors completely ignore this aspect of monitoring. Instead, they are focused on the broader, anonymous metrics associated with end user and general performance monitoring. These solutions can verify if the servers in the cloud are up and running, and the level of load they are under, but cannot tell you who specifically is connected to them, and how they are working inside them.

Therefore, tools like our Remote Desktop Reporter become absolutely critical. First, it’s important to note that Remote Desktop Reporter can be deployed directly inside cloud-based Virtual Machines – we’ve tested it successfully on stock Windows Server 2008 R2 and Windows Server 2012 images provided by Windows Azure. More importantly, once deployed, management and IT can gain key insight into how customers and employees are accessing mission-critical servers – for instance, they can find out how long their sessions run, how active they are in their sessions, how much bandwidth they consume in their sessions, and the type and quantity of applications they run. They can also derive information such as the names of unique users that visit the server each day, and the peak number of concurrent users connecting to the server each day, week, or month. The latter especially is of tremendous value to businesses that license access to applications and services based on inbound RDP connections.

So, whether you’re brand new to the “cloud,” or are greatly expanding your mission critical business infrastructure into a cloud services partner, don’t forget to budget for an RDP monitoring and management solution like Remote Desktop Reporter. We know you’ll be glad you did.