Design Considerations

XenServer 5

Worldwide Consulting Solutions

Simplifying the Migration to XenApp 5

Overview
XenApp migrations are a major event within an organization resulting in the potential of hundreds of servers being
updated impacting thousands of users. Finding ways to simplify the process and reduce the risk potential often associated
with a XenApp migration is possible with server virtualization and provisioning with XenServer. A set of materials have
been created to demonstrate the solution and explain how the solution functions.
 Reference Architecture
 Getting Started Guide
 Implementation Guide
The aforementioned articles are based on a single scenario. Trying to create a similar solution in other organizations
requires an understanding of a few key design considerations. As with any XenApp migration, there are many decisions to
make just on the XenApp side of things including whether to upgrade, migrate or build a new XenApp farm. With the
integration of XenServer into the mix, additional design considerations should be taken into account. These
considerations will help create an architecture that meets the goals of the migration as well as creating a simplified
environment to manage and maintain.

XenServer Considerations
The first area of consideration is the hypervisor, Citrix XenServer 5. The considerations focus on to get the most out of
the hardware and how to setup the environment so it is easy to manage. These considerations focus on the following
areas:
 Minimizing the Hardware Footprint
 Tags
 Templates

Minimizing the Hardware Footprint

One on the major benefits of server virtualization is hardware consolidation. During a XenApp migration, hardware
sprawl is a concern. Take, for example, a migration to XenApp 5 on Windows Server 2008. In a physical XenApp
environment, the migration would take an extended amount of time if no new hardware was utilized because taking a
handful of servers out of production for the upgrade would too greatly impact the users. However, if the XenApp
migration included XenServer virtualization, the migration speed can be increased as shown in the following figure.
 2

First Round

XenServer 1
- VM-1
- VM-2

XenApp 1 XenApp 2

Second Round

XenServer 2 XenServer 1 XenServer 3

- VM-3 - VM-1 - VM-5
- VM-4 - VM-2 - VM-6

XenApp 3 XenApp 4 XenApp 5 XenApp 6

Third Round

XenServer 4 XenServer 5 XenServer 2 XenServer 1 XenServer 3 XenServer 6 XenServer 7

- VM-7 - VM-9 - VM-3 - VM-1 - VM-5 - VM-11 - VM-13
- VM-8 - VM-10 - VM-4 - VM-2 - VM-6 - VM-12 - VM-14

XenApp 7 XenApp 8 XenApp 9 XenApp 10 XenApp 11 XenApp 12 XenApp 13 XenApp 14

During the first round, one XenApp server is converted to XenServer. Instead of streaming one XenApp image onto
the single XenServer, two virtual XenApp servers could be streamed instead, assuming the XenApp servers are not
fully utilized. After the first round, two physical XenApp servers have been virtualized, which frees up two physical
servers that can be reinstalled with XenServer. Assuming each XenServer can support two virtual XenApp servers,
four more XenApp servers are virtualized in the second round, freeing up four more physical servers. After only a few
short rounds, an entire group of XenApp servers can be virtualized.
This approach also helps mitigate the risk in the event of an issue because only a few servers are migrated at a time. It
also helps to reduce the challenges of supporting a mixed environment spanning multiple XenApp versions because
the migration happens faster than a physical XenApp migration.

XenServer Tags
After XenApp servers start to populate the XenCenter console, it will be apparent the list will become unmanageable.
Even with standard naming conventions based on the XenApp role, the list will become quite extensive. With
XenServer tags, a very simple solution, the list can be customized to focus on a set of servers carrying out identical
tasks. For instance, with tags, an administrator can only look at servers hosting a certain application on XenApp 5
running Windows Server 2008. Some recommended tag categories are:
Category Example
Server Operating System Windows Server 2008
Windows Server 2003
Citrix Product and Version XenApp 5
XenApp 4.5
Provisioning Server 5
XenServer 5
Server Role Core Applications
 3

Manufacturing Applications
DHCP
DNS
Zone Data Collector

Once tags are created and applied to the virtual servers, a quick search will show a list of all virtual servers matching
the custom criteria. This search will be able to show CPU, memory, disk and network utilization from a single view.
Best Practices:
 Create and apply tags to each server within the XenServer environment.
 Name XenServer tags similar to Provisioning Server device collection names.
 Each server should be tagged with at least three items: Operating System, Citrix product and server role

XenServer Template
With each XenServer virtual machine, there are a few options that should be set in order for the virtual server to be
optimized for the environment. Although it is easy to configure these options for each server, it is time consuming and
prone to errors. For example, if a XenApp virtual machine is not optimized for XenApp, XenServer scalability will
degrade. This setting, as well as a few others, should always be set for XenApp workloads.
Creating a template for XenApp servers will help automatically set these settings for each new XenApp virtual
machine. When integrated with Provisioning Server, a XenApp virtual machine should have the following settings
applied:
 No Virtual Disk: There is no need for an assigned virtual disk because the virtual machine will receive the
XenApp build from Provisioning Server via a network stream.
 Optimized: Each XenApp server should be optimized for the XenApp workload. This information can be part of
the XenApp template
 Tags: XenServer tags are a great way to help manage the long list of virtual machines through categories. A
