If you are used to working with XenApp, then being able to create custom administrator roles is nothing new, it’s just there like it’s supposed to be. However, if you are a hardcore XenDesktop admin then this is probably something you’ve been waiting for. The predefined administrator roles (5 in total) in XenDesktop 5 just don’t cut it, and we want, or need, flexibility. Well… with the release of XenDesktop 7 it’s now all there. You’ll still find a set of predefined roles but with the added possibility of creating a custom role, finally!
Pre-defined and custom
The ability to assign a user or certain groups of users, not only explicit permissions, but permissions to specific objects as well is a must in most organizations. With delegated administration in XenDesktop 7 you can do just that. The idea behind it is based on roles, scopes and objects which I’ll explain shortly. As mentioned, just like with XenDesktop 5.x there is also a set of predefined roles, you’ll find them in the overview below, note that these are not customizable. However, the real flexibility and granularity comes with the custom administration role, which is new.
Looking at the above kind of gives you an idea what roles are about. Roles define what a user can do within your Site depending on the permissions granted. If we look at the Helpdesk Administrator role for example, it can view delivery groups and manage all sessions and associated machines with it. Unfortunately it doesn’t give us the option to configure which delivery groups the Helpdesk Administrator role can view and thus manage, meaning that this particular role can manage sessions and machines for all delivery groups within your Site. The same goes for the Applications Administrator role; it can manage all applications, including all associated machines and sessions, not much granularity here. But wait… this where the custom role come in.
Scopes and objects
Go hand in hand and help form the custom administrator role. With scopes you define which specific objects (per department for example) an administrator can manage as part of the custom role permissions, like; desktops, catalogs, applications, hosts etc…Basically the same as with the predefined roles mentioned above only now you can limit the scope to specific objects. By default there is one scope defined, it’s named ‘All’ and it holds all Site objects, including the ones that are created and added at a later time, it can’t be deleted or modified. All predefined roles mentioned earlier are based on this scope. So unless you create a custom role and the scope(s) to go with it, administrators will be able to manage all objects that fall within the range of one of the predefined roles you assign them.
It works like this
You first create a custom administrator role, give it a name and assign permissions to it. This is all still high level, for example, you assign the custom role permissions to manage several objects like; delivery groups and machine catalogs. During that same step you also decide what can be managed (sub-permissions) within these objects; can they create, add or delete applications to and from the delivery groups, add or delete machines to and from catalogs and so on and so forth, there is a whole list of options to choose from.
With high level I mean that these permissions still apply to all delivery groups and catalogs within your site (the ‘All’ scope). In the next step you configure the scope to which these permissions will apply. You simple select the delivery group(s) and catalog(s), again, called objects as part of the scope, to which these role permissions get applied and that’s basically it. Once created, you’ll have to assign the custom role plus scope(s) (and objects) to a user of choice by creating a new administrator. I’ll throw in some visuals to clarify. First we need to create our custom role. In Studio go to the Administrators page, it’s on the left. Click on ‘Create Role’ on the right hand side of the screen, a new window will pop up.
Give it a name, description and decide which permissions (and sub permissions) to assign.
After clicking save, you’ll need to create your custom scope. Switch to the scopes tab and select ‘Create Scope’ on the right. Here you’ll see all objects available within your Site, select accordingly and click Save.
Once that’s done there’s just one more step left. You’ll now need to create a new administrator, as explained earlier, to which this custom role (and scope(s) plus object(s) can be assigned to. Give this some thought, especially if you have multiple custom Roles and Scopes. For example, assigning custom role permissions, during the first step, to modify delivery groups doesn’t do anything when the accompanying scope is set to catalogs, so select accordingly. Select ‘Create Administrator’ on the right side of your screen.
Click the ‘Browse’ tab to select a user account, next, select the appropriate scope to go with the custom role which you’ll need to select on the next page.
Finally the summary page will appear, meaning you’re done. Hit Finish and the rest will take care of itself. Make sure that the ‘Enable Administrator’ box is checked so that the account can be used right away, or not, if that’s what you need.
Every ‘normal’ domain user can become an administrator, there are no specific prerequisites. If a user is made a member of multiple custom administrator profiles then all permissions will be added up, they are inclusive. All custom administrator roles and scopes defined can be copied when necessary. If your Site is complex and has multiple custom administrators configured, dozens perhaps, you can use the so called Resultant Set of Permissions tool to see which permissions go with which custom admin account. Personally I’m not sure if this will be used much but I can see the added value in some cases.
Delegated Administration is something we can’t do without, I think we all agree. I wonder why Citrix waited this long to include it as far as XenDesktop is concerned. I can’t imagine this being extremely complicated to implement. Anyway, it’s here now and pretty straight forward to configure. I was playing around with it myself and thought it might be a good subject to write about. Although it taught me a thing or two, to be honest, you don’t need a manual to figure this one out. Thank you for reading anyway ;-)
Bas van Kaam ©
Reference materials used: Citrix E-Docs website