Citrix XenApp Design Draft

Citrix XenApp Design

Table of Contents

1.1      Introduction
1.2      Implementation Overview
1.3      Document Overview
2.        Architectural Overview
2.1      Overall Architecture
2.2      XenApp Design
2.3      Support

Part 1 XenApp Design

3.0      XenApp Architecture
3.1      Farm Configuration
3.2      Data Store and License Server Configuration
3.3      Application Integration
3.4      Load Management
3.5      Features and components of XenApp Server
3.6      XenApp Server Configuration
3.7      Client Environment
3.8      Web Interface Configuration
3.9      Printing Architecture
4.        Shared Infrastructure Components
4.1      Hardware Virtualization Architecture
4.2      Operating System Configuration and Lockdown
4.3      Active Directory Integration
4.4      Profile and Policy Management
4.5      User Logon Process
4.6      Data Storage
4.7      Network Topology
4.8      Network Security Architecture
5.        Perimeter

Overview

1.1      Introduction

The XenApp Design is a best-practice based comprehensive standard. The XenApp Design was designed with simplicity, reproducibility, usability, scalability, supportability, security, privacy and accessibility in mind.

The XenApp Platinum Design represents a complete XenApp standard that can be leveraged as a vanilla solution or modified to more accurately reflect organizational-specific needs. The XenApp Design includes the following categories and solutions:

• Perimeter. A secure perimeter for internal and external access.
• Hardware Virtualization. Hardware virtualization provides an abstraction layer that allows multiple virtual machines to share the processor, memory, storage and networking resources of a shared hardware environment allowing server consolidation, and rapid server provisioning.
• XenApp. Citrix XenApp enables the centralization, management and delivery of Windows applications.
• Application Streaming. Citrix XenApp Streaming allows applications to be packaged, streamed and executed in an isolated environment on XenApp Servers or Windows Desktops.
• Enterprise Single Sign-on. Citrix Password Manager enables single-sign on capabilities for published and local applications, whether they are host (legacy), web, or windows based.
• Server Utilization Monitoring: Citrix Edge Sight for XenApp monitors applications, devices, and the network in real time, allowing organizations to quickly analyze, resolve, and proactively prevents problems.
• Web Interface Portal. A consistent user interface containing XenApp applications, streamed desktop applications, web applications, web content, documents, announcements and information.

1.2      Implementation Overview

The XenApp Design provides a well defined starting point for each implementation. It also serves as a baseline upon which all solution additions, revisions, and tools will be based.  As such, there is an increasing value to XenApp Design users in keeping implementations as close to the design as possible.

Prior to implementing XenApp based upon the XenApp Design, it’s important that an infrastructure assessment and gap analysis be performed. During the IA/GA, the architecture of the solution will be customized to match the customer’s business needs while maintaining the integrity of the XenApp Design. Implementation and support will follow the analysis phase after careful consideration has been given to any specific design modifications that deviate from the reference.

1.3      Document Overview

This document outlines the decision points necessary for implementing the XenApp Design. For decisions that rely on pre-existing factors or specific organizational needs, the appropriate best practice has been provided. The best practices should be analyzed carefully and decisions should be made based on organizational needs, architecture present and budget resources availability.

2.     Architectural Overview

2.1      Overall Architecture

The XenApp Design is designed to be scalable and resilient for ease of implementation, high availability, and ease of maintenance. The complete solution is made up of six architectural components that work together to provide flexibility and options with respect to server consolidation, monitoring, authentication and security requirements, user access scenarios, and component migration/modification.  The design breaks down into the following six components:

• Perimeter. The XenApp Design supports the use of multiple secured perimeters. This allows for flexibility in global load balancing, accommodating different applications and their performance requirements, authentication, security, and branding (look/feel) requirements. It also supports techniques for multiple brands, making it possible to support multiple businesses unites, and partners.
• The XenApp Server farm. The XenApp Design may have one or more XenApp Server farms available to provide application resources for the environment. This design builds on the ability to test new farm builds alongside production farm builds, leveraging the other two components without sacrificing the integrity of the production environment. This will allow the customer to be agile and proactive in their efforts to deliver the most current, feature rich, stable OS, application functionality, and XenApp Server versions. 
• Application Streaming. The XenApp Design will support an organizations entire application portfolio with a single Citrix XenApp Server silo. Application streaming allows applications to be packaged, streamed and executed in an isolated environment on Citrix XenApp Servers or to Windows Desktops. Application streaming used in conjunction with XenApp CPU management allows organization to safely run an entire application portfolio on a single XenApp Server silo.  
• Server Utilization Monitoring: The XenApp Design provides complete transparency from an end user perspective to any application running on a XenApp farm to see exactly what’s happening for a specific user or group of users. Citrix Edge Sight allows organizations to consistently and quantitatively measure performance across the organization for all XenApp hosted applications.
• Hardware Virtualization. The XenApp Design offers a generic hardware virtualization layer that allows multiple Windows and Linux virtual machines to run on a shared hardware environment allowing x86 and x86-64 bit server consolidation, and rapid VM provisioning.
• Web Interface Portal. The XenApp Design supports existing corporate portals used to deliver both XenApp and streamed desktop application using Citrix XenApp Platinum.

