XenApp 7.6 (formerly known as Presentation Server, MetaFrame, and WinFrame) is an application virtualization software built to deliver a secure and highly-customizable set of applications and desktops to end users regardless of their location or endpoint device type. XenApp's Virtual Delivery Agent (VDA) is installed on an RDS-enabled Windows Server OS, while the XenApp environment (also known as a farm or site) is managed by a Delivery Controller installed on a separate non-RDS Windows server. The applications can be installed on the XenApp VDA server, and a client software called Citrix Receiver needs to be deployed on the user's endpoint device to enable application launching. We will explore the XenApp architecture in further detail in Chapter 2, Designing a Citrix® Solution to Fit Your Needs, but, for now, it is important to remember (much like other enterprise software) that there is a management component (also known as a controller or broker) and a delivery agent. The communication between the two is vital for an operational environment. The following diagram illustrates the conceptual architecture of XenApp:
The XenApp conceptual architecture available at http://www.citrix.com/. © Citrix Systems, Inc.
XenApp 7.6 uses a proprietary Citrix communication protocol called ICA. ICA transmits data intercepted by XenApp from an application running on the server to the Citrix Receiver on the client device over standard network protocols, such as TCP/IP and, formerly, IPX/SPX. From the client side, when a user interacts with the application (for example, a mouse movement or keyboard input), the Receiver software on the client device circulates the traffic back to the application running on the XenApp server. Multiple virtual channels exist within the ICA protocol, such as multimedia, printing, USBs, smart cards, and others. These virtual channels define various functions within the ICA stream and different settings can be applied to control their impact based on the requirements of the environment. In Chapter 11, Administering a XenApp® Environment – Server Management, we will go into further details regarding Citrix group policies that can be implemented to manage application security and user experience. The following diagram illustrates the ICA protocol and virtual channels:
ICA protocol and virtual channels available at http://www.support.citrix.com. © Citrix Systems, Inc.
Citrix XenApp 7.6 uses the FlexCast Management Architecture (FMA), which is conceptually the same model used by Citrix XenDesktop. In fact, in 2013, Citrix merged the XenApp and XenDesktop technologies into a single delivery platform under the umbrella of XenDesktop 7.0. Starting with XenDesktop 7.0, you could deliver both applications and Virtual Desktop Infrastructure (VDI) from a single pane of glass. However, less than a year later, Citrix reintroduced XenApp as a standalone licensed product, which once again used the same integrated management model as XenDesktop FMA. You do not have to purchase XenDesktop licenses in order to use XenApp. The latter can also be deployed on both virtual machines and physical servers depending on the nature of the existing infrastructure.
Older versions of XenApp, such as 6.5, have a completely different design than 7.x releases. Pre-7.x XenApp uses Independent Management Architecture (IMA) as its operational platform. Citrix has since moved away from IMA and onto FMA, which is a more service-oriented multiproduct platform. If you've had previous experience with XenApp, you will find that 7.5 and 7.6 have a completely different look and feel than older versions. There have been significant changes in administration as well. Here are some examples of architectural modifications in 7.x:
Server management: Application delivery and farm administration is no longer managed from the XenApp server itself but rather from the Citrix Delivery Controller. Application and desktop configuration can also be configured by a server with the Citrix Studio console installed. The Delivery Controller's only unique roles are user access and optimization of connections.
Graphical User Interface (GUI): Citrix Studio (formerly known as Desktop Studio) has replaced the AppCenter and Delivery Services Console.
Database: XenApp no longer uses a local host cache, mirroring the data from the primary SQL data store to a local access database. FMA relies on the high-availability features set in the SQL server instead.
Provisioning methods: Machine Creation Services (MCS) can now be leveraged to provision XenApp servers from a single master image. Previously, they could only be deployed as standalone machines on a hypervisor or via Citrix Provisioning Services (PVS).
Agent software: The Virtual Desktop Agent has replaced the XenApp 6.5 software installed on a XenApp image.
XenApp 7.6 offers features that were either absent in 7.5 but present in 6.5 or nonexistent in previous versions altogether. Here is a list of the main new functions that can be enabled in 7.6:
Session PreLaunch (available in 6.5): This refers to sessions that are launched before users request them
Session Lingering (available in 6.5): This refers to sessions that are not terminated when a user disconnects from an application
Anonymous logon: This refers to credentials not being required in Citrix Receiver or StoreFront, and users can authenticate directly at the application level
Connection leasing: This refers to session information that is cached locally on the Delivery Controller so that if a SQL server outage occurs and the Delivery Controller loses connectivity to the site database, users who request new sessions can be connected to their applications and desktops
Cloud integration: This refers to XenApp servers that can be deployed and managed by cloud solutions, such as Citrix CloudPortal, Amazon Web Services (AWS), and Microsoft Azure
Citrix enables you to deliver resources to end users in a variety of ways. Which model fits your environment best will depend on the business purpose of your solution. There are three methods for application delivery via XenApp—hosted apps, streamed apps, and hosted shared desktops. Let's have a look at them:
Hosted apps: With this model, the application is installed on the XenApp server and will execute there as users launch instances of it on their client devices. The application will consume CPU and RAM on the server and multiple instances of the same process will appear in Task Manager.
Application streaming: In this delivery model, apps are packaged and streamed to the endpoint device via Microsoft App-V as part of the XenApp store. With this method, apps will execute and consume the compute resources of the endpoint device instead of the XenApp server.
Hosted shared desktops (HSD): This model is the right approach if the requirement of the environment is to present a full desktop to users instead of individual apps. With the hosted shared model, the XenApp server itself is presented to the end user as a full desktop launched from their Citrix Receiver and it can be shared among multiple users at the same time. The number of users that can utilize the desktop simultaneously is determined by the compute resources allocated to the server and the nature of the applications being run within this desktop. In Chapter 9, Administering a XenApp® Environment – Application Management, you will learn how to deploy the different models of application delivery with Citrix XenApp.
The XenDesktop model allows a user to have a dedicated OS and not share resources with other users by delivering a desktop to the user. The desktop can be pooled or private. Pooled desktops are nonpersistent and any changes made by the user outside of their profile are not retained upon reboot. Dedicated desktops are also assigned to a single user. All changes made by the user to the underlying system are retained after a reboot much like a physical computer when a personal vDisk is configured for users. Bear in mind that this approach is only available if you have a XenDesktop concurrent or user/device license.