The design of a XenApp infrastructure is a complex task that requires good knowledge of XenApp components. Making the right decisions in the design phase may also greatly help system administrators to expand XenApp farms to satisfy new business requirements or to improve the user experience.
In this chapter, you will learn about the following:
The key features of the new FlexCast Management Architecture
The five-layer model
Sizing each layer's components
Implementing and using Machine Creation Services to deploy new worker servers in minutes
The difference between XenApp 6.5 and 7.5
With XenApp 7.5, Citrix adopted the same architecture that was introduced in XenDesktop 5 and refined in XenDesktop 7, namely, FlexCast Management Architecture (FMA).
FMA is primarily made up of Delivery Controllers and agents. Delivery agents are installed on all virtual and/or physical machines that host and publish resources (named worker servers), while the controllers manage users, resources, configurations, and store them in a central SQL server database.
Unlike the previous versions of XenApp, the delivery agent now communicates only with the controllers in the Site and does not need to access the Site's database or license server directly, as illustrated in the following figure:
The main advantage of this architectural change is that now only one underlying infrastructure is used by XenApp and XenDesktop. Therefore, the overall solution might include both published applications and virtual desktops, leveraging the same infrastructure elements.
XenApp administrators who have moved to version 7.5 might be a bit confused; there are no more zones or data collectors. By the end of this chapter, you will find a table that maps concepts and terms from XenApp 6.x to the new ones in XenApp 7.5.
When designing a new infrastructure, a common mistake is trying to focus on everything at once. A better and suggested approach is to divide the solution into layers and then analyze, size, and make decisions, one level at a time.
FlexCast Management Architecture can be divided into the following five layers:
The power of a FlexCast architecture is that it's extremely flexible; different users can have their own set of policies and resources, but everything is managed by a single, integrated control layer, as shown in the following figure:
What users need access to (business applications, a personalized desktop environment, and so on)
What endpoints the users will use (personal devices, thin clients, smartphones, and so on)
Where users connect from (company's internal network, unreliable external networks, and so on)
User groups can access more than one resource at a time. For example, office workers can access a shared desktop environment with some common office applications that are installed, and in addition, use some hosted applications.
StoreFront (Web Interface 5.4 is still supported to offer customers additional time to migrate to StoreFront)
The following figure demonstrates the access layer:
Internal users access a StoreFront store using Citrix Receiver that is installed on their endpoints or via the StoreFront web interface. StoreFront also offers a receiver for HTML5 that does not require any installation on the user's device.
StoreFront requires Windows 2008 R2 SP1 or later, with Microsoft Internet Information Services (IIS) and the .NET framework. Even if it can be installed on a server that runs other components, my suggestion is to install it on at least two dedicated servers with a load balancer in front of them to provide high availability.
StoreFront is the entry point of your XenApp infrastructure. To correctly size its servers, you will need to estimate or measure the maximum number of concurrent logins (if your infrastructure mainly serves internal users, most of the logins will happen in the morning, when users arrive at office).
From my experience, StoreFront does not require a lot of hardware resources: a server with two CPUs and 4 GB of memory is enough for up to 1,000 user connections per hour.
Remote users connect and authenticate to NetScaler Gateway, which is located within the network's DMZ.
NetScaler Gateway is available both as a hardware appliance (MPX) and a virtual appliance (VPX); the virtual appliance delivers the same features and functionalities as that of the physical one. The main difference between VPX and MPX is about SSL; MPX has dedicated offload capabilities.
An MPX appliance has a single, dual-core processor and 4 GB of memory, while the virtual appliance that can be run on VMware ESXi, Microsoft Hyper-V, and XenServer, requires at least 2 virtual CPUs, 4 GB of memory and 20 GB of disk space.
NetScaler Gateway establishes a secure SSL channel with the user's device, and all the traffic is encapsulated in that channel.
Upon successful validation, NetScaler forwards the user request to the internal StoreFront servers that then generates a list of the available resources that is passed back to the user through NetScaler Gateway.
When the user launches a resource, all the traffic between the server that hosts the resource and the user's device is again encapsulated in the SSL channel.
To provide high availability, you can deploy two NetScaler Gateway appliances in a failover clustering configuration; so, if the primary active appliance fails, the secondary one becomes active. The HA feature is native and part of the NetScaler license; it does not require any external clustering solutions (Microsoft Cluster…).
In most environments, there are different security policies based on the users' locations; for example, users in the internal network can authenticate using only the username and password, while external users might need to enter a token code as well (multifactor authentication).
In NetScaler Gateway, you can configure session policies to differentiate between incoming connections by analyzing elements such as IP addresses, HTTP headers, SSL certificates, and so on. Moreover, you can also combine different expressions using logical operators (OR and AND), use built-in functions to test whether the client is running the most updated antivirus, and perform string matching with the power of regular expressions.
Policies do not take actions. They provide the logic to evaluate traffic. To perform an operation based on a policy's evaluation, you have to configure actions and profiles and associate them with policies. Policies can be applied at user, group, and server levels; all the applicable policies are inspected, and the one with the lowest priority wins.
Actions are steps that NetScaler takes; for example, you can allow an incoming connection if it matches the associated policy and deny it if not.
Profiles are collections of settings, for example, the session timeout (in minutes) or the Web interface / Storefront server URL.
To help system administrators create the correct policies and profiles for most common clients (Citrix Receiver, Receiver for Web, Clientless Access, and so on), Quick Configuration Wizard is automatically executed the first time you configure NetScaler Gateway.
XenApp offers different strategies to deliver applications. The choice of the correct strategy has a high impact on the infrastructure. Later in this chapter, you'll learn how to size the servers based on the number and type of applications.
Hosting apps is the most common strategy: applications are installed and published on servers with a delivery agent installed (worker servers). Each application is assigned to a delivery group; when accessed, the application executes on the hosting server, and the user interface is displayed on the user's desktop. This is the best approach for standard, business applications.
Some applications might not run on server-based operating systems such as Windows 2012. They have particular license or software requirements that conflict with other installed applications. Using the VM-hosted apps strategy, these applications are installed on virtual machines based on client-operating systems (such as Windows 7). When a user requires one of the applications, it runs on the VM, and its user interface is displayed on the user's desktop.
Because applications are installed on a client-operating system that does not support more than one user connected at a time, you need at least one VM for each concurrent execution of the hosted application.
Applications are not installed on the server or user's desktop. Using a solution such as Microsoft App-V or VMware ThinApp, they are dynamically delivered to the target server or desktop when accessed. Such solutions require an external infrastructure. They are normally chosen when there are a large number of different applications to be delivered or when applications are resource-intensive; therefore, they must be run on the end user's device. Applications have to be carefully evaluated and packaged prior to streaming; refer to Microsoft and VMware's documentation for more detailed information.
Users connect to a hosted server-based Windows operating system where the virtual machine is shared among a pool of users simultaneously. In this scenario, each user is encapsulated within their own session, and the desktop interface is remotely displayed.
Users connect to their physical office desktops, allowing them to work at any time. Remote PC Access uses the Citrix HDX policies and access layer, providing better security and performance over a simple RDP connection. Moreover, the connections can be managed using the centralized delivery console.
A Delivery Controller is the heart of a XenApp infrastructure; it is queried when a user logs in, when it launches an application, and when policies are evaluated. It's therefore important to correctly size the servers that host this component.
The minimum requirements are as follows:
2 vCPU and 4 GB of memory
100 MB of disk space to install the software
Windows 2008 R2 Service Pack 1 or later
In my experience, Delivery Controllers consume a lot of CPU memory; this is especially true in those moments of the day (for example, in the morning) when most of the users start working. If the CPU of the Delivery Controllers' servers reaches a critical threshold, roughly 80 percent, you need to scale up or scale out.
If you're using a virtualized environment, it could be easy to add virtual CPUs to the servers; an alternative is to add another controller to the Site configuration.
Your infrastructure should have at least two Delivery Controllers to provide high availability. You can add more Delivery Controllers and the load will be evenly distributed across all the controllers, thus helping to reduce the overall load on each single controller.
In a virtualized environment, the controllers should be distributed across multiple physical servers to help spread the CPU load across multiple servers and provide greater levels of fault tolerance. On VMware, for example, you can configure an anti-affinity rule to ensure the virtual servers would never be placed on the same physical one.
SQL Server 2008 R2 SP2 Express, Standard, Enterprise, and Datacenter editions
SQL Server 2012 SP1 Express, Standard, Enterprise, and Datacenter editions
If no SQL Server is found, SQL Server 2012 SP1 Express Edition is installed during the installation of the first controller of your Site. The use of the free Express Edition is, however, suitable only for small installations (less than 100 users).
To provide high availability, XenApp 7.5 supports the following SQL Server features:
AlwaysOn Availability Groups (SQL Server 2012 only)
By default, the Configuration Logging and Monitoring databases (usually called as the secondary databases) are located on the same server as the Site Configuration database. Initially, a single database is used for all the three datastores, as shown in the following screenshot:
If the Site database becomes unavailable, the system is unable to accept new users, while the existing connections are maintained.
Delivery Controllers don't have Local Host Cache (LHC) like the datastore servers had in previous versions of XenApp. Thanks to LHC, the infrastructure could be run even if the database server is unavailable; with the absence of LHC in XenApp 7.5, the database server has become a more critical element of the infrastructure.
The maximum size is usually reached after 48 hours as a small log of connections is maintained within the Site database for two days.
From my experience, the Site database does not require much storage. A typical storage requirement is as follows (refer to http://support.citrix.com/article/CTX139508):
Number of users
Number of applications
The retention period depends on the XenApp license you own:
For non-platinum customers, the default and maximum period is seven days
For platinum customers, the default period is 90 days with no maximum period
Updates to the Monitoring database are performed in batches and the number of transactions per second is usually low (less than 20). Overnight processing is performed to remove obsolete data.
Of the three databases, the Monitoring database is expected to grow the largest over time. Its size depends on many factors; anyway, a realistic estimation is that 1,000 users working 5 days/week generate 20-30 MB of data each week.
The size and transaction rate are hard to predict; they depend on how much configuration activity is performed. This is usually the smallest and least-loaded database of the three.
The administrator can configure the Site database to accept or refuse configuration changes when the Configuration Logging database is unavailable, as shown in the following screenshot:
Select Configuration on the left-hand side of the pane.
Select the database you want to change the location for.
Click on Change Database in the Actions pane.
Specify the location of the new database server.
If you specify a new location, remember that the data in the previous database is not imported to the new one and that logs cannot be aggregated from both the databases.
You can also migrate the databases from the actual database server to the new one without losing data. First, you must stop configuration logging and monitoring to make sure that no new data is written to the database during the move.
Then, start Windows PowerShell and type the following commands:
PS C:\> asnp Citrix* PS C:\> Set-LogSite -State "Disabled" PS C:\> Set-MonitorConfiguration -DataCollectionEnabled $False
Now, you can back up the existing databases and restore them onto the new server.
After having configured the new database location as explained earlier, remember to enable configuration logging and monitoring again with the following commands:
PS C:\> Set-LogSite -State "Enabled" PS C:\> Set-MonitorConfiguration -DataCollectionEnabled $True
If your infrastructure grows and more controllers are brought online, the SQL database CPU will eventually become a bottleneck.
Scale out: This is used to create a second XenApp Site alongside the initial one. Note that each Site would be semi-independent of each other; some components may be shared (such as the access layer), but the controllers and the SQL databases would only function within their own Site.
The license server stores and manages Citrix licenses. The first time a user connects to a XenApp server, the server checks out a license for the user, and subsequent connections of the same user share the same license.
A single license server is enough for Sites with thousands of servers and users; you could install a second license server in your Site, but the two servers cannot share licenses. Because the license server is contacted when the user connects to a XenApp server, slow responses will ensue and might increase the login time. You should place the license service on a dedicated server or, in the case of smaller infrastructures, on a server that doesn't publish applications. The license server process is single-threaded, so multiple processors do not increase its performance.
If the license server is not available, all the servers in your Site enter a grace period of 720 hours; during this period, users are still allowed to connect. This means that you usually don't need a high-availability solution for your license server; if a server fault occurs, you can install a new license server during the 30 days of the grace period or power on a second license server you prepared and kept turned off (cold standby).
The hardware layer is the physical implementation of the XenApp solution. After having collected all of the required information for previous layers, we're now ready to choose the correct number of servers and their hardware configuration.
One for the resource layer
One for the access and control layers
For server-hosted resources (hosted apps, shared desktops, and VM-hosted apps), a set of physical or virtual machines is required.
VM-hosted apps run on client-operating systems, and each user must be provided with a dedicated machine; therefore, the number of machines depend on the number of concurrent users. For hosted apps or shared desktops, the number of servers you need and their hardware configuration depends on the number of users and applications, and even more on the kind of the applications and how you deliver them to the users.
The use of a virtual infrastructure is highly recommended; it lets you quickly reallocate resources (CPU, memory, and so on) if required. Later in this chapter, you'll learn how to use a new delivery fabric solution by Citrix, Machine Creation Services (MCS), to deploy new servers in minutes, working together with your virtualization technology.
My suggestion for correctly sizing your infrastructure is to set up a test environment where you can verify the load that each application produces using real users or automatic testing tools such as LoginVSI or HP Loadrunner (Citrix EdgeSight for load testing is now deprecated and no longer supported).
With XenApp 7.5, the hardware layer can also include cloud-hosted desktops and apps with the integration of Amazon AWS, CloudPlatform, and Microsoft Azure.
Amazon AWS only supports Server OS machines.
I found out that the new delivery agent is lighter in weight than the IMA service installed on session host servers in XenApp 6.5; therefore, you might save some hardware resources when moving to the new 7.5 version.
In this approach, applications are installed on small groups of servers; you could even have the servers running a single application. Applications are usually grouped by their use; for example, all the applications used by the Finance department are installed on the same servers, while the applications used by the HR department are installed on different servers.
This approach is sometimes required if your applications have different hardware requirements or might cause conflicts if installed on the same server. Some application vendors, moreover, don't consider a different licensing agreement if their applications are published through XenApp. So, if you pay licensing fees, by simply counting the number of installations, you might reduce the cost of installing them on a small number of servers.
Siloed applications can increase costs as they require more resources for standby; they require more hot spare servers (at least one for each silo) than the nonsiloed approach. If silos are necessary for isolation, you can consider using app streaming.
In this approach, all the applications are installed on all the servers. This approach is more efficient as it reduces the number of required servers, and it may also improve the user experience because it allows users to share the same server session with different applications. If you're using any automatic technology to deploy servers, a nonsiloed approach will also help you to reduce the number of different images you have to create and maintain.
My suggestion is to use the nonsiloed approach when possible. Later in this book, you'll learn that with session machine catalogs and delivery groups, you will still be able to logically group applications on servers even with this approach.
A typical XenApp 7.5 infrastructure has a couple of Storefront servers, a couple of Delivery Controllers, one license server, and one database server (clustered to provide high availability). If you have external users, a VPN solution (NetScaler Gateway or third-party products) is usually added.
When sizing the infrastructure, consider that Storefront and Delivery Controller servers can be easily scaled out by adding new servers, while you can't have two active database servers in your Site to balance the load or add another database server to your Site. Moreover, if you're using a shared database server (for example, a database server that is also hosting some production databases), pay attention to the fact that the load generated by XenApp will not be smooth during the day, but it will probably have peaks in the morning and after lunchtime.
Even if Citrix supports the installation of a Delivery Controller, license server, and Storefront on the same server (and this is the default option during the setup), my suggestion is, wherever possible, to use different servers; better if these servers are virtualized. If your virtualized environment has built-in HA functionalities (such as VMware HA or Hyper-V clustering), you might deploy only one Delivery Controller and one Storefront server to start and then add new servers if needed.
Storage is often considered as one of the most important and complex decisions in a XenApp or XenDesktop solution.
Storage is not only the amount of disk space that must be allocated to the solution but also the number of Input/Output Operations (IOPS) that must be available in order to provide a good user experience.
It might seem strange at first, but when you're choosing the correct storage solution for your new infrastructure, the most critical information is the maximum number of IOPS the storage platform you're evaluating can offer. All the storage systems can indeed be updated to add more disk space, while the maximum number of IOPS can be limited by the type of connection (fiber-channel, iSCSI, and so on), its speed, or the storage controllers, elements that are difficult or expensive to replace when in production.
As a rule of thumb, you can consider 10-15 IOPS for each virtual desktop-running office applications and 5-8 IOPS for each user-running applications on worker servers.
You can use the free Iometer tool (http://www.iometer.org) to test the performance of your storage's subsystem.
An example of using the Iometer tool is shown in the following screenshot:
Infrastructures are not static; they evolve to satisfy new business requirements, offer new applications, or support new users.
A common task that every Citrix administrator has to face is to deploy, as fast as he or she can, new worker servers. Citrix offers the following two technologies to automatically provide new servers, starting with a master image:
Provisioning Services (PVS)
Machine Creation Services (MCS)
Servers are delivered from a Provisioning Services virtual disk (vDisk), imaged from a master device. Target servers are configured to perform a network boot and receive the vDisk image from the PVS server. vDisks are usually configured in the read-only mode; local changes are discarded at every reboot.
Provisioning Services works with almost any device and does not require any virtualization technology. The target servers can be physical, virtual, or a mix of both.
Machine Creation Services was introduced in XenDesktop 5, and now, with the adoption of FlexCast Management Architecture, it is also available for XenApp infrastructures.
Both Provisioning Services and Machine Creation Services are enterprise solutions included in XenApp 7.5.
PVS is usually preferable in a mixed infrastructure that also includes a large number (less than 2,000) of virtual desktops. PVS is also preferable because MCS requires more IOPS (about 21 percent) than PVS and potentially more storage space.
Persistency, that is, the need to maintain changes for different targets forced the use of MCS in the past. The reason was that PVS prior to version 6.0 only had server-side caching that caused several performance issues. Now, both the technologies offer client-side caching.
It does not require any dedicated servers like PVS does
It takes advantage of virtualization features such as snapshots
It is integrated in Citrix Studio (PVS requires a dedicated console)
It does not use the network to deploy the servers (PVS can generate high traffic on the network)
Citrix documented that MCS generates approximately 45 percent of more peak IOPS compared to PVS. The reason is that during the boot and logon phases, all the virtual machines created by MCS access a shared copy of the master image, and servers that are provisioned by PVS get the needed data through the network instead.
The typical R/W (read/write) ratio for Windows MCS machines during the various phases is as shown in the following diagram:
After the first start of a virtual machine, IntelliCache uses the local storage cache of the server to cache blocks of the base image as far as they are accessed by the virtual desktop. If a second VM is started on the host, it uses the already cached bits on local storage and does not need to reach out to the shared storage.
IntelliCache also caches temporary and nonpersistent files; this means that a portion of a runtime read/write of each virtual machine might occur in a low cost server-attached storage rather than the consumption of IOPS resources of your storage area's network.
First, you have to enable IntelliCache when installing XenServer, choosing Enable thin provisioning (Optimized storage for XenDesktop).
You can also enable thin provisioning on an existing XenServer; refer to Citrix's installation guide (http://support.citrix.com/article/CTX129387).
IntelliCache is disabled by default in XenApp or XenDesktop. When you are adding a XenServer host and are prompted for the type of storage to use, select Shared; then, select Use IntelliCache to reduce load on the shared storage device, as shown in the following screenshot:
VMware vSphere 5 includes a feature named Content-Based Read Cache (CBRC) that is similar to IntelliCache. With this feature, you can have the host hypervisor scan the storage disk blocks to generate digests of the block contents. When these blocks are read into the hypervisor, they are cached in the host-based CBRC, and subsequent reads of blocks with the same digest are served from the in-memory cache directly.
Even if CBRC is not officially supported by Citrix, it can be used to optimize IO workloads when using MCS with VMware virtual infrastructures.
Citrix XenServer 6.0.2 or higher
VMware vSphere 5.0 update 2 or higher
System Center Virtual Machine Manager 2012 or higher (includes any version of Hyper-V that can register with the supported System Center Virtual Machine Manager versions)
Yes (with cluster-shared volumes)
Select the hypervisor you're using and enter the credentials for the connection, as shown in the following screenshot:
Select the resources (cluster, network, and storage) for the new connection and complete the wizard.
If you're using self-signed SSL certificates in your VMware vCenter, you might encounter an error message: Cannot connect to the vCenter server due to a certificate error.
Connect to your vCenter server and copy the
Open Microsoft Management Console (
mmc.exe) in your controller server and add the Certificates snap-in to manage certificates for the local computer account.
cacert.pemfile in the Trusted Root Certification Authorities folder, as shown in the following screenshot:
If you're using Microsoft KMS (Key Management Services) to manage Windows and Office licenses, you don't need to manually launch the rearm process (
slmgr.vbs) or run the
sysprep.exe command on the master image.
Create a new virtual machine using the management tool for your hypervisor and install the operating system, including service packs and updates. The number of vCPUs and the amount of memory you assign to the virtual machine is not critical; you can change these settings when you create a machine catalog. It's important to choose the correct amount of disk space, including the space that will be required for applications and users' data (if you're not using a profile management solution) because it cannot be changed later.
When installing VDA, select Create a Master Image, enter the addresses of your Delivery Controllers, and enable the Optimize performance feature, as shown in the following screenshot:
Install and configure the applications you're going to deliver using XenApp and any third-party tools needed in your infrastructure, such as antivirus software or management agents. Make sure those tools can be installed in machines deployed from a single image; some agents create a unique identifier (UUID) when you install them, and if all your servers are created from a single installation, they'll have the same UUID. Sometimes, you might need to write a startup script for your servers that will change the agent's UUID (usually stored in Windows Registry).
When the master image is complete, Citrix recommends that you create a snapshot of it and name the snapshot so that you can identify the master image in future. If you specify a master image rather than a snapshot when creating a machine catalog, Studio creates a snapshot for you but you cannot name it.
A machine catalog can be configured to use MCS to create the number of VMs you specify based on the master image you created in previous sections.
In Citrix Studio, select Machine Catalogs on the left-hand side pane and then click on Create Machine Catalog in the Actions pane.
Select the appropriate operating system for your machine catalog; if you're going to deliver applications using XenApp, choose Windows Server OS.
You're now prompted to select the machine management tool that your catalog will use. Choose Machines that are power managed (this means you want to use a machine management tool) and Deploy machines using Citrix Machine Creation Service, as shown in the following screenshot:
Select the virtual machine (or one of its snapshots) that will become the master image of your catalog:
Define the number of virtual machines needed in the new catalog along with their resources, as shown in the following screenshot (the number of vCPUs and the amount of memory). Note that the hard disk size cannot be changed.
The new virtual machines require an Active Directory computer account. If you have access to an Active Directory domain admin account, you can allow Studio to create new accounts for you by performing the following steps:
If you can't create accounts in your Active Directory, you can select unused accounts that already exist (or that someone created for you), or you can import a
.csv file that contains the list of account names in the following form:
[ADComputerAccount] accountname1.domain accountname2.domain
MCS can reset the account passwords, or if all the accounts share the same password, you can specify it.
This scheme can consist of fixed characters and a variable part defined by the
# characters. A scheme can include only one variable part, and you can define it to be either numeric (1, 2,…) or alphabetic (A, B,…). The number of hash characters defines the minimum length of the variable region; for example, a naming scheme of
WorkServer## will result in accounts called WorkServers01, WorkServer02 or WorkServerAA, WorkServerAB.
The characters not allowed in a naming scheme are
If your master image has more than one network card, you can enable/disable the network cards and associate them to the correct virtual network.
At the end of the wizard, MCS copies the master image to the datastores you configured as resources for the connection to your virtual infrastructure and creates the requested number of virtual machines.
Machine Catalog is now ready to deliver applications, as shown in the following screenshot:
You can use the Test Machine Catalog action to verify that the new Machine Catalog is properly configured.
If you need to perform an update (for example, install OS patches) or install new applications, you can perform the requested changes on the master image, take a new snapshot (so you can always return to the previous image if something goes wrong), and with a configurable rollout strategy, update the catalog's virtual machines based on the new snapshot.
After having updated the master image, choose the catalog to be updated and select Update Machines from the Actions pane.
Select the new snapshot and define a rollout strategy, either in the following situations:
On the next shutdown
Immediately (shut down and restart the machine now)
If you chose Immediately, you can program a distribution time (that is the interval within which the machines are restarted) and send a notification message to the users (for example, warning them to close all the running applications).
Many XenApp administrators who worked with previous versions of XenApp were a bit confused when Citrix decided to adopt the same FlexCast Management Architecture that was introduced in XenDesktop 7 for XenApp 7.5.
Independent Management Architecture (IMA)
FlexCast Management Architecture (FMA)
Delivery Site (or just "Site")
Session Machine Catalog plus Delivery Group
Worker with virtual delivery agent
Zone and data collector
Delivery Services Console
Citrix Studio and Citrix Director
SQL Server database
Load Management Policy
With XenApp 7.5, Citrix adopted the new FlexCast Management Architecture that was previously introduced for XenDesktop, and now your solution might include both published applications and virtual desktops, leveraging on the same management infrastructure.
A XenApp architecture is made by several components: StoreFront servers, NetScaler Access Gateways, Delivery Controllers, license servers, worker servers, and database servers. All contribute to the correct working of the solution. In this chapter, you learned how to correctly size them based on your business requirements and how to design an infrastructure based on the five-layer model.
If you need to deploy several worker servers, you should consider using Citrix Machine Creation Services. With this tool, you can create a master virtual image of your server and use it to provision as many servers as you need. Day-by-day management is also made easier; updates, patches, and changes have to be applied to the master image only.
If you're an experienced XenApp administrator and have worked with previous versions of XenApp, the new FlexCast Management Architecture may be confusing; at the end of this chapter, I have included a table comparing the terms and technologies of the older versions with the new ones introduced in XenApp 7.5.
In the next chapter, you'll learn how to monitor and optimize the infrastructure when in production.