Figure2.0 shows a high level overview of the XenApp Design components.

The XenApp Design supports a variety of access scenarios, providing users with the most functional, best performing user experience possible. The user is guided to the appropriate access scenario through end point analysis and global load balancing. The users’ location, device/operating system type, browser version, and connectivity method can be considered. The two primary supported use cases, with available services/functionality, are listed below:

1 – Win32 OS, Internet Explorer, broadband quality connectivity.

In this use case, the user is on the Windows platform running Internet Explorer, with broadband access to the Internet/network. The user launches a web browser locally, navigates to a public URL, and authenticates with the appropriate combination of credentials/passcodes. After the user is authenticated, their web browser is securely directed to a Portal, which serves as their starting view of the organizations’ applications, desktops and data.

This use case leverages the most common corporate platform and reasonably rich, low latency connectivity to provide the user with a highly functional user experience with a rich, diverse set of access services. These services include the following:

• Full access to all appropriate XenApp hosted applications. Users can access published applications directly with the Citrix ICA client or applications from a Portal, e.g. the Web Interface. This service leverages either a native, locally installed Citrix client or a JAVA based ICA client. Both options deliver the appropriate software to the client device through a portal.
• Full access to secure, internal web content using the local web browser. By leveraging the Access Gateway Secure Access Client, the user can access content such as intranets, web applications, web-based e-mail, EIP implementations, etc. The Secure Access Client provides layer 3 connectivity and encryption for all approved applications and content. This includes internal web content that is not natively encrypted with SSL.
• Single sign-on functionality. Once a user is authenticated at the perimeter, their experience accessing web apps/content and published applications is significantly improved. By leveraging Password Manager running on the XenApp Server farm(s) any application that requires secondary authentication (including most web, client/server, and host based apps) can be automatically passed an appropriate credential on behalf of the authenticated user. This functionality is fully compatible with and complimentary to WebSSO products and technologies.
• Full access to corporate e-mail systems through a local e-mail client (such as Outlook), a published e-mail client, a web mail client, etc. This includes support for offline e-mail, which is a requirement for users who spend time in an offline mode. This service also leverages the Secure Access Client to provide secure connectivity to the messaging services without the use of any application specific encryption mechanisms (such as SSL or RPC over HTTP).
• Support for locally installed applications, including TCP based applications that need to communicate with the secured data center network (such as Blackberry synchronization, terminal emulation, etc.).  Similar to above, this service leverages the Access Gateway for layer 3 connectivity and security.
• High latency connections (such as WWAN and Satellite) users can continue to be productive when using these applications over lower quality connection types by leveraging XenApp delivered applications.

2 – Any device, any OS, any connectivity mechanism.

For users who are attempting to access services from a none compliant device, fringe devices, or devices using lower quality connection types, the solution provides services for the following situation(s):

• An end point analysis scan determines the posture of the device, and corporate policy dictates weather a user receives full or restricted connectivity.
• Access device is not Win32 based. This includes devices running the Macintosh OS (both current and previous generations), or Linux.
• Access device is running a browser other than Internet Explorer. This includes Netscape/Firefox/Mozilla variants, Safari, and others.
• Access device is locked down, such that the installation/use of the local Citrix ICA client is impossible. An example may be an airport kiosk, or a locked down business partner’s PC.
• User is utilizing a connectivity medium that is lower quality, such as wireless WAN, dial-up, or satellite.

For these none compliant and ‘fringe’ devices/connectivity mechanisms, the XenApp Design provides the following services:

• Full or limited access to all appropriate XenApp published applications. User’s access published applications from the Web Interface, and pre-tune published application performance for a variety of connectivity medium. Either option delivers the appropriate software to the client device through the web browser.
• Single sign-on functionality. Once a user is authenticated at a the perimeter, their experience accessing XenApp applications is significantly improved. By leveraging Password Manager running on the XenApp Server farm(s) any application that requires secondary authentication (including most web, client/server, and host based apps) can be automatically passed an appropriate credential on behalf of the authenticated user. This functionality is fully compatible with and complimentary to WebSSO products and technologies.

Any of the above use cases can be supported by Windows or Linux Based Terminals that comply with the XenApp Design standard.

2.2      XenApp Design

The XenApp environment for a typical XenApp Design implementation has a single-farm single or multiple zone configurations that should reside in a central data center. Decisions made for this design were based on a large-sized, 5000 concurrent user deployment and should be adjusted to accurately reflect the environment. Shared hardware and infrastructure components such as Citrix Licensing Server, Citrix Data Collectors, Citrix Data Store should reflect Citrix best practices while leveraging what currently exists in the infrastructure.

