XenDesktop/XenApp 7.x from a XenApp Adminstrator view Part 2
- Published: Tuesday, 08 April 2014
In the first part article I started trying to explain XenDesktop from a XenApp view. We discussed the installation, the requirement to create machine catalog and the way to set-up Published Applications or a Published Desktop creating a Delivery Group. In this second part we will continue with other components available in XenApp and how they are available (if available) in XenDesktop.
If you already have worked with XenApp 6.x the way of working with policies are not changed a lot. Policies can still be defined out of the console (Studio) or within Active Directory based on Group Policies. Logically Citrix have renamed the label to which platform the setting applies, where in previous version XenApp 6.x was mentioned as the applied to this is now replaced by XenDesktop 7.x Server OS.
Delegation of Control
Just as XenApp XenDesktop 7.x offers several delegation of control options. Within XenApp you had three privileges: view only, full administrator and custom. Those privileges can be assigned to a user(group), where the custom privilege was chosen you should specify which part the user(group) get access to. Within XenDesktop this works slightly different. XenDesktop has six predefined roles, which can be assigned to a user/group.
Besides the predefined roles you can create your own roles. This role can be really customized, you can define on a detail level which functionality/rights are assigned to the role. That role can logically again assigned to a user/group.
Also Load Evaluators did not change a lot. Just as within XenApp 6.x the load evaluators are part of the policy component. However there are a few changes mainly the amount of available evaluators. Not all load evaluators are available, for example the many used Schedule evaluator (for Reboot Scripts) is not available anymore. However the most used evaluators are available but are renamed.
Not known by every XenApp admin (see my article XenApp Load Balancing explained <<LINK>>) but often used within organization with multiple data centers. In XenApp 6.5 Load Balancing arranges that users can be redirected to the preferred data center and when that’s unavailable they automatically failback to another datacenter or datacenters defined in the Load Balancing policy. Unfortunate XenDesktop 7.x does not offer this functionality yet. You can work with different machine catalogs or delivery groups to redirect the user to a specific data center, however configuring an automatic failback location is not available. Citrix already promised that these features will become available in a later XenDesktop version.
Citrix announced the Session Pre-Launch and Session Lingering with big drums and indeed those were very useful features for several use cases (especially when using Published Applications). Especially Session Lingering offered some good additional functionality to the end-user by keeping the XenApp Session alive for a define time (so when a user directly starts another Published Application, the session is still there so the application starts almost immediately). Unfortunate these features are also not (yet) implemented in XenDesktop, again Citrix is working to add those in a later version (could be that these are in the upcoming release).
Worker Groups were also introduced in XenApp 6.x and are mainly used for Load Balancing, Policies assignment and to automatically add a new server to Published Applications/Desktop. The Worker Groups are not available anymore in XenDesktop, but the functionality is available as part of the Machine Catalog, Delivery Groups or via the Tags option. After a while you will find the way the worker group functionality is exactly available within XenDesktop. As Load Balancing is not available anymore, that part of the Worker Groups is logically also not available.
Although Zones are not that important since XenApp 6.x, they are still used in many implementations. Personally I think that in a minimum of 80% they are just configured without a real good reason. However for that 20% use cases (minimizing management traffic between different XenApp server locations with limited bandwidth) XenDesktop does not offer a comparable solution. You can create different sites, but you are creating really separated infrastructures, while with Zones it still was one Farm.
Administrating / Monitoring
As already mentioned XenApp consists of two consoles. Most of the article we used the Studio console. This console is built for set-up and configuring the XenDesktop infrastructure. The Director console will be used for monitoring the XenDesktop environment. Director is a web-based console, so you can start it from anywhere.
The Director console can be used both by the system administrator for monitoring the environment as the service desk to support the end-user and see the health of the XenDesktop infrastructure. Just Google on Citrix Director and you will find some informative articles about the possibilities of Director. Remember that Director can be combined with HDX InSight, but that a platinum license is required and also a NetScaler device.
Within a XenApp environment you should enable the Configuration Logging separately. Configuration Logging is available in XenDesktop and enabled by default. By default the configuration logging is written down in the same database, but XenDesktop offers the possibility to separate the different types of data into different databases.
When are viewing a machine in Citrix Studio you have the option to place the machine in maintenance mode. As a XenApp administrator you never had this option in this form. As the name already suggest this mode enables you to execute maintenance tasks. When you enable the mode on a machine stops accepting connections, so no new sessions will be made to the server. This works on the same way as you previously used the disable user logon option within XenApp/RDS infrastructures.
Not really new, but XenDesktop 7.x (till know) can only be used using Citrix StoreFront. Citrix StoreFront is the successor of Citrix Web Interface. Where XenApp is supported both with Citrix Web Interface and StoreFront, XenDesktop is only supported with StoreFront. For the old XenApp administrator be careful when configuring the Store that you select XenDesktop as type. J Selecting XenApp means that StoreFront expects a XenApp 6.5 infrastructure.
I tried to make these articles series as complete as possible. However it can be that I missed something or did not mention a feature that I don’t use often. If that’s the case don’t hesitate to add a comment about this feature and I will add to the document. Also if you cannot find a specific setting in XenDesktop just let me know. Hopefully the article has given you a better insight into XenDesktop with a XenApp mindset.