Architecting a Citrix Virtualization solution-Design: Application Delivery Design

Lets refresh where we are! We are discussing  about architecting a Citrix environment from Architects perspective. There are 2 parts to it:

  1)    Assessment

  2)    Design

Assessment is further divided into

·   User Community

·   Operating System Delievery

·   Application Delivery

·   Server Virtualization

·   Infrastructure

·   Security and personalization

·   Operation and Support

·   Conceptual Architecture

Design is further divided into

·   Application Delievery design

·   Desktop Delivery design

·   Operating System Provisioning design

·   Virtualization Infrastructure Design

·   Access Design

·   Delivery Optimization

In this blog, we will discuss design of Application Delivery . Each topic will be covered in separate blog.

Before beginning an application delivery design, architects already should have done an assessment of the organization's user groups and application needs. The number, type and complexity of the applications will drive major considerations about application delivery within the virtualized environment.

Application Delivery Design Scenario

A Citrix Certified Integration Architect has been given the task of designing a solution for delivering the applications to users in a company with two branch offices.

The company wants to secure its data, allow workers to access the data center remotely and minimize the effort required to update applications.

During the assessment, the architect documented the following information:

• There are two branch offices, one in Hartford, Connecticut and one in Boston, Massachusetts.
• The datacenter is located in the Hartford branch office.
• There are 500 users in Hartford and 200 users in Boston.
• All servers in the datacenter are running Windows Server 2003 with Service Pack 2 installed.
• Approximately 440 endpoints are running Windows XP, approximately 200 are running Windows Vista and approximately 60 are running Windows 7.
• Users have rights to install applications on their endpoints.
• Microsoft Office 2003 (Outlook, Word, Excel, Access, PowerPoint) and Adobe Acrobat Professional 7.0 are installed on all endpoints. IT would like all systems to be updated to use Microsoft Office 2007 and Adobe Acrobat Professional 8.0, but the work effort is too great.
• Help desk personnel are dispatched to offices to address user issues.
• Seibel CRM and SAP are mission-critical applications and are used by only 70 users, 5 of which work out of the Boston branch office.
• The backend servers (Exchange Server and SQL Server) are located at the Hartford branch office.
• Users at the Boston branch office complain about latency when accessing data on these servers.
• Users travel with their endpoints which makes the data vulnerable should the endpoint be stolen.
• All data is stored on the endpoints.
• Users have no access to the network when outside the office which is affecting productivity.
• A wide variety of client and network printers are used in the environment.

An architect can use the information gathered during an assessment and the information in the following topics to assist in designing an application delivery solution

Application Delivery Overview

Separating the application layer from the OS layer allows for fewer numbers of unique desktop images. Application can be added on the top of OS based on each users identity and rights. The following categories are:

1)      Base: These are applications that are installed on the base image.  Base Applications include helper applications and applications with many OS hooks and shell Integration

2)      Custom: These are applications that are home grown

3)      Resource Intensive: Require significant amount of resources

4)      Challenging: Large, complex applications that require backend DB communication, eg. EFP

Delivery Methods

Following methods are used for best delivery of applications:

1)      Installed: Applications installed on the base image of the OS.

2)      Hosted: Hosted applications are available only to users who have been granted rights to run the applications. All execution occurs on XenApp server hosting the application

3)      Streamed: Streamed applications are available only to users who have been granted rights to run the applications. The required application components are streamed across the network to the target device and executed with an isolated environment

Delivery Method Guidelines

Architects need to determine whether applications should be installed as part of the base desktop image, streamed to the virtual desktop image or hosted on XenApp. Each application should be evaluated on a case-by-case basis based on the application architecture.

