XenDesktop 7.6 is the latest release of the Citrix desktop and application virtualization platform, strongly oriented to the mobile world and the Bring Your Own Device
way to work. It also manages different types of Cloud deployments. This gives the customer the ability to use their personal devices, with no loss in terms of security and data isolation. All the new functionalities introduced with this latest version have been discussed in the book's introduction.
In this chapter, we will discuss the implementation of the Machine Creation Service (MCS) and the
Provisioning Services (PVS) architectures. We will also discuss how to upgrade from XenDesktop Version 5.6 to Version 7.6, including the Provisioning Services 7.6 component. After this, you will learn how to install a XenDesktop 7.6 infrastructure from scratch, configuring the most important and required components such as the database server, the licensing components, and the web access portal for users, StoreFront 2.6. StoreFront 2.6 is the evolution of the previous existing StoreFront releases, and it is also the substitute of the old Citrix Web Interface platform.
The following are the prerequisites to install and configure a fully functioning XenDesktop 7.6 architecture:
- Operating Systems: Windows Server 2008 R2 SP1 (Standard Edition, Enterprise Edition, and Datacenter edition), Windows Server 2012 (Standard and Datacenter editions), and Windows Server 2012 R2 (Standard and Datacenter Editions).
Note
For the Citrix Studio and the Virtual Delivery Agent, Windows 8 / 8.1 and Windows 7 (Ultimate, Professional, and Enterprise) are also supported as operating systems.
- Microsoft .NET Framework 3.5 SP1 (Windows Server 2008 R2) and Microsoft .NET Framework 4.5.1 and 4.5.2.
- Windows PowerShell 2.0 (included in Windows Server 2008 R2) and Windows PowerShell 3.0 (included in Windows Server 2012 and 2012 R2).
- Visual C++ 2005, 2008 SP1 and 2010 Redistributable packages.
- Required disk space: At least 100 MB for the Delivery Controller, at least 75 MB for the Studio platform, at least 50 MB for the Citrix Director, and at least 40 MB for the License Server.
- At least Microsoft Internet Information Services (IIS) 7.0 Version as Web or application server.
Citrix customers can choose between two deployment mechanisms: MCS, which consists of hosted desktops and applications published to users based on given accessibility permissions, or PVS, which consists of a single desktop or a pool of them, booted over a network and streamed on demand to end users.
In both cases, information is stored in a Citrix database repository, based on Microsoft SQL Server. It is used and populated with data coming from the main architectural components. In this book, we will discuss in detail about all of them.
Note
Starting from the XenDesktop 7 edition, you can deliver both desktop and server operating system images, virtually or physically, thanks to the union with the XenApp platform and its changes, which are now based on the Flexcast Management Architecture (FMA) rather than the Independent Management Architecture (IMA).
Configured resources such as virtual desktops can be accessed by end users through a web portal called
StoreFront, the substitute of the old
Citrix Web Interface, which permits publishing online stores with the applications and the desktops published to the end users.
MCS and PVS architectures can be combined together and used within the same company for different desktop distribution areas. This is the implementation of the
Flexcast technique, the methodology that applies different Citrix products and configurations together, based on the requirements of specific company areas or customized architectures for specific teams.
Tip
As generic reference, for a number of delivered virtual desktops nearer to or greater than 500, you should always consider using PVS architecture in order to avoid global performance and maintenance issues.
The main goal of this recipe is for you to understand the differences between the two main kinds of architectures: MCS and PVS. Once you have understood this, you will be able to better comprehend what and how to implement a consistent XenDesktop installation in line with your user/company requirements.
Starting from the database server and licensing configuration, along the chapter we will walk through XenDesktop components, StoreFront, and the configuration of provisioning service architecture.
The first implementable deployment is MCS. Its most important part is based on hosted virtual desktops.
How can we choose if MCS is the better solution for us? We have a set of main parameters to decide listed here:
- MCS is the right solution if we only want to deploy a virtualized desktop infrastructure, both client and server operating systems.
- As a general reference, we should choose MCS with a number of deployed desktops lower than 500.
- It is better to use MCS when we need to frequently upgrade base images. Despite the complexity of the operations required with the use of the PVS architecture, this is a quite simple process in terms of operations for machine creation platforms.
Note
Cons for the MCS configuration are I/O intensive, more storage per single VM despite the PVS infrastructure, and higher time to update images in the presence of an elevated number of desktops.
- Consider implementing this architecture when you have a shared storage like Network File System (NFS) or Storage Area Network (SAN); especially in the second case, it's preferable to have MCS architecture, thanks to its large Input/Output Operations Per Second (IOPS) capacity.
To implement a pure MCS architecture, you need the following XenDesktop components:
- Director
- Delivery Controller
- Studio
- StoreFront
- Licensing Service
- SQL Server database
Note
Even if not explicitly specified, you need a Hypervisor platform to create the virtualized resources.
The second kind of XenDesktop infrastructure is PVS, a Citrix implementation fully based on desktop streaming technology.
PVS is the right choice in the following cases:
- When you need to provide the users with not only hosted desktops, but also streamed physical workstations.
- In the case of physical machines, PVS is the only available solution.
- When we have more than one site with a number of desktops per location between 500 and 1,500 per PVS server.
- When we do not have a shared storage or we are faced with low performance storage areas. In this case, we will take advantage of PVS memory caching activity.
- When we have many users logging on or logging off simultaneously. This is known as the I/O boot storm phenomenon; choosing PVS, we can avoid this problem by passing storage constraints.
Note
Cons for the PVS infrastructure are possible network boot storm, and network traffic have to be separated and isolated from the company network traffic to avoid bottlenecks.
To implement PVS instead of MCS, you must configure these components in your architecture:
- Director
- Delivery Controller
- Studio
- StoreFront
- Licensing Services
- Citrix Provisioning Services
- Provisioning Service database
Tip
You should consider combining MCS and PVS together, especially in cases where your architecture has the right balance of RAM quantity and storage performance. This is what Citrix calls Flexcast approach, a way to combine different architectures to satisfy all the requirements for a set of different end user's topologies.