2.3      Support

Support is an integral part of the XenApp Design and includes a combination of a Citrix support agreement, on and off-site support from the implementing party, and GoToAssist for help-desk support. Users will have several options for support, including FAQ’s, Live Assist, phone support, and GoToAssist.

Part 1 XenApp Design

3.     XenApp Architecture

This section provides a decision matrix for the XenApp Design. Implementers of the XenApp Design can use the decision matrix as quick reference guides to identify settings and configuration decisions to be implemented in the environment. Decisions highlighted in yellow may rely on pre-existing environment factors or differ depending on organizational needs. These decisions should be carefully analyzed during a gap analysis phase.

3.1      Farm Configuration

Decision Point	Citrix  Decision	Justification
Farm Layout	Single farm with XenApp Servers in one data center	Single point of administration, global license pooling, global application access. If more than one location exists, XenApp Servers may be dispersed to different locations if proximity to file servers is necessary.
Version of XenApp Server		The latest version and hotfix level of XenApp will be used.
Number of Zones	One Zone	A single or multiple zones depending on customer requirements.
Zone Data Collector Configuration	Dedicated Primary and Backup Zone Data Collectors	Two servers dedicated to the ZDC role, one primary and one backup ZDC. This configuration provides sufficient capacity for future growth and redundancy for serving critical farm information across the XenApp Server environment. All Web Interface servers will be configured to exclusively contact the ZDCs for authenticating users and enumerating published applications. The Primary ZDC will be set to “Most Preferred,” the Backup ZDC will be set to “Preferred,” and all other servers will be set to “Not Preferred.” Best practice is to have a dedicated primary and backup ZDC; however this decision should be made based on the size of the environment.

 3.2      Data Store and License Server Configuration 

Decision Point	Citrix Decision	Justification
Data Store Database Platform	MS SQL 2000 SP3 or MS SQL 2005 running on Windows Server 2003	MS SQL 2000 or MS SQL 2005provides robust and scalable support for multiple server access, supports replication, and can be clustered. The existing database team will administer the data store.
Data Store Hardware	For up to 1,500 users, a shared dual processor, P4 or greater processor, 1 GB of RAM or greater server will suffice. SQL Server data store and license server may be co-located	Assuming less than 1,500 users (less than 50 servers), this decision will hold. A dedicated dual-processor server should be utilized for more than 3,000 users.
Data Store Access Method	Direct Mode access	XenApp member servers will query the data store directly to maximize efficiency and eliminate single points of failure.
Data Store Location	Main data center; replica in disaster recovery or secondary site	The data store should be located in the central data center, along with all other XenApp components.
Data Store Redundancy	Hardware Component Redundancy and SQL Backup and Replication	The data store component should be redundant with dual power supplies and dual NICs. Regular backups should be performed in conjunction with the data backup strategy. Clustering is not necessary for the data store, since there is no time limit placed on the ability for users to log in when the data store is unavailable.
Data Store Backup Strategy	Full backup daily with 90 day retention period	Recommended regular full backups. If there is already a structured backup regiment in place that will be appropriate for the environment, it may be leveraged here.
Data Store Database Authentication	Windows NT Authentication with “db_owner” rights	For high security environments, Citrix recommends using Windows NT Authentication only. The account used for the data store connection must have “db_owner” rights for the database being used for the data store.
Data Store Database Connection Type	TCP/IP Sockets	Data transmissions are more streamlined for TCP/IP sockets and have less overhead than Named Pipes. Named Pipes is an authentication protocol. Therefore any time a user attempts to open a connection to the SQL Server using named pipes, the Windows NT authentication process occurs.
License Server Location(s)	The Citrix license server will be hosted on the backup zone data collector	In order to centrally manage and pool licenses, it is recommended to install the Citrix license server on the Data Store server and configure connections to the license server as a farm-wide setting.
License Server Hardware	Enterprise-class hardware with dual processors and 2 GB of RAM minimum	Servers with these characteristics will be able to handle the license server for a medium-sized farm.
License Server Disaster Recovery	No backup License Server	Because there is a 30 day grace period in the event the license server is made unavailable, it is not necessary to have a backup License Server.
License Management Console	The web server component the LMC will be hosted on the license servers.	The LMC console web server will be installed on the license servers.

3.3      Application Integration