Application Type	Delivery Method	Justification
Base	Installed or Streamed	Base applications such as .NET Frameworks can be installed as part of the virtual desktop image. If the base application must be updated, the virtual desktop image must be updated. The more images there are to manage, the more complex the managing of locally installed base applications becomes. If an existing XenApp infrastructure is in place, these applications can be streamed to the virtual desktop image.
Custom	Installed or Streamed	Custom applications can be installed in the virtual desktop image if all users of the image require the application. If an existing XenApp infrastructure is in place, these applications can be streamed to the virtual desktop image or hosted on XenApp. If the custom application is not Terminal Services aware, hosting it on XenApp is not an option, but streaming the application to the virtual desktop image may be a viable solution.
Resource- Intensive	Streamed or Hosted	Resource-intensive applications have a significant impact on CPU and memory resources. If the application is: Streamed to the desktop of the cilent device, the application will use the resources of the client device Streamed to the virtual desktop image, the application will use the resources of the XenServer host server up to the limit of the resources allocated to the desktop, which limits the impact to other users Hosted on a XenApp server, the application will use the resources of the XenApp server, meaning that a small number of users could potentially consume all of the resources of the XenApp server
Challenging	Hosted	Challenging applications typically have unique configurations and dependencies. Because XenApp is a tightly-controlled environment, an organization can guarantee that the application is set up properly and functioning in the XenApp delivery model.

Ask the Architect

How should applications be executed and delivered in a virtual desktop? To find out more, view the "Integrated Apps into Virtual Desktop" video on the www.citrix.com/tv web site.

Streaming Considerations

Application streaming simplifies the delivery of the application by allowing an administrator to install and configure an application on one file server for delivery to desktops. To upgrade or patch the application, the administrator must make the updates only in the location where the application was stored.

Once the architect has decided that an application should be streamed, a decision must be made about whether or not to cache the streamed application to improve the access time for users. The following caching options are available:

• Pre-caching
• No pre-caching
• Cache redirection

Pre-Caching

Pre-caching can stream the application files to the target device prior to launch by the user. When a user launches the streamed application, the plug-in will validate that the application files on the target device are current and will launch the application accordingly. An advantage of pre-caching streamed applications is that there is minimal delay in the application launch because the files are local and do not have to cross the network. In addition, because files and settings are not being streamed to the target device, the write cache size is kept to a minimum. If the application files are out of date, the application launch process will update the write cache as needed.

Applications that are used everyday and undergo semi-frequent small updates should be pre-cached to reduce user frustration, network usage and the write-cache size.

During the vDisk image build process, streamed applications can be pre-cached within the vDisk image and then executed to pre-cache all the files. Even though the streamed application becomes a part of the image, users must launch the application using a XenApp plug-in, just as with streamed applications that are not pre-cached.

Updating a streamed application does not necessarily mean that the application cache on the vDisk image must be updated. If the application update is minor, such as with a hotfix that changes a few files, the application streaming process can update the files without impacting the startup time. If the update is major, like a service pack for an application, then it would be advantageous to update the application cache on the vDisk image.

No Pre-Caching

When a streamed application is not pre-cached on the target device, the application profile must be streamed to the write cache on the target device during the application launch. Even though the entire application might be 500MB in size, only the portion needed to start the application is initially sent to the target device. Because this portion of the application must be delivered over the network, the application start will be delayed until enough of the application files and settings are delivered. As the user continues to access more functionality within the application, more files are delivered to the target device, continuously increasing the write cache size.

An advantage of not pre-caching a streamed application is that the application profile is not part of the base vDisk image. As a result, updating the application profile does not necessitate updating the base vDisk image. This simplifies the process for application updates, especially in larger organizations, which typically have one group managing application profiles and another group managing base vDisk images.

A disadvantage of not pre-caching a streamed application is that the application profile must be streamed to the target device after every reboot of the server hosting the application. This will result in a delay of the application start while the write cached is being built.

Applications that should not be pre-cached include:

• Applications that undergo constant, large updates because all of the benefits of pre-caching would be negated
• Applications with sporadic usage because requiring a user to wait a little longer for an application only occasionally will not be as noticeable as delays in launching everyday applications

The .CAB based architecture used for application streaming will be replaced in future XenApp releases with an uncompressed directory structure architecture.

Cache Redirection

Another method that can be used to optimize application streaming is called cache redirection. With cache redirection the virtual desktops are designed so the storage allocated for holding the Provisioning Services write cache is also used to hold the application streaming write cache.

