Application Licensing

All this work on the Terminal Server licensing might almost make you forget that you have to properly license your applications as well. While the purpose of this book is to focus on Terminal Server, there are some common threads worth pointing out regarding application licensing.

Because there are so many different ways that applications can be licensed, it's impossible go into specifics here. However, in almost all cases, the application usage license is tied in some way to the number of users or client devices. Most application licenses are not linked to the number of times the application is installed because the application vendors don't want you to buy one copy of the application for each Terminal Server that you have and then make that application available to hundreds of users per server.

Most applications today have licensing agreements that fall into one of two categories:

• Per Named User. One license for each user that could execute the application.

• Per Concurrent User. One license for each concurrent copy of the application that is executed.

Enforcing Named User Application Licenses

Applications that are licensed "per named user" require that you have a license for each user that could access the application. If you have 100 users with access to an application but no more than 10 ever connect at the same time, you still need to purchase 100 application licenses. Most Microsoft applications are licensed this way, in addition to many expensive line-of-business applications.

The key to properly enforcing per named user application licenses is permitting or preventing users from being able to access the applications. An easy way to do this is to create a domain group with all the user accounts of the users that will need to access the application. Then, add these users to the Remote Desktop users group on the Terminal Server hosting the application so that only members of that domain group can use it. This can also be done by setting NTFS permissions on the executable if users that don't use this application connect to the same Terminal Server.

Another option is to create a Software Restriction Policy to restrict that application to only a certain group of users. This policy could be applied in the Group Policy at the OU level for a large number of Terminal Servers.

By restricting access to the application itself, you guarantee that only appropriate users will ever use the application. When it comes time to pay for your application licenses, all you have to do is count the number of users that are in your application group and buy that number of licenses.

Enforcing Concurrent User Application Licenses

Applications whose licenses are based on the number of concurrent users only require that an application license is purchased for each concurrent connection. If you have 100 users that have access to an application but no more than 10 ever connect at the same time, you only need to purchase 10 licenses. Your company's accountants will appreciate applications that are based on concurrency. You will probably not appreciate them because they are harder to enforce from a technical standpoint.

Within Terminal Server, there are two ways to enforce concurrent users:

• Limit the number of connections on the Terminal Server hosting the application. This can be done in the Terminal Server Configuration utility by editing the RDP connection properties.

• Create a batch file that writes to a flag file before an application is launched. That batch file can be configured to check the flag file to see how many other instances of the application are running. For environments in which applications are executed across more than one server, the flag file can be stored on a network drive. When users quit the application, the flag file is updated to reflect the user change. The only problem with this (other than the complexity of writing the scripts in the first place) is that the flag file is not updated if users do not exit the application properly.

Hardware Dongles in Terminal Server Environments

The only additional item worth mentioning about application licensing relates to applications that require a hardware key. If you have an application that requires a hardware key, or "dongle," it probably won't work on a Terminal Server. Microsoft has intentionally disabled this functionality because the sole purpose of a hardware key is to prevent multiple users from using an application, and Terminal Services' sole purpose is to allow multiple users to use an application.

If your hardware key vendor did not use the standard Microsoft APIs when writing the application, the hardware key may work on a Terminal Server. If this is the case for your application you must ensure that its use in a Terminal Server environment is acceptable from a licensing standpoint.