With the merge of XenApp into XenDesktop’s Flex Management Architecture (FMA) a lot changed, for most XenApp admins it meant they had to rethink their designs and as a result it was back to the drawing board. Take application, or resource, publishing for example, we now have to deal Delivery Groups and Machine Catalogs, nothing new if you’re used to working with XenDesktop, but if it’s ‘just’ XenApp you know, well… Even now where XenApp 7.5 is a product on it’s own, again, it’s still based on the Flex Management Architecture meaning it also still uses the same wizards and configuration options as in XenDesktop 7.x a few months ago, for the most part anyway.
Simply put
Machine Catalogs hold the machines from which our resources, applications and or desktops, are published. Delivery Groups (DG) are than used to take a few, or all, machines out of a Catalog (you can select them manually), next it will automatically discover all installed or available applications (it does this by communicating with the installed VDA), and last but not least, you will be able to assign these resources to your users, either individually or by AD groups. Per Delivery Group you can ‘publish’ as many applications as you like, which are than managed through that particular Deliver Group. Of course resources, and users, can be added or deleted from the DG as needed and there’s basically no limit to the number of DG’s you can create. Before I continue, if creating Machine Catalogs and Delivery Groups is something completely new to you, have a look here.
Separately
Which brings me to the following, what if we decide to publish, let’s say, 10 applications from a single DG? No problem, it just means that all users assigned to that DG will see and have access to these applications and as such will be able to subscribe and launch them. Which of course could be exactly what you want. But what if you’d like to manage and assign applications on a more granular level, per application or smaller applications groups for example?
First off you can configure multiple separate Delivery Groups, one per application or smaller groups of applications per DG for example. Although due note that for this to work you will need to create multiple separate Machine Catalogs (MC) as well since a machine can only be a member of one Delivery Group (and Machine Catalog) at a time. Using this approach you might potentially end with as many Delivery Groups, and thus Machine Catalogs, as you have applications which for a lot of companies might be just fine. Just go through the process of creating a DG and an MC a few times, group your ‘base’ application set, and you’ll be up and running in no time. Remember that this is just a way of making your resources available to your users, nothing more. It doesn’t really matter if you’re using PVS, MCS, App-V etc. if you don’t assign users to your applications or desktops they won’t be able to access your resources no matter how they are provisioned.
Back to application publishing. If you need to publish and manage a few hundred applications the above method might not be your preferred approach. Having hundreds of Delivery Groups and Machine Catalogs probably isn’t what you had in mind, so what else can we do? When applications get published, either all bundled into one Delivery Group or using separate Groups, you can still configure the properties of each application on a individual basis like we were used with earlier versions of XenApp, change its name, location, file type association etc. One of those properties is called Limit Visibility, this is what it looks like.
When selecting ‘Limit visibility for this application to the users listed below’ it will do just that, only the users listed will see the published application and will be able to subscribe to it. Do note the explanation at the top, if you want to make sure that certain users won’t be able to launch a specific application (because not being able to see an icon doesn’t mean it won’t launch), or a group of applications for that matter, you will need move them into a separate DG without those apps in it. The Limit Visibility feature is only available for applications, you can’t use it to hide published desktops, but we’ll get to that in a minute
Further more, on a Hosted Shared Desktop environment you will need to make sure to ‘lock down’ your desktop as you feel fit. Make sure that your users won’t be able to access any shares or other networks, browse the server file system, launch applications that way etc. In larger environments this is often accomplished with a little help from desktop management suites like RES Workspace Manager or AppSense for example. Of course these suites can do a lot more, and in my opinion should only be purchased if they are going to be used for a lot more than ‘just’ locking down your desktop, but that’s another subject and beyond the scope of this article, for now this will do.
So you see, using the Limited Visibility feature enables you to configure dozens or hundreds of applications into one Delivery Group without you having to worry about needing to manage just as many Delivery groups or that all applications will be seen by all the members of that specific Delivery Group. It’s configurable on a per application basis.
Three delivery types to choose from
Remember that there are three Delivery types to choose from when creating a DG, you can choose to deliver Desktops, Desktops and Applications or ‘just’ applications. Now it’s obvious that when you choose to publish either Desktops or Applications your users will get just that, a Hosted Shared Desktop or one or more applications to subscribe to and use depending on the DG they belong to. But what if you choose to create a Delivery Group that delivers both Desktops and Applications? In that case, by default, they will see the published desktop together with any applications that also might be published at that time, they will have permissions to launch both. Here’s on overview, as you can see, once you have created a Delivery Group it’s always editable afterwards. The display name is the name given to the published desktop as seen by your users.
Basically it comes down to this, you either publish multiple Delivery Groups, some with desktops (one published desktop per DG) and some with applications, and assign them accordingly. This way you can easily separate your different resources. However, when a user (or multiple) needs to use both the published desktop and a few published applications, he or she will need to be added to both, or at least multiple, Delivery Groups.
The other option is when users will use a specific set of applications together with a published desktop, in that case you might decide to go with the Desktop and Applications delivery type when configuring your Delivery Group. This is probably the preferred way of publishing a Hosted Shared Desktop (HSD) environment where your users will also use several published applications on that HSD. I say preferred because these applications are hosted on, and published from, the same underlying machines (Catalog) keeping them close to one another. When needed you can always hide one or two apps as we’ve seen.
But wait, there is more
There is a third option. What if we configure a Delivery Group, select Desktops and Applications as the delivery type but still want our users to be able to use either the published desktop or ‘just’ the applications? As we’ve learned earlier hiding applications is easy, just use the Limit Visibility feature and think about whether or not you need to lock down your desktop any further. But as mentioned , Limit Visibility doesn’t apply to published desktops, so while we are able to hide applications from certain users they will always see the published desktop when using this type of Delivery Group. Does this mean that if we want to ‘hide’ the desktop we are back to using multiple DG’s again? The answer is no, and here’s why.
The power of shell
Once we’ve configured a Delivery group with the Desktops and Applications delivery type we can use PowerShell to limit access to the HSD. By default, When you create a delivery group with the delivery type set to Desktops and Applications, Studio creates one Entitlement Policy Rule and one App Entitlement Policy Rule for the group, meaning that each user is entitled to one desktop session and one app session. Studio doesn’t expose the user filter on these objects, so both are available to all users of the delivery group.
Using the PowerShell command: Set-BrokerEntitlementPolicyRule we can change this behaviour. It can set the IncludeUserFilterEnabled parameter to True instead of False, enabling the user filter, and it also lets you add in an AD security group, this way limiting access to just that group and that group alone as apposed to all users that are a member of the Delivery group.
This is how it’s done, first you log on to one of your Delivery Controllers and open up a PowerShell console. Next you need to load the appropriate PowerShell Citrix snap-ins using the following command: Add-PSSnapin Citrix*
Than you need to determine the name of the desktop entitlement group using this command: Get-BrokerEntitlementPolicyRule. It will display all Delivery Groups configured, their names, whether these groups are enabled or disabled, if the IncludeUserFilterEnabled is set to False or True (disabled or enabled), which AD security group is bound to the IncludeUsers parameter, meaning, who has access to the published desktop, and a few more.
Once you have that information, assuming that the IncludeUserFilterEnabled parameter is still set to False and no AD security group has been configured, it’s time run the Set-BrokerEntitlementPolicyRule command where you specify the Delivery group it applies to, which AD user group should be added and finally set the IncludeUserFilterEnabled parameter to True to make it active:
PS C:\> Set-BrokerEntitlementPolicyRule -Name “fill in the Delivery Group name” -AddIncludedUsers “Domain\fill in the AD Security group name” -IncludedUserFilterEnabled $true
Finally hit enter. Again use the Get-BrokerEntitlementPolicyRule command to see if things have worked out the way they should. The result should look something like this:
Round up
That’s it, were good to go. Now that you know which options you have in configuring your Delivery Groups and publishing your applications and desktops, it’s up to you to decide how to implement these features. Multiple DG’s with separate applications or desktops, perhaps hide a few along the way, combine the two and assign the desktop to a few specific AD groups and do the same with the applications, mix and match as you feel fit!