Advantages of using cache redirection include:

• Simplified application maintenance by decoupling the application streaming write cache from the vDisk
• Faster application launches after reboots because the cache is persistent

A disadvantage of using cache redirection is that it requires additional storage to be allocated for each virtual desktop.

XenApp Farm and Zone Design

An architect must determine how many XenApp farms should be implemented in the environment. The number of zones in a XenApp farm should often be kept to a minimum with one zone being the optimal solution. Keep in mind that a data collector exists in each zone and that the zone data collectors must replicate data to all other zone data collectors in the farm.

Farm Design Considerations

A single farm will work best in most implementations. However, there are some circumstances in which deploying multiple farms makes sense. For example:

• If the IT infrastructure is organized by region and managed in a decentralized manner, use of multiple farms could improve farm performance, save time when coordinating farm administration and simplify troubleshooting farm-wide issues.
• If the organization has network infrastructure limitations such as WANs with high latency or error rates, use of multiple farms may perform better than a single farm with multiple zones.
• If the organization has security policies in place concerning server communications, use of multiple farms can be used to segregate data based on the security level to meet regulatory compliance requirements.
• If the organization has geographically dispersed datacenters that can support their own data store database, use of multiple farms can ease administration.
• If communications between servers within the farm should not cross a firewall or WAN, use of multiple farms can resolve this issue.
• If an organization has a large deployment with thousands of servers and users, use of multiple farms can improve the scalability and the performance of the data store, local host cache and IMA service.

Some Citrix components such as Web Interface, SmartAuditor Server, Citrix Licensing and EdgeSight can be shared between multiple farms; consequently, it is not necessary to consolidate all servers in a single farm to prevent deploying these components multiple times.

Zone Design Considerations

In general, the number of zones in a XenApp farm should be kept to a minimum. When all farm servers are in one location, a single zone is probably the best solution.

Even when "Share load information across zones" is disabled (the default setting), zone data collectors must still communicate some data to all other zone data collectors in the farm, although the communication is less. As the number of zones in a XenApp farm increases bandwidth consumption and network traffic increase exponentially as a result of these data collector communications.

Multiple zones might be warranted in the following situations:

• In large organizations with datacenters geographically dispersed, geographically-related servers should be grouped into zones when latency has been determined to degrade performance. Keep in mind that not all geographically dispersed implementations require multiple zones.
• When zone preference will be used to direct user connections to specific sites

Profile Design

Because profiles play an important role in user satisfaction with a virtualization solution, it is imperative that the architect understands:

• The available profile types
• Which profile types best meet the needs of the users
• How to manage profile effectively

The profile information discussed in this section also applies to XenDesktop virtualization designs. 

Profile Types

Profile Design Considerations

Profile design is one of the most critical areas in a XenApp implementation. Many of the issues commonly seen in large or complex XenApp implementations, such as slow logons, loss of user settings, profile corruption and excessive administration effort are often the result of poor profile design.

To determine which profile type should be used in a XenApp implementation, the architect must be able to answer the following questions:

• Do users need to save their settings?
• Yes: Use a roaming or hybrid profile.
• No: Use a mandatory profile.
• Do applications store settings in the registry?
• No: Use a mandatory profile.
• Yes: Use a roaming profile hybrid profile or multiple profiles.
• Will auto-created client printers be used with client-side settings?
• No: Use a roaming profile, hybrid profile or multiple profiles.
• Yes: Use a mandatory profile.
• Will network print jobs be spooled directly to the print server with the printer properties retained?
• No: Use a mandatory profile.
• Yes: Use a roaming profile, hybrid profile or multiple profiles.
• Are applications in load managed groups or silos?
• No: Use roaming profiles.
• Yes: Use a hybrid profile or multiple profiles.

Citrix Profile Management

Citrix Profile Management is a hybrid-type profile solution. It allows users to completely customize their experience while overcoming challenges with roaming profiles. For example, in a virtual desktop environment, when the user logs back into a new desktop, the mandatory profile loads and the custom modifications are applied automatically.