XenApp template can include the base tags like operating system and XenApp version.
 Startup Options: If Provisioning Server is used, the template should be set with the correct boot order:
Network, DVD and Hard Disk.
Best Practices
 Create a XenServer Template for the XenApp virtual machines.

Provisioning Server Considerations

The second set of considerations revolves around server provisioning with Provisioning Server 5. The recommendations
focus on designing a structure within Provisioning Server that is manageable and understandable. As the number of
XenApp servers increase, the more target devices Provisioning Server will maintain. This list might become
unmanageable if it is not logically designed.
These considerations focus on the following areas:
 Device Collections
 Collection Template
 Auto Add Target Devices
 4

Device Collections
The number of Provisioning Server target devices in a production environment could include hundreds of XenApp
servers. Trying to remember the workload for each specific server is a daunting task. To better manage the
architecture and make it easier to update identical XenApp servers, use Provisioning Server Device Collections.

Figure 1: Device Collection

Based on Figure 1, we can quickly see there are four different sets of target devices for the environment:
 XenApp 5 – Data Collectors
 XenApp 5 – Core Applications
 XenApp 5 – CRM Application
 XenApp 5 – Manufacturing Applications
If we need to manage the Core Applications, we only work with the XenApp 5 - Core Applications collection. For a
XenApp environment, each collection would correspond to a Provisioning Server vDisk. Every target device within the
collection should point to the same vDisk. When updates are required, we have a simple view into the target devices
being affected.
Best Practice:
 Create a Collection Template for each XenApp role

Collection Template
Going hand-in-hand with Device Collections are Collection Templates. Like stated before, each collection is
responsible for delivering the same set of applications. The configurations of each target device within a collection
should also be similar, or else we end up with inconsistency, which is a hallmark of a poor XenApp design.
 5

A Collection Template creates a standard of target device properties from which other newly created target devices will
inherit.

Figure 2: Collection Template

Best Practice:
 Each Device Collection should have a Collection Template set. The Collection Template should include the
following items set:
o Class: A Class name will link target devices to vDisks to facilitate automatic updates
o Boot from: vDisk
o vDisks: The appropriate vDisk should be assigned to the template

Auto Add Target Devices

The link between a physical/virtual device with the defined target device within Provisioning Server is accomplished via
the MAC address. Populating the Provisioning Server database with each XenApp server’s MAC address can take a
lot of time and is prone to numerous errors. To simplify this task, Provisioning Server includes an Auto-Add feature.
In order for this feature to work, Auto-Add must be configured in the following locations:
 Farm-level: Auto-add must be enabled as a Provisioning Server farm option. Once it is enabled, a site must be
selected where new target devices will be added.
 Site-level: Within the site configuration, the auto-add functionality must be told which device collection to store
the new target device. If the device collection has an associated device template, the auto added target device
will take on the properties of the template.
 6

Once the target device is added, it can easily be moved to another device collection. Although auto-add is a great way
to populate the Provisioning Server database, it can create confusion if not done correctly. Many servers are set at the
factory to boot from the network. If the network booting options are not set, the servers will fall back to local disk
startup. This works well until Provisioning Server is added and starts responding to PXE boot requests. In this
scenario, if a non-XenApp server is set from the factory to boot from the network, it will receive a XenApp stream once
Provisioning Server is started because Provisioning Server is configured for Auto-Add. This challenge can be
overcome by network subnets.
Best Practices:
 Utilize Auto-Add to quickly and easily add XenApp servers into the Provisioning Server database
 Set a device collection template so the newly added target devices are already configured with appropriate
settings.
 When adding groups of identical XenApp servers, change the auto-add site properties to select the correct
location. Modify this setting as needed during the rollout.
 Segment the network so only XenApp and Provisioning Server are on the same subnet while not allowing the
PXE traffic from Provisioning Server to go to other subnets.

XenApp Considerations
Migration design considerations for XenApp delivered on XenServer or on physical hardware are the same. A technical
guide for migrating and upgrading XenApp is available in the following Citrix article (CTX117913). This white paper
explains the different upgrade and migration strategies to XenApp 5.
 7

Notice
The information in this publication is subject to change without notice.
THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-
INFRINGEMENT. CITRIX SYSTEMS, INC. (“CITRIX”), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL
ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY
OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION,
EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.
This publication contains information protected by copyright. Except for internal distribution, no part of this publication
may be photocopied or reproduced in any form without prior written consent from Citrix.
The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products.
Citrix does not warrant products other than its own.
Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.
Copyright © 2008 Citrix Systems, Inc., 851 West Cypress Creek Road, Ft. Lauderdale, Florida 33309-2009
U.S.A. All rights reserved.

Version History
Author Version Change Log Date
Daniel Feller 0.1 Initial documentation November 14, 2008
Daniel Feller 1.0 Finalized document December 2, 2008

851 West Cypress Creek Road Fort Lauderdale, FL 33309 954-267-3000 http://www.citrix.com

Copyright © 2008 Citrix Systems, Inc. All rights reserved. Citrix, the Citrix logo, Citrix ICA, Citrix MetaFrame, and other Citrix product names are
trademarks of Citrix Systems, Inc. All other product names, company names, marks, logos, and symbols are trademarks of their respective owners.