Best Practices for Remote Desktop Services (RDS) Licensing

MicrosoftTeams-image (19)

The two most underreported products in Microsoft SPLA are SQL and RDS. SQL is a complicated beast, but RDS? You simply license every user that has access to the software, how hard is that? In this article, we will review RDS licensing and how to avoid getting caught off guard in case of an audit.

When is it required?

Remote Desktop Licensing is required when you enable the Remote Desktop Services role within Windows Server.

According to Microsoft’s volume licensing brief titled: "Licensing Windows Server 2012 R2 Remote Desktop Services and Microsoft Desktop Applications for Use with RDS" Remote Desktop Services functionality is defined as those features or services that are running when enabling the Remote Desktop Services role and/or role service(s) in:

Windows Server 2008,  Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2.

This includes, but is not limited to, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop Connection Broker, Remote Desktop Session Host, and Remote Desktop Virtualization Host. The same is true for Windows Server 2016, 2019 (the article was written in 2014).

Common Challenges for managed service providers

Let me provide an example of how easily you could be underreporting RDS. Let’s say your customer has an application from another vendor (outside Microsoft) that’s hosted in your datacenter. That same vendor provides support to the application. You are not hosting the application for the vendor but for your customer, you just provide the vendor access to support the application via remote connection. SPLA allows 20 users to provide support and administration per datacenter. If you exceed that limit, you are going to have to report those additional users. Yes, even if you are not charging them.

How to fix RDS underreporting 

The best way to avoid RDS pitfalls is to set up a security policy for indirect access to the software. Many times, during an audit, RDS is underreported because someone never deleted the user from AD or they forget about indirect access (not actual access). Setting up security policies is great for any user based products.

We also get asked a lot about providing access for demonstration purposes. According to the SPLA Indirect Agreement (page 6 section F) allows a SPLA provider to demonstrate their solution (including RDS) to up to 50 active user ID’s for demonstration purposes.

They can also provide a trial for up to 60 days for evaluation purposes. Many customers do not take advantage of this use right. There are restrictions (i.e., you cannot charge for access during this period and keep active records). In addition, you are allowed up to 20 administrators per datacenter to access the server software. My recommendation is to ensure you label “admin” in active directory in case of an audit.

MicrosoftTeams-image (18)

Things to remember

  1. Review the demonstration and evaluation guidelines in your SPLA agreement.
  2. Make sure you have specific language in your agreement if you have end customer licenses in your datacenter.
  3. If you leverage a third-party datacenter to host your solution, ask if it is dedicated or shared?
  4. Office licenses and RDS licenses should match.
  5. If you offer Windows Server and RDS to deploy a VDI solution, make sure to advertise as such.
  6. To activate RDS, you must enter your SPLA agreement number, not a license key. This is the most important part.
  7. Work with the Octopus Cloud team to help you determine best licensing and set up a proper monitoring solution to identify any licensing gaps with RDS.

Thanks for reading,

SPLA Man

Back to Blog