However, depending on its configuration, Citrix Profile Management can take over as the profile solution for XenApp, XenDesktop and the local desktop. Citrix Profile Management is not for every environment, because it is more complex than the standard Microsoft profile solutions. Citrix Profile Management should only be implemented if warranted by both technical and business requirements. In general, mandatory profiles should be used first, then roaming profiles, then Citrix Profile Management.

Suggested use cases for Citrix Profile Management include the following:

• User accesses multiple XenApp server farms and often has multiple ICA session open.
• User accesses multiple desktops, including XenDesktop, where the operating system is different.
• Excessive roaming profile corruption issues exist

Profile Management

Citrix Profile Management is included with XenApp Platinum and Enterprise editions. It optimizes profiles in an easy and reliable way. At logoff, registry changes, as well as files and folders in the profile, are saved to the user store for each user. If, as is common, a file already exists, it is overwritten if it has an earlier time stamp.

At logon, the users' registry entries and files are copied from the user store. If a locally cached profile exists, the two profiles are synchronized. This makes all settings for all applications and silos available during the session, so it is no longer necessary to maintain a separate user profile for each silo.

Citrix Profile Management should be installed and enabled on servers, virtual images and client devices in the environment because it can address user profile deficiencies in virtualized environments. For example, when Citrix Profile Management is not in use, and a user starts sessions in two different virtual resources, the profile of the session that terminates last overrides the profile of the first session. This problem, known as "last write wins," discards any personalization settings that the user makes in the first session. Citrix Profile Management can correct this issue.

The "last write wins" issue can also be addressed by using different profiles for each application silo. However this results in increased administrative overhead and storage capacity requirements. Another drawback is that the administrator must replicate the settings in all profiles in all silos.

Printing Design

Print configurations vary widely among organizations. Some users might have locally attached printers, while others might use only network printers or a combination of both. Managing the print devices, print drivers, printer configurations and network traffic can make printing administration a complex task.

An architect should design the printing environment so that it is easy to administer, responsive and seamless to users. This can be accomplished by addressing the following questions:

• Which print drivers -- native drivers, Citrix universal print drivers, or both -- will be allowed in the environment?
• Will printers be provisioned to users through client printer auto-creation, static provisioning, network printer provisioning or user-self provisioning?
• Will print jobs be routed to the client or the network?

Print Drivers

Print drivers determine how jobs are rendered to print devices. While designing the printing architecture, the administrator must determine which print drivers are allowed and how they will be installed and maintained on XenApp servers. XenApp supports:

• Native drivers, which are the drivers provided within the Microsoft Windows operating system
• OEM print drivers, which are drivers supplied by vendors
• Citrix Universal Print Drivers, which are included with XenApp 4 and later and are compatible with most print devices

The Novell iPrint driver is not supported in a XenApp environment.

If OEM drivers will be used, it is important that these drivers be manually or auto-replicated to all servers in the farm to ensure a consistent experience regardless of the server hosting the user session. In addition, it is a best practice to limit the number of OEM drivers used in the environment.

Users do not have the ability to install OEM drivers over ICA or RDP connections but can inadvertently install native drivers over ICA or RDP connections. To accomplish this goal:

• A Citrix policy that disables the installation of native print drivers over ICA sessions can be implemented.
• A group policy to prevent users from redirecting printers over RDP connections which installs the native print driver on the XenApp server can be implemented.

If native drivers will not be used, a Citrix policy that enforces the use of the Citrix Universal Print Driver for all print jobs should be used. In addition, a Windows group policy should be implemented that disables the installation of native print drivers over RDP should be configured.

If both native print drivers and the Citrix Universal Print Driver will be used, use a Citrix policy to determine the default driver type and to ensure print drivers are consistent across all servers.

Printer Provisioning

XenApp print environments are highly dynamic as they are built during user logon or application launch. During the printing design, an architect must determine how printers will be provisioned to user sessions. The following printer provisioning methods can be configured:

