When you think about the licenses you will need for your MetaFrame XP environment, you can't forget about the licensing of the actual applications that your users will access. While the purpose of this book is to focus on MetaFrame XP, 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 MetaFrame XP server that you have and then publish that application to hundreds of users per server.
Most of the applications out there today have licensing agreements that fall into one of two categories:
- Per Named User. One license for each user that could execute the application. (Microsoft applications)
- Per Concurrent User. One license for each concurrent copy of the application that is executed. (Everybody else)
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. That means that if you have 100 users that have 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. One 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, set the permissions on the published application so that only members of that domain group can use it. Or, if your users are connecting to a published desktop instead of a published application, set the NTFS permissions on the application executable.
By restricting access to the application itself, you are guaranteeing 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 because they are a lot cheaper. You will probably not appreciate applications that are based on concurrency because they are harder to enforce from a technical standpoint.
Within MetaFrame XP, there are really three ways to enforce concurrent users. We'll look at them in order, from the easiest to the most difficult:
- The easiest way to limit the number of concurrent applications is to install Feature Release 1 or 2. Feature Release 1 and newer includes a "connection control" feature that lets you specify the maximum number of concurrent published application instances in a server farm. It also lets you limit each user to only running one instance of the application. It's based on all instances of the application on all servers, so you can easily limit application access while still getting the benefits of a load balanced application. The disadvantages of this connection control is that it requires Feature Release 1 and MetaFrame XPa or XPe. See Chapter 4 for details on connection control.
- Another way to limit the number of concurrent connections to an application is to use the Load Evaluators available in MetaFrame XPa or XPe. You can create load evaluators that are based on ICA connection thresholds or published application thresholds. They can be configured so as not to allow any more connections once their threshold is reached. See Chapter 4 for more details on configuring load evaluators.
- The last way to limit the number of concurrent connections to an application is known as "really fancy scripting." It is possible to 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 published 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. These days this method is not really used anymore, especially since Feature Release 1 simplifies limiting users.
The only other 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 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 need to ensure that its use in a MetaFrame environment is acceptable from a licensing standpoint.
IMA Data Store Database Licensing
If you use SQL, Oracle, or DB-2 for your IMA data store, you will need have the proper licenses for it as well. Fortunately, the licensing of these databases allows for licenses based on the number of connections to the database.
If your MetaFrame XP servers are configured to access the IMA data store via direct mode, you will need a database license for each of your servers. If your servers will access the data store via indirect mode, you will only need a single connection license for the MetaFrame XP server directly connected to the database.
Either way, your Citrix ICA clients will never directly access the IMA data store, so at worst you will have to buy a database client license for each MetaFrame XP server, not for each Citrix ICA client.