Decision Point	Citrix Decision	Justification
Applications	Microsoft Office Suite, Internet Explorer 7.0, any other mission critical applications	Applications should be proven in a Terminal Services environment or tested for functionality.
Application Requirements and Dependencies	Internet Explorer 7.0, WinZip 8.x, Adobe Acrobat Reader 6.x	Applications should be analyzed for requirements and dependencies; these listed are expected for typical deployments.
Load Managed Groups (LMGs)	Only 1 for typical deployment.	If any applications are more resource intensive or conflict with all other applications; multiple LMGs should be considered.
Application Packaging and Distribution	Office – MSI WinZip, Adobe – Install Shield	Applications should be packaged using the XenApp Streaming Profiler. All packages should be distributed to servers using XenApp Streaming.
Application Streaming	Citrix XenApp Streaming.	If any applications planned for deployment require customizations, the party implementing the solution should work with the organization to include the change in the application’s installation package and/or modify the server’s login script.

3.4      Load Management

Decision Point	Citrix Decision	Justification
Load Evaluators	Advanced	Initially, the Advanced load evaluator will be assigned to all the servers in the XenApp environment.  The Advanced load evaluator measures load based on CPU Utilization, Memory Utilization, and Pages Swaps/sec. During a pilot testing phase, the effectiveness of the Advanced load evaluator should be assessed. If necessary custom load evaluators may be developed that are appropriate for the environment.

  

3.5      Features and components of XenApp 

Decision Point	Citrix Decision	Justification
XenApp Streaming Profiler
XenApp Streaming Profiler	Shared XenApp Server	To consolidate hardware resource requirements, the XenApp Streaming Profiler can be co-located with a test XenApp Server.
Network Share Point(s)	File share on existing server	XenApp Streaming packages should be stored on a centrally located file server.
Scheduled Installs	Low to no usage	Installations should occur during regularly scheduled system downtime.
Network Account	AD: Domain\Username	An Active Directory administrator account should be created and used to install applications with XenApp Streaming packages.
Server Groups	One	Since the XenApp Design is designed for one LMG, only one server group will be used and all servers will have the same applications. If design has more than one LGM, one server group should exist for each LMG. If the server group is over 40 servers, multiple groups would be recommended to stagger XenApp Streaming package deployments.
Package Groups	None	All applications will be installed using XenApp Streaming.
XenApp Components
Primary Farm Metric Server (FMS)	Primary Zone Data Collector	To conserve hardware resources, the primary Zone Data Collector will be configured with the FMS role
Backup Farm Metric Server	Backup Zone Data Collector	The backup Zone Data Collector will be configured as the backup FMS
Database Connection Server (DCS)	Backup zone data collector	The DCS will be located in the backup zone data collector, thus avoiding an extra load on other servers when reports are run.
Database Connection Server Update Time	Off peak hours	The update needs to be scheduled during off-peak hours such that it does not affect end users.
Collected Processes	Custom	Administrators will monitor various server metrics aimed at assessing the XenApp Server health and utilization levels.
Schedule Reboots	As Needed	Servers should be rebooted based on the applications being deployed. This should be a regularly scheduled event, whether it is daily, weekly or monthly.
Network Manager
SNMP Plug-in	If available	Leverage an enterprise management tool such as HP OpenView or Tivoli if it is pre-existing in environment

3.6 XenApp Server Configurations