• Client printer auto-creation automatically creates the printers defined on the client devices. A Citrix policy can be configured to auto-create all client printers, only the default client printer, only client local printers or only client network printers.

Client printer auto-creation is the easiest to configure but may require extensive processing on the XenApp servers.

• Static printer provisioning uses local printers specified by TCP/IP, USB or another method. Local printers are typically created as part of the server build and seldom change.

Static printer provisioning has an initial high administrative burden during the setup process. In addition, it increases overhead on XenApp servers as jobs are spooled on the server. Static provisioning is optimal when:

• Applications require local printers, such as Acrobat printing to PDF.
• A small deployment with a small number of printers will be managed entirely on the servers.
• Network printer provisioning uses a Citrix policy, GPOs, logon scripts or toolkits to provision printers on network print servers to users within XenApp sessions. Network printer provisioning requires additional configuration initially but is the most efficient of the provisioning types for printer creation and printing.
• User self-provisioning allows users to configure client and network printers using the Add Printer wizard available within XenApp sessions or by publishing the PRINTCFG.EXE tool. After a user self-provisions a printer, that printer is available in all future sessions for that user. User self-provisioning reduces server overhead because no excess printers are provisioned. In addition, user self-provisioning reduces administrative overhead and the control administrators have over printer provisioning. The number of help desk calls may increase as users need help configuring their printers.
• Citrix Universal Printer provisioning is an auto-created printer object that uses the Citrix Universal Print Driver and is not tied to any specific printer defined on the client. Once implemented, it is available in all sessions that use the XenApp plug-in. It is also independent of any printing policies defined in the management console or elsewhere, and therefore, it is possible to implement the Citrix Universal Printer with other auto-created printers, session printers, and/or non-Citrix defined printers (as well as by itself). The printer auto-creates in a standard fashion with the name "Citrix UNIVERSAL Printer."

Print Job Routing

During the printing design, the architect must determine the path that print jobs destined for a network printer will take. By default, print jobs destined for a network printer are routed along the network printing path unless the application server and print server are on different untrusted domains or the print driver is not installed, in which case print jobs are routed along the client printing path.

The following information describes the two printing pathways:

• Network printer path
1. The application server communicates with the remote spooler on a print server to create the print job and associated spool file.
2. The print server renders the print job.
3. The print server relays the print data to the appropriate print device.

The network printer path is ideal for fast networks where the application server and network print server are on the same LAN. The network printer path is not recommended for WANs, networks with substantial latency or networks with limited bandwidth due to the number of packets exchanged between the application server and network print server. In addition, the packets traversing the network are treated as regular traffic and are not compressed. This can result in the user experiencing latency while the print jobs spool.

• Client printer path
1. The application server communicates with the local spooler on the XenApp server to create the print job and associated spool file.
2. The print server renders the print job. If the Universal Print Driver is used, this step differs slightly.
3. The rendered data is delivered to the client device through a virtual channel within the ICA protocol.
4. The client device relays the print data to the printer, or to the print server which then relays the data to the print device.

The client printer path is ideal for networks with limited bandwidth because the ICA protocol compresses the print job and provides the ability to set bandwidth limits through a Citrix policy. To make client printer routing the default printing path, the Citrix print job routing policy can be set to always connect indirectly as a client printer.

Proximity Printing

During the printing design, an architect should specify whether proximity printing will be implemented in the environment. Proximity printing allows users to move within the environment and print to the closest network printer to the client device used to access the session. Proximity printing is normally warranted for mobile workers within the corporate environment.

Proximity printing is implemented by configuring the Citrix session printers policy rule and is typically applied using the Client Name filter with wildcards or the Client IP address filter. This means that the endpoints are assigned client names or IP addresses by their location (floor, building).

The session printers policy rule should be updated whenever network printers are added or removed, and whenever the DHCP IP address ranges for the floors or departments are modified, if the Client IP Address filter is used.

Tuning and Optimizations

An architect may need to tune the operating system, Terminal Services and XenApp specific-settings on a 32-bit XenApp server.

Operating System Tuning

