XenDesktop/XenApp 7.x from a XenApp Adminstrator view Part 1
- Published: Thursday, 09 January 2014
XenDesktop 7.x is already available for a while and Citrix really tried to push the message that the framework where XenApp (IMA: Independent Management Architecture) is built on will be replace with the XenDesktop (FMA) architecture. In other words the XenApp functionality will be embedded within the FMA/XenDesktop product. The first big step is set with XenDesktop 7, this version even has a specific XenDesktop App edition, that should provide the functionality of XenApp. However other versions of XenDesktop offer the XenApp functionality. Actually I noticing that many XenApp customers have difficulties to understand how XenApp is integrated within XenDesktop 7. In this article I will try to explain XenDesktop with a XenApp view in mind, trying to explain how the XenApp functionality can be found within XenDesktop.
First let’s take a look at the installation. The installation was already simplified a lot with the release of XenApp 6.0, where the installation and configuration were separated into two steps. However XenDesktop installation is not really comparable with the XenApp installation mostly based on the different architecture. XenDesktop has specific controller brokers, which are the intelligence of the infrastructure. The controller functionality is separated from the functionality to host a desktop of application for the end user (technically it is possible to combine the roles). From an installation endpoint it is complete different installation, while XenApp used the same installation steps and components for both roles).
To host applications you need to install the VDA (Virtual Desktop Agent) on a Windows 2008R2 or Windows 2012(R2) server. This is as already mentioned a separated installation. There are several ways to connect this server (in XenDesktop RDS Server called) to the controller broker. You can specify it during the installation, later on, via MCS (if using that technique) or via AD. The VDA is similar as the VDA installation as known from previous XenDesktop installations.
XenDesktop 7.x is delivered with another console than XenApp. XenDesktop 7.x is delivered with two consoles: Studio for the configuration of the product and Director for monitoring the product. Let’s first start with Studio as the configuration is done pretty different if you are familiar with XenApp.
When you start Studio for the first time you need to define a site. A site can be compared with a XenApp Farm. It’s the highest level in a XenDesktop Environment. There are two options to set-up a site: a kind of quick deploy which configures the required basics (so you can start directly using the XenDesktop) within the create site wizard and the empty set-up wizard that only set-ups the site and you need to configure the other required parts manually. When creating the empty XenDestop site is the most similar when creating the farm from the first XenApp server. You need to point to a database (can be created automatically by the wizard if it is not already available) and the license server.
When you created the farm many administrators would like to create a Published Desktop and/or a Published App. With XenDesktop however you need to execute at least one other task and that is creating a Machine Catalog.
Before you start creating a Machine Catalog you should know what it’s actually is. A machine catalog is a group of machines that can be assigned to a Delivery Group (will me described quickly). It’s a bit comparable with silos which we are used a lot in XenApp Farms. A silo was just a term used and could not be set in a XenApp farm (only a logical separation could be made with folders). A machine catalog exists of machines which have the VDA component installed and are connected to one of the Connection Controllers, so in other words the machines that will host user sessions. If you follow the wizard you will need to define which type of machine the machine catalog will be hosted (Windows Desktop OS, Windows Server OS and RemotePC Access). To set-up a XenApp similar environment you will use the Windows Server OS. Also you will see that Citrix techniques like Machine Creation Services (MCS) and Citrix Provisioning Services (PVS) are available in the wizard. MCS is not available for XenApp 6.5 environment, so you could have PVS or just regular installed servers currently. If you are using “regular” installed servers, you can select them out of AD (it is not checked if the VDA component is installed on the server). Logically you can create more Machine Catalog. However a machine can only be part of one machine catalog.
One of the questions I got is where the data collector can be found. Data Collectors could not be found anymore in XenDesktop. The Data Collector role is replaced by the Connetion Broker. Connection Brokers are NOT part of a machine catalog as sometimes is thought.
The Connection Brokers are shown below Configuration in the Controllers tab. When you install additional Controllers those will be added during the configuration steps to the site and will show up in the console. There are no options to configure on the Connection Controllers out of the console.
Probably the biggest change for XenApp admins is the way to set-up a Published Application or Published Desktop. Creating a Published Resource is done via creating a Delivery Group. To create a delivery group at least one Machine Catalog should be available (which hosts Server OS machine to create a XenApp similar environment). When you select the machine catalog you can provide how many machines of the catalog should be added to the delivery group. You can also specify in the delivery group if this group provides desktops, applications or both.
There are also similar steps like providing the user(group) which will have the desktop/application assigned. XenDesktop also “reads” the Start Menu, so you don’t have to browse for applications (everytime). Per selected application you can assign a different user group to the application and change some basic settings (Icon, Display Name, Startup Parameters) during the wizard. You can also provide a StoreFront infrastructure to a delivery group, so the Receivers installed on the machines on the Machine Catalog are preconfigure with the StoreFront configuration. Can be useful when using different XenDeskopt Sites with different StoreFronts connected to it, but I think many administrators will not use this functionality. If there are still machines available in a Machine Catalog you can create another Delivery Group with that Machine Catalog, when all machines are assigned you need to add machines to the catalog or create another catalog. Logically it is possible to add applications or additional machines to the delivery group. Several settings that were previously configured on the Published Application/Desktop are now part of the Delivery Group settings (like color depth, Secure ICA, Access Policy). This is good move as these misconfigurations on per application could brake session sharing in current XenApp implementations. Also changed is that the reboot schedule is not attached to machines, but to a Delivery Group. One more tip: Deleting a machine out of a Delivery Group is done on the Machine view, selecting the machine and then the option will be available.
With creating a machine catalog and a delivery group the basis is ready. Users could connect to the XenDesktop environment and use the (published) applications. However lots of other familiar XenApp components and/or parts are not touched in this article. I will discuss/describe those in an upcoming second part article.