As part of the push to bring back XenApp 6.5 functionality in the new line of XenApp and XenDesktop product releases, you can now take advantage of multiple licensing types within a single site. If you already have or want to purchase a mixture of XenApp CCU, XenDesktop CCS, and XenDesktop User/Device licenses that share the same Product Edition (Platinum, Enterprise, Advanced, etc.), then this article is for you!
NOTE: This feature does not allow you to use a mix of licenses for different Product Editions. For example, you can’t combine XenApp Platinum and XenApp Advanced licenses in the same site. You’d still need two sites for that.
I will start with a short introduction to XenApp and XenDesktop licensing for anyone new to this. If you consider yourself an expert in the area, feel free to skip the next three paragraphs, though you might still want to take a peek – you never know what you could learn when dealing with licensing.
A XenApp and XenDesktop Site needs to be licensed to function past the Trial period (for more information on licensing in XenApp and XenDesktop 7.x, see article CTX128013). The decision on which licensing Product Code and Edition combination to purchase, alongside cost considerations, is usually based on the product features that you require. To compare functionality, visit the XenApp and XenDesktop feature matrix.
For XenDesktop licensing, there is a choice of two models: Concurrent and User/Device. The expected kinds of user access to the published applications and desktops would determine whether you should purchase one or both of those models for the chosen XenDesktop Product Edition. Previously referenced article CTX128013 can help out with this decision, but in general Concurrent licenses are good for users accessing their apps and devices irregularly, while the User/Device model serves the frequent user better.
To set the licensing type that has been selected, go to Citrix Studio’s Licensing node (option ‘Edit Product Edition’) or use the PowerShell SDK’s cmdlet Set-ConfigSite. You also need to add the .Lic files purchased to import the licenses to the Site. I recommend you do that using Citrix Studio’s Licensing node.
So, how does multi-type licensing work?
As from XenApp and XenDesktop 7.14 you are able to set Delivery Group-specific licensing types that apply to all machines in those Delivery Groups and ignore the Site’s licensing (with the exception of the Site’s Product Edition, as mentioned in the beginning of the blog). The following image illustrates all that:
This was the good news. There is some bad news as well though – the functionality is not available in Citrix Studio. Yes, you have to open that PowerShell window and start typing. This one’s easy though, I promise! (Don’t forget to first add all Citrix.XXXXX PSSnapins, by calling ‘asnp citrix*’. You can also have Citrix Studio open on a side for easier access to some information and functionality outside of multi-type licensing.)
Going down to the PowerShell SDK level hasn’t put you off yet? Good.
To get your Delivery Groups to follow a licensing model different from the Site, there are two cmdlets you can call: New-BrokerDesktopGroup, to create a new Delivery Group, and Set-BrokerDesktopGroup, to edit an existing Delivery Group. To check what licensing has been set for a Delivery Group, use the Get-BrokerDesktopGroup cmdlet. (Notice the ‘Desktop’ in the cmdlet naming, rather than ‘Delivery’ – this is due to legacy terminology that has been improved because the groups do not deliver only Desktops, but Apps as well.) The two new parameters to look for are ProductCode and LicenseModel. They are not compulsory – leaving each of them unset (or setting them to $null) defaults to the legacy functionality of using whatever the respective Site property value is.
The following table contains the possible values for the two multi-type licensing parameters in XenApp and XenDesktop 7.14:
|ProductCode||null||Use the Site’s Product|
|XDT||Set to Product XenDesktop|
|MPS||Set to Product XenApp|
|LicenseModel||null||Use the Site’s License Model|
|Concurrent||Set to License Model Concurrent|
|UserDevice||Set to License Model User/Device|
Suppose you have a Site that is configured like this:
- Licenses added for
- XenDesktop Enterprise User/Device
- XenApp Enterprise Concurrent
- Site set to XenDesktop Enterprise User/Device
- Delivery Groups:
- DG1 set to License Model User/Device
- DG2 set to Product XenApp and License Model Concurrent
- DG3 set to just Product XenApp (fails because the inherited Site License Model of User/Device isn’t valid for XenApp)
Remember how I mentioned that the choice of Product Code and Edition combination can depend on the features you want to enable for your deployment’s sessions? Something that admins might forget or overlook is that there are some differences between XenApp and XenDesktop enabled features for the same Product Edition. For example, if the above DG1 and DG2 are set up for Remote PC Access, sessions on machines in DG2 are not going to be allowed regardless of the availability of licenses for XenApp Enterprise. This is because Remote PC Access is not licensed for that licensing type (visit XenApp and XenDesktop feature matrix for more).
Along with sessions, licensing can also affect machine registration. It’s worth noting that there are certain cases when the machines register with the Broker service, even though sessions or application launches would not be allowed with the applied licensing. This is because the registration for Single Session (Desktop OS) machines is disallowed only for those combinations of Product Code and License Model in which both Single Session Applications and Single Session Desktops are not licensed. The same logic applies for registrations for Multi Session (Server OS) machines. To give you an example, if the above DG2 machines are Desktop OS, they register successfully and application launches are licensed, but session launches fail as Single Session Desktops are not supported for XenApp Enterprise.
Changes to the Site licensing type could invalidate your custom licensing Delivery Group due to XenApp User/Device not being an accepted combination. Consider the scenario where you have decided to change the above site to Product XenApp and License Model Concurrent. Because a Product was not explicitly set for DG1, this means that DG1 now inherits the XenApp Product from the site configuration that clashes with the Delivery Group’s License Model. Sessions on DG1 are no longer licensed and you aren’t prompted about it by the SDK or Citrix Studio.
I have set up my multi-type licensing Delivery Groups. What next?
The answer is: whatever you would have done in previous releases. The multi-type licensing is now completely set up for your business and users’ benefit and the licenses should start being checked out dependent on the Delivery Groups that the respective user-accessed machines belong to.
As mentioned previously, Citrix Studio does not make this feature visible; hence the Licensing node is going to show only the license usage for the Site’s licensing type. To discover more, go back to the PowerShell window. The attached zip contains a script with useful functions that we created during the test automation for this feature.