Terminal Server Logging Blog Articles | Remote Desktop

Automating Microsoft SPLA Reporting With SPL Tracker – Part 2

June 4, 2014 By admin Leave a Comment

In Part 1 of our blog series “Automating SPLA Reporting With SPL Tracker,” we discussed the challenges inherent in SPLA monthly reporting requirements faced by MSPs and how to define classes of license usage in SPL Tracker.

Now we’re going to show how you can pair these license types with the Active Directory or local machine groups which serve as the gatekeepers for accessing these types of licensed applications or services.

Associating Groups in SPL Tracker

Once you have defined the license types for which the Service Provider Licensing Tracker (SPL Tracker) will track usage in Step 1 of the program, click on Step 2 – Associate Groups. Here you will be able to associate the license types you specified in Step 1 with one or more Active Directory groups in a particular client domain.

If you are an MSP or SaaS provider using workgroups instead of domains for your client networks, you can just as easily specify local machine groups in this program area. Just select “Computer” instead of “Domain”, and enter the name of the Remote Desktop or Citrix XenApp server that hosts the groups which control access to your license types.

Once you enter a computer name or domain name, you can click “Fetch Groups” to retrieve a list of all groups on a computer or in an Active Directory.

SPL Tracker Configuration Files Across Client Domains or Workgroups

It’s very easy to create template configuration files which you can reuse across all of your many client domains or workgroups. If each of your clients has their own domain, enter %MACHINEDOMAIN% for the name of the domain, or if each client has their own single server workgroup, enter LOCALHOST for the name of the computer.

SPL Tracker Screenshot Showing Adding of Associations — Adding new associations in SPL Tracker.

Then, provided your group names are standardized across all client domains and/or client servers, you can use the same configuration file for all instances of SPL Tracker – greatly simplifying deployment. We’ll have more on this subject in an upcoming post in this blog series.

You can create as many group/license type associations as needed – just click the “Add New Association” button to create each additional one required in Step 2.

In the upcoming Part 3 blog post in this series, we will review how SPL Tracker assesses the variance between actual license usage and allowed license usage. This can have a huge positive effect on your bottom line over time – so please stay tuned!

SPL Tracker is downloaded with RDPSoft’s Remote Desktop Reporter. You can download a free 30 day trial today.

Automating Microsoft SPLA Reporting With SPL Tracker – Part 1

May 29, 2014 By admin Leave a Comment

SPLA reporting is an expanding and increasingly complicated need as cloud and subscription-based solutions become more prevalent in Microsoft Windows environments.

And Really, It Isn’t Just About SPLA Reporting

In addition to Microsoft’s Service Provider License Agreement (SPLA), there is the Citrix Service Provider licensing program as well. Those aren’t the only two examples where subscription-based license reporting is necessary – more and more software vendors that cater to the Managed Service Provider (MSP) community are also offering this form of licensing.

As a result, one of the monthly chores that can considerably complicate the life of an MSP is recurring, subscription-based license reporting.

While monthly subcription based licensing greatly reduces startup costs and large, capitalized expenses, the reporting requirements can be challenging. Every month, the MSP must provide a report to various licensing authorities based on the number of users who used, or more frequently, had the ability to use specific classes of software.

This gets very tedious and labor intensive for MSPs. Some will attempt to script a solution, others will do simple counts based on AD membership or equivalent. However, both of these approaches are problematic, and they do not reflect total costs or utilization rates over time.

SPL Tracker for SPLA Reporting and More . . .

Our new Service Provider Licensing Tracker (SPL Tracker) is a powerful and cost-saving solution for this specific challenge. Leveraging the software usage history and RDS/ICA usage history collected by our Remote Desktop Reporter tool, the SPL Tracker can analyze the difference between actual usage and ability to use certain classes of licenses.

Best of all, it only takes a few steps to configure, and once configured, can completely automate your SPLA reporting and similar MSP license reporting requirements.

Two classes of license types are shown in this screenshot from SPL Tracker, an SPLA reporting software. — SPL Tracker targets the increasing need for SPLA reporting. Above, two classes of license types are shown – Microsoft Office Users and Remote Desktop Users.

Step 1: Defining License Types

By default, two of the most common license classes are defined for you automatically in the software – Microsoft Office Users, and Remote Desktop Users.

Microsoft Office Users

This class represents all users who have accessed Office components (e.g. Microsoft Word, Microsoft Excel, etc) in your shared computing environment, based on Remote Desktop Reporter’s usage history.

Remote Desktop Users

Similarly, the Remote Desktop Users class represents all users who established an RDS or Citrix XenApp session in a given time period.

Additional Definitions / Classes

You can create additional definitions to track the usage of other applications – those that access SQL Server, for example. Simply create a new license type definition, select the processes that reflect the usage, and save it for later use.

Keep in mind that you can automatically omit disabled user accounts from reports. And, you can also prevent the SPL Tracker from marking newly on-boarded user accounts in a client’s Active Directory as inactive.

Upcoming Insights on SPLA Reporting and More . . .

In Part 2 of our Service Provider Licensing Tracker series, we will demonstrate how to correlate historical license usage with the Active Directory groups that control access to those license types.

Do you have questions about what you’ve read here? Respond below!

Tracking Attendance for Telecommuters and Local Users – Remote Desktop Reporter

April 19, 2014 By admin Leave a Comment

We recently made a few tweaks to our “Attendance By Day” and “Attendance By Hour” reports – appearing In Version 1.9.4 of Remote Desktop Reporter. This creates a new class of user attendance reports that also factor in console user sessions when building the reports. If you’ve been tasked with tracking attendance for telecommuters and local users, this will definitely help conserve time and money.

The “Console” Session and Why It Matters

Are telecommuters goofing off? Track attendance with Remote Desktop Reporter. — Bueler? Bueler? Telecommuters are generally more productive than office workers. Still, you may be tasked with tracking their attendance.

For the uninitiated, the “console” session is the local, interactive logon session a user creates when they sit down at a Windows workstation or server to do work.

There can only be one console session per computer running at any time. This is in contrast to Remote Desktop sessions, which are created when a user connects to a workstation or server remotely to do work.

More recent versions of Windows workstations (such as Windows Vista, Windows 7, and Windows 8) have some nifty user session techniques. These can automatically convert a previously logged on console session to a remote desktop session if the same user who established the console session starts a remote session later.

Similarly, if a user leaves a remote user session open but disconnected, and later signs on to the computer locally, that remote session gets converted back to the console session.

Tracking Attendance for Telecommuters and Local Users

Report on attendance by hour - console users. — A report from Remote Desktop Reporter shows how attendance can be tracked for telecommuters and on-site workers.

Some managers may wish to get a feel for total employee attendance regardless of whether they are telecommuters or working locally. Using these new attendance reports can help solve that issue, as they look at whether or not users had either type of session open on their workstations or servers. While idle and active time cannot be tracked in the console session, whether or not a session was established in the first place during certain hours or days can be.

Administrators who wish to implement this approach with our software would be wise to consider implementing the free WinExit screensaver or equivalent, which will automatically logoff console sessions after a certain period of inactivity. This guarantees that locked but inactive console sessions will not be included in the reporting.

Interested in setting up a system like the above? Or, maybe you just want to track telecommuters. Contact us to review your objectives. We’ll be happy to make some recommendations.

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.