The architect should optimize a Windows 32-bit operating system running XenApp by disabling unused services and features including the following settings.

Setting	Configuration	Description
Disable Windows Animation	System Properties > Advanced > Settings > Visual Effects > Adjust for best performance	Disable window animations which are not well suited for remote display.
Disable Paging of the Executive	HKLM\System \CurrentControlSet\Control \Session Manager\Memory Management \DisablePageExecutive REG_DWORD = 1	Configure kernel mode drivers and other system components to not be paged to disk to improve performance.
Disable Spooler Warning Events	HKLM\System \CurrentControlSet\Control \Print\Providers\EventLog REG_DWORD = 1	Disable warning events that are logged anytime an auto-created printer is created or deleted to prevent the System event log from quickly filling with useless warnings.
Disable Spooler Notifications	HKLM\System \CurrentControlSet\Control \Print\Providers\NetPopup REG_DWORD = 0	Suppress notifications to users when the Spooler service connects to shared network printers to improve performance.

Server Tuning and Optimizations

The following settings may need to be adjusted on a Windows 32-bit XenApp server to enable it to run in the most efficient manner possible:

• System Cache
• Paged Pool Size
• System PTE
• Non-Paged Pool Size
• Maximum Work Items (MaxWorkItems)
• SMB Server Requests (handling and issuing)
• Maximum Raw Work Items (MaxRawWorkItems)
• Maximum Free Connections (MaxFreeConnections)
• Minumum Free Connections (MinFreeConnections)
• SMB Client Session
• Lazy Flush Interval
• Remote Recursive Events
• Terminal Services security
• TCP Maximum Data Retransmissions
• Error Mode
• NTFS Last Access Update

Data Store Design Considerations

When designing the application virtualizaton solution, an architect must ensure that the database used to hold the XenApp data store will meet the needs of the implementation.

A Microsoft SQL Server data store database should meet the following requirements:

• The data store database can be placed on the same server as other databases but should not be configured to share a database with other client/server applications or the master database.
• Approximately 100MB of disk space is required for every 250 XenApp servers hosting 50 published applications. More disk space is required for greater numbers of published applications. The default database size and settings usually suffice.
• The "temp" database must be set to automatically grow on a partition with at least 1GB of free disk space for a small farm or 4GB for a large farm with multiple print drivers.
• The Windows authentication-only setting provides the highest security. In addition, the service account can be changed from db_owner to read/write only to increase the security of the database. Keep in mind that the service account must be changed back to db_owner in order to upgrade or apply hotfixes to the database.
• TCP/IP sockets should be used as the authentication protocol because it does not rely on the Windows authentication process to establish a connection but does provide user/password authentication to the database after the connection is established

Database Replication Considerations

A replicated data store ensures that all data store reads occur on the network local to the XenApp server rather than across the WAN. An architect should be aware of the following considerations when deciding if database replication is warranted:

• A single data store works best for most deployments, but a replicated data store at remote sites can improve farm performance especially across high-latency or low-bandwidth WAN links.
• Database replication consumes bandwidth so replicas of the data store database should be placed only at sites with enough servers to justify the bandwidth cost of placing the copy at the site. As the size of the farm increases, the amount of bandwidth required for the read requests increases.
• Data coherency is required across the replicated databases, so a two-phase commit must be used.
• Merged replication should not be used, as it can lead to corruption of the data store database.
• A published XenApp management console must be used to perform farm maintenance from a remote site that has high latency to avoid performance issues.

SQL mirroring instead of replication of the data store database may be used over fast WAN links if the sites are close or tightly connected.

Database Fault Tolerance Considerations

Microsoft clustering provides failover and failback for the clustered systems. If a node running an instance of Microsoft SQL Server fails, the cluster group containing the data files for that instance is switched to another node and starts accepting connection requests for that instance. Failover of the database in a clustered environment is transparent to XenApp.

The SQL cluster should be configured in the datacenter where the majority of XenApp servers are, not where the majority of users are located.

Microsoft Cluster Services clustering does not support load balancing among clustered servers because it functions in active/passive mode only.