Decision Point	Citrix Decision	Justification
XenApp Farm Properties
Connection Limits	Disable “Maximum connections per user”	If it is necessary to conserve resources, a user connection limit may be set. Resource availability should be analyzed.
ICA Keep-Alive	Enabled, timeout set to 60 seconds (default)	Keep-Alive should be enabled to ensure more resilient connections.
ICA Settings - Redundant Graphics Operations	Enable “discard Redundant graphics operations” (Default)	Good for low bandwidth connections.
ICA Settings - Alternate Caching Method	Default: Enabled	Default configuration is suitable.
ICA Settings - Session Graphics	Default: 5625 KB	Default configuration is suitable.
ICA Settings - Degradation Bias	Degrade color depth first  Do not notify user	It is preferable for most applications to degrade color depth before resolution. User notification should be turned off to avoid confusion in the part of the end-user.
ICA Settings - Auto Reconnect	Disable “require user authentication” and enable “log automatic reconnection attempts”	This setting allows for the reconnection process to be as seamless as possible.
License Server – Port Number	TCP 27000	Default port for communication with the license server.
Settings - Broadcast Response	Enable “data collections respond to ICA Client broadcast messages” only	Citrix recommendation.
Settings – Client Time Zone	Disable “use local time of ICA Clients” Disable local time estimation	If user base is in one time zone disable setting; if user range is global then enable.
Settings – XML Service Address Resolution	Disable XML Services DNS address resolution (default)	Default configuration is suitable.
Settings – Content Redirection	Disable server to client redirection	Not required for the XenApp Design.
Settings – Remote Connections to the Console	Default: Enabled	Default configuration is suitable; administrators may require remote connections.
Session Reliability	Enabled
SNMP	Disable SNMP Agent (default)	Not required for AIRDF solution.
Speed Screen Browser Acceleration	Enable Speed Screen Browser Acceleration Level: medium (Default)	Speed Screen Browser Acceleration improves end-user perception by increasing the speed of screen refreshes.
Speed Screen Browser Acceleration\ Compress JPEG Images	Enabled	JPEG images will be compressed.
Speed Screen Browser Acceleration\ Determine When to Compress	Enabled	When WAN links are limited, compression will automatically be invoked.
Speed Screen Flash Acceleration	Enable Speed Screen Flash Acceleration	Improves end-user perception by lowering playback quality of Flash running on the server.
Speed Screen Multimedia Acceleration	Enable Speed Screen Multimedia Acceleration	Leverages local players to ensure high-quality multimedia.
Zone Properties	Servers hosting applications: “Not Preferred” Primary ZDC: “Most Preferred” Backup ZDC: “Preferred”	All XenApp application servers will be set to “Not Preferred” to minimize the probability of being assigned the primary ZDC role during the zone data collector election process. Set the primary ZDC to “Most Preferred” and the backup ZDC to “Preferred” to maximize the probability of being assigned the primary ZDC role during the zone data collector election process. The setting for “Share load information across zones” will remain unchecked, since the XenApp Server farm will not function in mixed mode.
Program Neighborhood Enumeration	Enable “Only data collectors enumerate Program Neighborhood”	Only the ZDCs will respond to application enumeration requests. This setting will prevent MPS servers hosting end user applications from processing farm enumeration requests.
UDP Listener	Disable “Create browser listener on UDP network”	End users will only connect using TCP/IP
Citrix XML Service	Port 8080	The XenApp Design uses port 8080 for XML communication. In addition to providing added security, this setting avoids sharing port 80 between XML communication and IIS on the zone data collectors.
Citrix Connection Configuration Manager
LAN Adapter	Select the primary interface (e.g. “HP Network Team #1”)	Network teaming should be configured on the servers to use ICA.
Connection Timeout	No timeout	Active sessions should not be disconnected.
Disconnection Timeout	180 minutes	Can be changed based on user requirements
Idle Timeout	No Timeout	The XenApp Design is based on users who keep applications up for entire work day; because of this it is recommended that sessions do not timeout when idle.
Encryption	Basic	The internal network should be secure and external users will access the internal network via the Access Gateway.
Connections to Applications	Enable “Only allow connections to Published Applications”	Limits access to servers only to published applications.
Wallpaper	Disable wallpaper	Not needed because all applications will be published seamlessly.
Action on Broken Session	Select “disconnect”	Allows users to reconnect without having to restart the session.
Session Reconnection	From any client	Users will be able to re-connect to their session from a different client device from the one used to establish the original connection. This setting allows for the use of Workspace Control, through which sessions may follow the user from one workstation to another.
Shadowing	Enabled, Input On, Notify On	Allow administrators to shadow end users.
Connections	Connect client drives and client printers. Default to main client printer.	The XenApp Design end users will require access to local drives and printers.
Client Mapping Overrides	None.	All clients mapping will be enabled.
Printers Connected	Enable “By default, only connect to the clients default printer”	Simplifies printer management if users only need access to their default printers. If users need access to multiple printers, this setting can be changed to connect all client printers.
RDP-TCP Listener Security Settings	Administrators and System accounts have “Full Control”. All other groups are removed.	Acts as a control for administrative testing and access for ICA troubleshooting.

3.7      Client Environment

Decision Point	Citrix Decision	Justification
Supported Client Devices	Range of devices	The supported client devices will depend on clients currently existing in the user environment. A wide variety of client devices are supported with the XenApp Design. Highest level of access from users of Win32 devices running IE on adequate network connection. Support for other workstation types and connections are provided by Web Interface.
Client Configuration Settings	Default settings	Client settings will be dictated by the Web Interface (non Win32 devices) servers.
ICA Client Types	Web Client only	To simplify client deployment, only the ICA Web client will be deployed to client workstations. Non-Win32 devices will either use device-appropriate clients or the Java client.
ICA Client Version	Version	The latest ICA Client version incorporates performance improvements (e.g., printing enhancements) and new features such as Workspace Control that will benefit users.
ICA Client Distribution and Upgrade	Leverage Web Interface and Access Center distribution where possible.	For ease of administration and management of client deployment, the Web Interface and Access Center should be leveraged for client distribution.
Client Bitmap cache	Default	The client bitmap cache will be located in the default user profile location. This setting can be edited by modifying the template.ica file.
Client Virtual channels	Disable any unneeded virtual channels (i.e. Audio, client drive mapping), use a policy to disable Client Management (auto client update), OEM virtual channel.	Disabling unnecessary virtual channels will decrease login times. If audio and client drive mapping are not requirements for production, these virtual channels should be disabled.
Special Client Attached Devices	Locally attached printers will be supported	The XenApp Design does not include any special client attached devices, with the exception of locally attached printers if they exist in the environment. Any COM or serial devices will be supported in the environment.
PN Agent Configurations (Optional)	Lockdown user options Enable pass through authentication	Standard ICA settings should be enforced to simplify support requirements and prevent users from overriding the settings. The Application Display and Session tabs of Program Neighborhood Agent will be disabled. Users accessing applications through the Access Gateway should be able to seamlessly launch published applications using the associated shortcuts on the user’s desktop without prompting the user to logon to the XenApp server.

3.8      Web Interface Configuration

Decision Point	Citrix Decision	Justification
Access Mechanism	The Web Interface portal should be primary access mechanism. Integrated with Access Gateway. Two factor authentication integration for external users.	The majority of users should use the Web Interface portal for access.
Redundancy	Web Interface Server	The Web Interface site will serve as backup for access. Currently the XenApp Design includes two Web Interface servers for redundancy.
Load Balancing and Fault Tolerance	Each perimeter host (Web Interface and Access Gateway) will be balanced with a Citrix Netscaler hardware load balancer.	A hardware load balancer provides redundancy and load balances user connections. It also eliminates the delay that may incurred by an unavailable Web Interface server in a DNS Round-Robin configuration. Alternatives may be examined if a hardware load balancer does not exist in the environment and acquiring one is not appropriate for the system.
Web Interface TCP Ports	Default: 80	Port 80 should be open on the internal firewall.
Web Interface URL	https://domainname.com	Predetermined Corporate portal URL. Domain name is organization or agency name.
Web Interface page timeout	6-8 hours.	Web Interface timeout should reflect user requirements.
STA Servers	Primary and backup Zone Data Collectors	The STA component of Access Gateway will be deployed on the primary and backup zone data collectors, due to its small footprint and minimal resource consumption.
Certificates	Verisign (or other Trusted Root Certificate Authority)	Instead of using internally generated certificates that require additional user configuration, Verisign certificates should be used for this service. If the organization has an agreement with another certificate generator an alternative that is equivalent to Verisign may be leveraged.
XML Broker Servers	Primary and Backup ZDC	The XenApp Server farm should be configured such that application enumeration is only performed by the zone data collectors.  For further details, please refer to the  XenApp Server Configuration section.

3.9      Printing Architecture

Decision Point	Citrix Decision	Justification
Required Printers	Local and network printers	The XenApp Design allows for both locally attached and network printers.
Auto-Create Client Print Devices	Default printer only	Only mapping the default client printer simplifies printer management and decreases login time. Although this is ideal, if all client printers are required, this may be modified.
Connection Method for Network Printers	Auto-created	The XenApp Design relies on auto-creation to map network printers.
Appearance of Network Printers	Disable “Always create client network printers as client printers.”	Most network printers will reside over the WAN from the servers. Auto-creating network printers as ICA printers, instead of client network printers, are beneficial because it allows for compression of the print job over ICA.
Bandwidth Limits	Unlimited	The XenApp Design does not limit printer bandwidth over ICA. If bandwidth issues occur as a result of heavy printing, a bandwidth limit should be established.
Citrix UPD	Enable “Use universal driver only if native driver is unavailable” UPD II will be used	UPD should be used to support most client printers to minimize the number of printer drivers installed on the servers. For utilizing advanced capabilities of a printer, mapping the compatible Windows built-in printer driver should be attempted first. Otherwise the 3rd-party printer driver will be installed. This approach will minimize server and spooler crashes due to bad printer drivers. The latest version of the UPD, which supports color printing and 600 dpi, should be used.
Native Drivers	Windows drivers Any required third party printer drivers will be thoroughly tested prior to implementation.	Initially, the XenApp Servers should use only those drivers native to Windows  When installing third-party, it is best to use drivers that are certified by the Windows Hardware Quality Labs (WHQL). If this is not possible, adequate testing of printer drivers should be performed before they are deployed into production. Installation of “Version-2” (kernel mode) drivers is riskier than “Version 3” (user mode) drivers, as they may cause a server to blue screen.
Driver Installation and Updates	Printer Driver Replication	Required 3rd-party printer drivers should be installed on a XenApp Server that acts as a trusted printer driver source. Once installed, printer driver replication will be manually scheduled for off-peak hours to avoid overloading the network with printer driver replication traffic. Using printer driver replication ensures that the printer drivers are consistently installed on all servers.
Compatibility List Options	None configured	Administrators will not manage lists of supported or unsupported native print drivers, as users will not have the right to install printers on the XenApp Servers.
Client Print Driver Remapping	None configured	The use of the Citrix UPD eliminates the need to map print driver names at the client device to the names XenApp Servers.
Pending Print Job	Delete upon logoff	This setting eliminates pending print jobs that may cause the spooler service to hang.

4.     Shared Infrastructure Components

4.1      Hardware Virtualization Architecture

Decision Point	Citrix Decision	Justification
Server Vendor	N/A	It is important to obtain reliable servers from a reputable vendor.
Virtualization Vender
Processors: #, Types, and Speed	Eight Way Dual-Core Processor	Dual-Core two, four or eight way processor configurations are a best practice. Higher processing power is recommended to support the maximum number of VMs per server. Processor utilization should be monitored to determine whether this area is a bottleneck.
Physical RAM	Up to < 64 GB
RAID Controller/RAM	RAID 5	Because hard drives are the most common server component to fail, fault tolerance of the disk subsystem is important. RAID 5 is the best practice.
Disks: #, Size, Speed	TBD	TBD
Partitions	TBD	TBD
NICs: #, Speed	TBD	TBD
Build Process	Unattended install

4.2      Operating System Configuration and Lockdown

Decision Point	Citrix Decision	Justification
Server Build Process	Use Golden Image	TBD
Platform	Windows Server	Windows Server.
Drive Partitions	1 partition	For ease of deployment and management, one partition will be used for both system files and application files.
Security Templates	None	The XenApp Design servers will be locked down through the use of Active Directory GPOs.  Security templates will not be utilized for the XenApp Design.
Disable Services	Yes	Disabling unused services conserves server resources and prevents unnecessary services from providing access to the servers. The following list of services should be disabled on the XenApp Servers, where not applicable: DHCP DNS WINS Alerter License Server Messenger Task Scheduler Windows Media Service TCP/IP NetBIOS Helper Service Plug and Play Unnecessary IIS components
Naming Convention for XenApp Servers	Yes	Naming convention standards for XenApp Servers are important for ease of manageability. The name of a server should help to quickly identify the role of the server, i.e. ORGMPS001, where ORG refers to the organization, MPS refers to XenApp Server, and 001 is an incremental count.
Naming Convention for Web Interface	Yes	Web Interface servers should also follow a naming convention, preferably adhering to the same standard, i.e. ORGCSG001 or ORGWI001.

4.3      Active Directory Integration

Decision Point	Citrix Decision	Justification
Domain Membership	All servers in Active Directory Separate OU for XenApp Servers	Domain membership will be specific to each organization implementing the XenApp Design. All servers in the server farm should be members of the same Active Directory forest. This configuration eliminates the need for trust relationships and simplifies access to published applications and resources. Having the XenApp Servers in their own OU makes it easier to apply XenApp specific GPOs.
Name of OU	Name of OU will be specific to each organization. Separate OU for production and development/test.	To simplify the application of group policies and overall administration, placing the XenApp Servers in their own organizational unit is recommended. An OU specific to Member Servers should be created inside the XenApp OU to house all the XenApp Servers hosting end user applications.
User Account Location	Active Directory	User Accounts should be located in Active Directory if some user accounts exist in NT Domains, a trust should be established between these accounts and the Active Directory.
TS License Servers	Two TS License Servers	Two Microsoft Terminal Services License Servers should be deployed to support the XenApp Server environment to ensure high availability, redundancy, and a measure of disaster recovery. One of the servers should contain all of the licenses while the other server should be activated with no licenses to provide redundancy.
TS Licensing Model	Per Device Per User	Two models are available in Windows 2003 Server. Per Device Licensing requires a TS CAL for every unique client device that accesses a Terminal Server. Per User Licensing requires a TS CAL for every user account that accesses a Terminal Server. Per Device Licensing is typically a more cost effective model; the environment should be evaluated to verify which is more appropriate.

4.4      Profile and Policy Management

Decision Point	Citrix Decision	Justification
Profile Type	Roaming	Roaming profiles are local user profiles stored in a network share and downloaded to the XenApp Server at logon. Roaming profiles give users the ability to modify and save settings across multiple XenApp Servers and sessions. The UPHClean utility Should be used to remedy slow logoff and un-reconciled profile problems.
Folder Redirection	Yes	The Desktop, My Documents, and Application Data folders are to be redirected to the user’s Home Directory; this speeds up logon times by decreasing the size of the profile copied to the local drive at logon.
GPOs Enabled	Yes	GPOs will be applied to the server OU to ensure XenApp Server sessions are kept secure.
Group Membership	Yes	Assigning permissions to XenApp Server published applications and printers are simplified if assignments are made based on group membership instead of individual accounts. Domain global groups should be used in a native Active Directory environment.

4.5      User Logon Process

Decision Point	Citrix Decision	Justification
Logon Script Type	WSH (Windows Scripting Host), VBS (Visual Basic Scripts), or other	Logon scripts will map group drives in the organization, as well as other necessary configurations, including application settings.
Logon GINA	Citrix GINA	When installed, XenApp enhances the Microsoft GINA with additional features for interoperability.
Single Sign-On	Explicitly Logon to My Workplace;   Password Manager for Published Applications	Users will explicitly logon. Password Manager will be implemented to handle applications launched from the Web Interface.

4.6      Data Storage

Decision Point	Citrix Decision	Justification
Application Data Location	File Server	The Application Data folder for each user will be redirected to a file share to speed up logon time.
Profile Directory Location	File Server	Running applications such as those in the Microsoft Office suite can result in user profile directory sizes of hundreds of megabytes.  Large numbers of user profiles can use gigabytes of disk space on the server.  Adequate disk space on the file server for these profiles is necessary.
Home Directory Location	File Server	The Home Directory location will be specified to connect to a file share (i.e. H: to \\server\home$\%username%).
Type of Storage	File Server, SAN, or NAS Solution	Roaming profiles and permanent user data should be stored on a centralized file server, SAN, or NAS that can adequately support the environment. In addition, this storage medium should be logically located near the XenApp Servers so that the fewest router hops are required to minimize logon times.

4.7      Network Topology

Decision Point	Citrix Decision	Justification
NIC and Switch Port Configuration	TBD	TBD
IP Addresses	Static	Static IP addresses eliminate issues associated with DCHP. Further, recording that IP address as a reserved address ensures that it will not be duplicated or reassigned.
Subnets	New subnets will be created for the XenApp Server and related servers.	Reducing the amount of extraneous traffic within a subnet improves throughput and minimizes delays.
Logical Location of Resource Servers	The Data Store, Exchange, and other database servers will be co-located with the XenApp Servers where feasible.	Keeping as many resources as possible within the same subnet eliminates router hops that may cause unnecessary delays.
WAN Links	ICA Packet Prioritization	To maintain responsive ICA sessions, packet prioritization should be implemented and the highest priority should be assigned to ICA packets. Additionally, Windows printing related packets should be assigned low to medium priority. Prioritization should be decided on an organizational basis, depending on the level of criticality the published applications have.
Remote Access	Access Gateway	The Access Gateway provides secures the communication between client devices and the XenApp servers using SSL.
Network Load Balancer	Use Citrix Netscaler hardware load balancing for Web Interface and Access Gateway appliances.	A hardware load balancer provides redundancy and balances user connections.
Port Numbers	The default TCP ports will be used for all components except Citrix XML, which will be changed to port 8080.	Using port 80 for TCP/IP traffic creates consistency and minimizes configuration. XML traffic will be changed to TCP Port 8080 to avoid conflicts with the IIS service on the zone data collectors and improve security in the environment.
Data Store Polling Interval	Will be set to every 60 minutes instead of every 30 minutes (default).	To minimize unnecessary network traffic, the polling interval will be set to one hour.
Speed Screen	Speed Screen Browser Acceleration will be implemented.	Speed Screen Browser Acceleration enables users to see images and text on their screen more rapidly and enhances the user experience.

4.8      Network Security Architecture

Decision Point	Citrix Decision	Justification
Firewall Ports	TCP ports 80 and 443 will remain open; TCP port 1494 will be closed.	A security risk is inherent if inbound TCP port 1494 is open. Once the Access Gateway is implemented, this port should be closed.
Firewall Hardware	Dual firewalls load balanced for failover	The current firewall infrastructure should be analyzed and leveraged.
Certificates	VeriSign or other Trusted Root Certificate Authority certificates will be used for the secure gateway/ web interface/ Secure Access servers.	Instead of using internally generated certificates that require additional user configuration, VeriSign or a practical alternative should be contracted for this service. Purchasing a certificate from a publicly trusted certificate authority (CA), ensures that end users will have the root certificates embedded in their web browser. Non-win32 devices with non-standard browsers will have to be handled on a case-by-case basis.
Dual Factor Authentication	RSA	RSA is the XenApp Design standard due to its simple implementation and ease of management and maintenance.

Perimeter

Figure 5.0 represents the Perimeter Host architecture, which includes a Citrix Access Gateway pair to provide a layer 3 tunnel for all client traffic.

1.1      Support Structure

1.2      GoToAssist Design

Decision Point	Citrix Decision
Ports Used	Standard Http (80) and SSL ports are used for GoToAssist Communication
User Bandwidth Requirements	28.8 K or greater for graphical sessions
Agent Software	The agent must execute an .exe file in order to activate GoToAssist.
Client Software	After the user enters information onto a GoToAssist web page, the user is prompted whether to download GoToAssist software. This is required prior for computer-based communications with an agent.
System Requirements for Agent	Windows 95, ,90, 2000, Me, NT 4.0 or XP, Minimum of Pentium 300 with 64MB of RAM Recommended: Stable Internet connection with ISDN or better Ability to make direct outgoing TCP connections or availability of SOCS server
System Requirements for Customer	Internet Explorer or Netscape Browser 4.0 or higher 28.8Kbps or greater connection Recommended: Ability to make direct outgoing TCP connections or availability of a SOCKs server or an HTTP Proxy Pentium-class running Windows 95, 98, 2000, Me, NT 4.0 or XP
GoToAssist Users	License requirements