Citrix Terms

   

The XenApp planning and installation documentation uses the following terminology.

Multi-user environment
An environment, including XenApp and Terminal Services, where applications are published on servers for use by multiple users simultaneously.
Application servers
The farm servers that host published applications.
Infrastructure servers
The farm servers that host services such as the data store or the license server. Typically, they do not host published applications.
Production farm 
A farm that is in regular use and accessed by users.
Design validation farm
A farm that is set up in a laboratory environment, typically as the design or blueprint for the production farm.
Pilot farm
A preproduction pilot farm used to test a farm design before deploying the farm across the organization. A true pilot is based on access by select users, and then adding users until all users access the farm for their everyday needs.
Enumeration
The process in which a client transmits data to locate servers on the network and retrieves information about the server farm’s published applications. For example, during enumeration, the XenApp Plug-in for Hosted Apps communicates with the Citrix XML Service or the ICA browser, depending on the browsing protocol selected in the plug-in.
Enumeration can also be expalained as:
Application enumeration is when Citrix client software lists virtualized applications available on the XenApp servers. The client software transmits data to locate servers on the network and retrieves information about the published applications. For example, during enumeration, the XenApp online plug-in communicates through Citrix XML Service with the XenApp server to determine applications available for that user.
Citrix farm
is a collection of citrix servers which provide published applications to all users(or, collection of servers that point to single database is a farm). It also prevent single failure of all citrix servers due to load balanced capabilities.
Citrix XenApp server uses server farms to organize and manage servers. This allows you to manage many settings as a unit rather than apply them individuallyto each machine. Servers in a farm all connect to the same datastore and generally have some features in common that make grouping them together logical. Farms also provide a method for application publishing. Publishing an application means to provide it to remote users from the server installation. Within the farm model are the two technologies that make the on-demand enterprise function: independent Management Architecture (IMA) and Independent Computing Architecture (ICA).
XenApp Setup comprises two installation wizards:
Create a New Farm. The first time you install XenApp, select  Create a New Farm in the installation wizard and Setup creates the farm with that server hosting specific roles.The server where you installed XenApp and created the farm is the first farm server or the Create farm server.
Join an Existing Farm. When you run Setup on servers after installing XenApp on the first farm server, you take a different path in Setup and XenApp references the settings you specified on the first farm server. These servers join the existing farm and communicate with the first server in the farm.
Data Store
The data store is the database where servers store farm static information, such as configuration information about published applications, users, printers, and servers. Each server farm has a single data store. To check the supported databases, click Here
Data Collector
A data collector is a server that hosts an in-memory database that maintains dynamic informationabout the servers in the zone, such as server loads, session status, published applications, users connected, and license usage. Data collectors receive incremental data updates and queries from servers within the zone. Data collectors relay information to all other data collectors in the farm. By default, the first server in the farm functions as the data collector.
By default, the data collector is configured on the first farm server during the Create Farm Setup and all other servers are configured with equal rights to become the data collector if the data collector fails. When the zone’s data collector fails, a data collector election occurs and another server takes over the data collector functionality. Farms determine the data collector based on the election preferences set for a server The data collector is an infrastructure server and applications are typically not published on it.
Other IMP def:
The data collector is responsible for managing all of the dynamic information in the farm. Dynamic information consists of items that change often such as connected sessions, disconnected sessions, and server loads. The data collector is responsible for knowing the global state of the farm. The data collector also performs resolutions. A resolution is a process where, upon user request, the data collector determines the least-loaded server that is hosting a load-balanced published application or desktop.
Zone
A zone is a grouping of XenApp servers that communicate with a common data collector. In large farms with multiple zones, each zone has a server designated as its data collector. Data collectors in farms with more than one zone function as communication gateways with the other zone data collectors.
The data collector maintains all load and session information for the servers in its zone. All farms have at least one zone, even small ones. The fewest number of zones should be implemented, with one being optimal. Multiple zones are necessary only in large farmsthat span WANs.
Other DEF:
Zones within Citrix infrastructures are logical segments within a Citrix farm. Every zone has a data collector (described in the next paragraph). Servers in a zone will communicate with his zone data collector where the data collectors of every zone will exchange information which each other about his zones. Click Here to know more about zones.
Zones perform two functions:
Collecting data from member servers in the zone
Distributing changes in the zone to other servers in the farm

• Every farm will have zones and every zone will have data collectors.

What is a Zone Data Collector (ZDC)?
Each zone in a Presentation Server farm has its own traffic cop  or ZDC. A ZDC may also at times be referred to as the Zone Manager. The ZDC maintains all load and session information for every server in the zone. ZDCs keep open connections to other farm ZDCs for zone communication needs. Changes to/from member servers of a ZDCs zone are immediately propagated to the other ZDCs in the farm.
Streaming Profiles
Applications can be delivered to users by either streaming or hosting the applications on the server. If you are streaming applications, either to client or server, you must install a streaming file server in your environment. When streaming applications, you create profiles of the application and then store the profile on a file or Web server.
You can deliver applications to users by either virtualizing them on the desktop (streaming) or by virtualizing them on the server (hosting). If you are virtualizing applications on the desktop, either streaming to the client or server, create a streaming profile server in your environment. To virtualize applications on the desktop, you create profiles of the application and then store the profile on a file or Web server. The profile consists of the manifest file (.profile), which is an XML file that defines the profile, as well as the target files, a hash key file, the icons repository (Icondata.bin), and a scriptsfolder for pre-launch and post-exit scripts.
Citrix Licensing
A Citrix License Server is required for all XenApp deployments. Install the license server on either a shared or stand-alone server, depending on your farm’s size. After you install the license server, download the appropriate license files and add these to the license server.
Program Neighborhood
is a set of services and APIs that provide the Program Neighborhood ICA Client with a filtered view of all of the published applications (managed applications) in a given enterprise that a particular user can access.
Web Interface
The Web Interface is a required component in any environment where users access theirapplications using either the XenApp plugin or a Web browser. Install the Web Interface on a stand-alone computer; however, where resources are limited, the Web Interface is sometimes collocated with other functions..
XenApp Web and XenApp Services Sites
XenApp Web and XenApp Services sites (formerly known as Access Platform and Program Neighborhood Agent Services sites, respectively) provide an interface to the server farm from the client device. When a user authenticates to a XenApp Web or XenApp Services site, either directly or through the XenApp plug-in or the Access Gateway, the site:
Forwards the user’s credentials to the Citrix XML Service

• Receives the set of applications available to that user by means of the XML Service
• Displays the available applications to the user either through a Web page or by
• Placing shortcuts directly on the user’s computer

IMA(Independent Management Architecture)
A data store, which is a database for storing MetaFrame XP server configuration information, such as published applications, administrator names and permissions, and server listings, total licenses, load balancing configuration, MetaFrame XP security rights, and printer configuration.
A protocol for transferring the ever-changing background information between MetaFrame XP servers, including server load, current users and connections, and licenses in use.
In MetaFrame XP, IMA does not replace the ICA protocol. The ICA protocol is still used for client-to-server user sessions. The IMA protocol is used for server-to-server communication in performing functions such as licensing and server load updates, all of which occur “behind the scenes.”
– IMA has a data store, a database to store MetaFrame XP configuration information.
– IMA has a protocol, to transfer the changing data between MetaFrame XP servers including server load and current user connections.
IMA Service citrix
Its a collection of subsystems (dll) that communicate each other and provides services/functions to the presentation server. It works on the port 2512 and 2513. The port 2512 is used for communication between servers and the port 2513 is used for communication with CMC.
Independent Management Architecture Service (or IMA) provides the communication between servers in your Citrix environment.
IMA exists to manage your XenApp farm by providing a method of communication directly with each server. The types of data that are used through this service would be sessions, server load, licenses, and other data that you can view in your management tools. This communication exists on TCP port 2512 by default.
IMA is important for communication to your Citrix Application server but not necessary for current connected sessions. You can successfully stop IMA if needed to do things like recreate local host cache without effecting users that are logged in.
Independent Computing Architecture
ICA is a protocol designed specifically for transmitting Windows graphical display data as well as keyboard and mouse input over a network. ICA is one of two technologies used by Citrix servers, the other being WinFrame.ICA has the following benefits:

• Like Remote Desktop Services RDP Protocol, but with many enhancements.
• Very “thin”
• Screen Updates and keyboard/mouse movements, peripherals, printers, disks and so on.
• Optimized for WAN delivery, Bandwidth optimized, Latency sensitive.
• Printing and file transfers reduce performance.

Independent Computing Architecture (ICA) is a proprietary protocol for an application server system, designed by Citrix Systems. The protocol lays down a specification for passing data between server and clients, but is not bound to any one platform.
What is Client Lock Down?
Answer :- Typically ‘client lockdown’ is the process of securing an endpoint so that the user can only access authorised features. An example of this would be turning the device into a ‘Thin Client’ by locking it down so that an end user can only connect to published apps or desktops and can not use other features.

Worker Group

Worker Groups are new in Citrix XenApp 6. They’re collections of XenApp servers that reside in the same farm and are managed as a single unit. Worker Groups let you collect servers into groups for publishing applications, load balancing, and policy filtering. They’re particularly useful for larger installations where many XenApp servers must be managed as a single unit.
A worker group is simply a collection of XenApp servers in the same farm. Worker groups allow a set of similar servers to be grouped together and managed as one

Shadowing
Session shadowing lets you monitor and interact with user sessions. When you shadow a user session, you can remotely view the user session display and interact with the session using your own keyboard and mouse.
Caution: Shadowing restrictions are permanent. If you disable shadowing or shadowing features during Setup, you cannot reconfigure them after Setup, and they apply to any policies for user-to-user shadowing.
Shadowing options
Prohibit shadowing of user sessions on this server: Disables user session shadowing on this server.
Allow shadowing of user sessions on this server: Enables user-session shadowing by the server.
You can apply the following restrictions:
Prohibit remote control: By default, authorized users can view a session they are shadowing and use their keyboard and mouse to interact with it. This option lets authorized users know their session is being shadowed.
Force a shadow acceptance popup: By default, an acceptance prompt notifies users when an authorized user attempts to shadow their sessions. This option prevents authorized users from shadowing sessions without sending an acceptance prompt.
Log all shadow connections: Enables logging of shadowing attempts, successes, and failures in the Windows event log.
Connecting to the Data Store
A factor in planning your data store is deciding how you want servers in the farm to access the server on which the data store database is running: directly or indirectly. (You specify the access method when you run Setup to install XenApp on servers to join an existing farm.)

• Direct access – If you are in an large farm environment, have a mission-critical farm, or are using Oracle, SQL Server, or DB2 as the database for your data store, Citrix recommends accessing the data store directly. For direct access, a server must have appropriate ODBC drivers installed and configured.
• Indirect access – With indirect access, servers in the farm connect to an intermediary server running XenApp, which connects to the data store directly. If you are in a small to medium environment and are using SQL Server Express or Microsoft Access for your data store, each server in the farm (other than the Create Farm server), must access the data store indirectly.

Citrix does not recommend indirect access for mission-critical farms because the intermediary server is a single point of failure. By default, indirect access uses TCP port 2512 for communication between servers in the farm and the intermediary server that connects to the data store. If the servers are in different subnets divided by a firewall, be sure this port is open on the firewall.
Protecting the data store is part of securing your server farm; this includes protecting the data and restricting who can access it. In a direct connection, all farm servers share a single user account and password for accessing the data store.
Provisioning Services:
You can install Provisioning Services and create a single desktop operating system image (vDisk) that you can stream to multiple desktops hosted in the VM infrastructure.
Provisioning Services requires a database in which to store configuration information. Before you install Provisioning Services, ensure that an instance of Microsoft SQL Server 2005 or Microsoft SQL Server 2008 is available. This can be an existing database on the network (provided it can communicate with the Provisioning Services VM) or it can be a fresh installation. Microsoft SQL Server 2005 Express Edition is provided on the XenDesktop installation media if you need to create a new database server.
Netscalar: Citrix’s NetScaler provides 100% application availability, application and database server offload, acceleration and advanced attack protection. Deployed directly in front of web and database servers, NetScaler solutions combine high-speed load balancing and content switching, data compression, content caching, SSL acceleration, application flow visibility and a powerful application firewall into a single, easy-to-use platform.
Mostly netscalar is used for web interface load balancing.
Smart Auditor: Smart Auditor records applications that we publish to users. We can set prompt or disable prompt that applicaiton is recorded in smart auditor. So, if we dont configure, users wont get a prompt that their sessions is recorded. More information about smart auditor can be found Here
Edgesight Monitors xenapp servers and report(sms/mail) if any servers are not responding. To do this, all xenapp servers should have edge sight agent installed. Edgesight monitors only servers and NOT applications.
Edgesight installation is not recommended in citrix xenapp server because it has some problem with Terminal services(Remote Desktop Services).
Edgesight for load balancing is a seperate component from citrix, using which we can know how many users can a server support and within which we can calculate how many citrix servers we can have in our enviornment.
Citrix Password Manager: Citrix Password Manager provides password security and single sign-on access to Windows, Web, and terminal emulator applications running in the Citrix environment as well as applications running on the desktop. Users authenticate once and Password Manager does the rest, automatically logging on to password-protected information systems, enforcing password policies, monitoring all password-related events, and even automating user tasks, including password changes.
Citrix Branch Repeater: Citrix Branch Repeater appliances optimize your WAN links(in other words compresses ICA packets), giving your users maximum responsiveness and throughput at any distance. A Branch Repeater appliance is easy to deploy, because it works transparently. A twenty minute installation accelerates your WAN traffic with no other configuration required. You do not have to change your applications, servers, clients, or network infrastructure. Also, you can change them after Branch Repeater installation without affecting traffic acceleration. A Branch Repeater appliance needs reconfiguration only when your WAN links change.
Citrix Dazzle:
Dazzle provides users with self-service access to the applications and desktops they need to work productively. Icons for those applications and desktops can be presented on the local desktop, on the Dock, or in the Dazzle folder available from the Finder.
The new, easy-to-use interface allows users to subscribe to applications and desktops hosted on XenApp and XenDesktop servers with a single click, replacing the need for individual connection files used by earlier versions of the plug-in.
Merchandising Server:
Merchandising Server is a virtual appliance located in the datacenter that manages the setup, distribution and updates of plug-ins for Citrix Receiver. After performing a simple, one-time setup for Citrix Receiver, users automatically receive their plug-ins from Merchandising Server. Merchandising Server provides the administrative interface for configuring, delivering, and upgrading plug-ins for your users’ computers.
Hosted Applications:
A hosted application, also known as Internet-based application, web-based application, online application and Application Service Providers (ASPs) are software applications where the software resides on servers that are accessed through the Internet instead of the more traditional software that is installed on either a local server or on individual PCs.
Hosting an application means that the application is installed on the Terminal Server and delivered to an end user with the application processing occuring mainly on the Terminal Server with the end user just seeing keyboard/window refreshing from their session.
Reduced costs, instant deployment, easier to maintain and reduced administration are among some of the main benefits.
Citrix XTE Service:
XTE stands for eXtensible Transformation Engine. XTE is a common infrastructure component used in multiple Citrix products. The XTE Service hosts the Password Manager Web services. This service is the same XTE Service that MetaFrame Presentation Suite uses; however, it uses added modules with a different configuration. The added modules and configurations prevent the Password Manager Service from being installed on a machine with other Citrix applications that use the XTE Service. In addition, the security model recommends the Password Manager Service server be placed in a physically secure location with limited access.
Citrix XTE server is for SSL Relay, Session Reliability and Password Manager Web Services. The name of the service for Session Reliability is ” Citrix XTE “. When you have any session reliability issues, restart XTE service and check.
SSL Relay:
The SSL Relay is a component that uses SSL to secure communication between Web Interface servers and server farms. The SSL Relay provides server authentication, data encryption, and message integrity for a TCP/IP connection. The SSL Relay is provided by the Citrix XTE Service.
The SSL Relay operates as an intermediary in the communication between the Web Interface server and Citrix XML Service. When using the SSL Relay, the Web server first verifies the identity of the SSL Relay by checking the relay’s server certificate against a list of trusted certificate authorities.
Application Streaming:
Application streaming simplifies application delivery to users by virtualizing applications on client devices. Administrators can install and configure an application centrally and deliver it to any desktop on demand.
Use the application streaming feature to install and configure an application on one file server in your App Hub, publish the application using the XenApp publishing wizard, and deliver it to any desktop or server on demand. To upgrade or patch an application, you make the updates only in the location where you stored the application. Application streaming augments application delivery not only to user desktops, but also to servers in your server farms.
Other Definition for Streaming:
Streaming an application means installing it into a profile and running it in an isolation environment. The application can then be either streamed to a server and then published to an end user or the application can be streamed directly to the client and even ran offline (like a laptop that is off the network). Not having the application directly installed on the servers can help with server/appmanagement. The application profile is just pulled down from a share location and once loaded the application launches.
Application streaming offers the following features:

• Apps cannot interfere with each other.Therefore you don’t have to regression
• Test all your applications every time you update or deploy a new app
• You can run multiple versions of the same app on the same server or workstation
• You can easily upgrade an application by repackaging and pointing the published app at the new package.
• Rollback is the same as above.
• A method to deploy apps to multiple workstations and servers.
• Apps that won’t work in a multi user environment will often work when virtualised.
• Install once, deliver anywhere
• seamless updates
• Application isolation
• Application caching
• Wide range of target environments
• Dual mode streaming
• Easy delivery of applications to farm servers
• Consistent end-user experience
• Offline access
• Once configured and delivered, applications are available to the user while disconnected from the network.
• Easy disaster recovery

All the above mentioned benefits are explained clearly in the PDF at link: Application Streaming
Streamed to Server: Application(Streamed App) caching will be done on server.
Streamed to Client: Applications caching will be done on client and resources wil be client ones. Even disconnected from server, users can use the application. Default time for the cached application is 21 days. It can be configured with minimum 2 days and maximum is 365 days. It can be configured by policy.
Farm Enviornment

You should already be familiar with client-server architecture, redirection, and application publishing.
This illustration shows a basic deployment of XenApp.

Citrix XML Service and the Citrix XML Broker
The Citrix XML Broker functions as an intermediary between the other servers in the farm and the Web Interface. When a user authenticates to the Web Interface, the XML Broker:

• Receives the user’s credentials from the Web Interface and queries the server farm for a list of published applications that the user has permission to access. The XML Broker retrieves this application set from the Independent Management Architecture (IMA) system and returns it to the Web Interface.
• Upon receiving the user’s request to launch an application, the broker locates the servers in the farm that host this application and identifies which of these is the optimal server to service this connection based on several factors. The XML Broker returns the address of this server to the Web Interface.

The XML Broker is a function of the Citrix XML Service. By default, the XML Service is installed on every server during XenApp Setup. However, only the XML Service on the server specified in the Web Interface functions as the broker. (The XML Service on other farm servers is still running but is not used for servicing end-user connections.) In a small farm, the XML Broker is typically designated on a server dedicated to several infrastructure functions. In a large farm, the XML Broker might be configured on one or more dedicated servers.
The XML Broker is sometimes referred to as a Citrix XML Server or the Citrix XML Service. For clarity, the term XML Broker is used to refer to when the XML Service functions as the intermediary between the Web Interface and the IMA service, regardless of whether it is hosted on a dedicated server or collocated with other infrastructure functions. This illustration uses a large farm to show how the Web Interface and the XML Broker work together.
(1) The user connects to the Web Interface through the XenApp plug-in or a Web browser;
(2) the Web Interface contacts the XML Broker to determine which applications are available for this user;
(3) the XML Broker queries the IMA service for this information and returns the results to the Web Interface;
(4) the Web Interface displays the available applications to the user either through a Web page or by placing shortcuts directly on the user’s computer.

How Load Balancing Works
The load balancing (LB) feature distributes client requests sent to the system across several servers to optimize resource utilization. In a real-world scenario, a limited number of servers can provide service to a large number of clients. The servers can become overloaded causing a decrease in their performance. The system selects the server using the load balancing criteria and forwards the incoming client requests to it. Thus, the system balances the load on the servers.

Single Sign-on

Citrix Single Sign-on (formerly Citrix Password Manager) provides password security and single sign-on access to Windows, Web, and terminal emulator applications running in the Citrix environment as well as applications running on the desktop. Users authenticate once and Single Sign-on does the rest, automatically logging on to password-protected information systems, enforcing password policies, monitoring all password-related events, and even automating user tasks, including password changes.

Subscription Advantage and Licensing

When you purchase a new Citrix product, your purchase includes a one-year membership in Citrix Subscription Advantage. This membership entitles you to, among other benefits, any product updates, including major and minor releases, released during your membership period. For example, if you purchased XenApp, Advanced edition on July 22, 2009, you are entitled to any updates released for XenApp, Advanced edition until July 21, 2010. After your initial one-year membership period expires, you may choose to renew your Subscription Advantage membership. After paying Citrix for your renewal, you must go to citrix.com and download a license file containing your renewal license.

Note: A Subscription Advantage membership and its associated license are distinct from your license to run the product. If you do not renew your Subscription Advantage membership, your Citrix products do not stop working; however, you are not entitled to any software releases after it expires.

Function of the Local Host Cache

   

Each XenApp server stores a subset(a portion or part from the whole part, but not full part) of the data store in the Local Host Cache (LHC). The LHC performs two primary functions:
• Permits a server to function in the absence of a connection to the data store.
• Improves performance by caching information used by ICA Clients for enumeration and application resolution.
The LHC is an Access database, Imalhc.mdb, stored, by default, in the \Citrix\Independent Management Architecture folder.
The following information is contained in the local host cache:
• All servers in the farm, and their basic information.
• All applications published within the farm and their properties.
• All Windows network domain trust relationships within the farm.
• All information specific to itself. (product code, SNMP settings, licensing information)
On the first startup of the member server, the LHC is populated with a subset of information from the data store. From then on, the IMA service is responsible for keeping the LHC synchronized with the data store. The IMA service performs this task through change notifications and periodic polling of the data store.
If the data store is unreachable, the LHC contains enough information about the farm to allow normal operations for an indefinite period of time, if necessary. However, no new static information can be published, or added to the farm, until the farm data store is reachable and operational again.
Note: Prior to Presentation Server 3.0, the LHC had a grace period of only 96 hours; this was due to farm licensing information being kept on the data store. Once the 96 hour grace period was up, the licensing subsystem would fail to verify licensing, and the server would stop accepting incoming connections.
Because the LHC holds a copy of the published applications and Windows domain trust relationships, ICA Client application enumeration requests can be resolved locally by the LHC. This provides a faster response to the ICA Client for application enumerations because the local server does not have to contact other member servers or the zone data collector. The member server must still contact the zone data collector for load management resolutions.
In some instances it can be necessary to either refresh or recreate the local host cache. The sections below describe these situations.
Refreshing the Local Host Cache
If the IMA service is currently running, but published applications do not appear correctly in ICA Client application browsing, force a manual refresh of the local host cache by executing dsmaint refreshlhcfrom a command prompt on the affected server. This action forces the local host cache to read all changes immediately from the data store.
A discrepancy in the local host cache occurs only if the IMA service on a server misses a change event and is not synchronized correctly with the data store.
Recreating the Local Host Cache
If the IMA service does not start, the cause may be a corrupt LHC.
If you have made extensive changes to the farm data store, such as publishing various applications, adding or removing servers from the farm, or creating new policies.
If you must clean the farm data store, using the DSCHECK utility, you should then rebuild the LHC on each of the servers in your farm, once the data store has been cleaned.
Steps to recreate the Local Host Cache
IMPORTANT: The data store server must be available for dsmaint recreatelhc to work. If the data store is not available, the IMA service cannot start.
1. Stop the IMA service on the XenApp server, if it is started. This can be done using the command: net stop imaservice, or from services.
2. Run dsmaint recreatelhc, which renames the existing LHC database, creates a new database, and modifies the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\Runtime\PSRequired key to 1. Setting the value PSRequired to 1 forces the server to establish communication with the data store in order to populate the Local Host Cache database. When the IMA service is restarted, the LHC is recreated with the current data from the data store.
3. Restart the IMA service. This can be done via the command line, net start imaservice, or from services.
Note: For XenApp 6 or later the registry key path is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ RUNTIME\PSRequired to 1.
There is also an available built-in utility to check the Local Host Cache called LHCTestACLsUtil.exe file located in C:\Program Files (x86)\Citrix\System32 of the XenApp server. To run this utility, you must have local administrator privileges.

XML and LHC

XML
The XML service handles all client communication. Client communication like user authentication to the published app list, resolving the Citrix Zone Preference Policies, user application requests, and user connections requests. The XML service also hosts the Secure Ticket Authority that is used for storing secure tickets for user session requests and session reliability in case of a network interuption. Citrix Web Interface is considered a web-based client component, that can also be used in conjunction with Program Neighborhood Agent.
The XML service should be running on all XenApp servers, and might be sharing a port with IIS. The default XML services port is port 80.
Local Host Cache

A subset of data store information, the local host cache, exists on each server in the farm, providing each member server with quick access to data store information. The local host cache also provides redundancy of the data store information, if for example, a server in the farm loses connectivity to the data store.
When a change is made to the farm’s data store, a notification to update the local host cache is sent to all the servers in the farm. However, it is possible that some servers will miss an update because of network problems. Member servers periodically query the data store to determine if changes were made since the server’s local host cache was last updated. If changes were made, the server requests the changed information.

Refreshing the Local Host Cache

You can force a manual refresh of a server’s local host cache by executing dsmaint refreshlhc from a command prompt. This action forces the local host cache to read all changes immediately from the farm’s data store. Refreshing the local host cache is useful, for example, if the Citrix Independent Management Architecture (IMA) Service is running, but published applications do not appear correctly when users browse for application sets.
A discrepancy in the local host cache occurs only if the IMA Service on a server misses a change event and is not synchronized correctly with the data store.

Recreating the Local Host Cache

You can manually create the local host cache from the farm’s data store. If the IMA Service fails to start or you have a corrupt local host cache, you may need to recreate it.

To recreate the local host cache, stop the IMA Service and then run the command dsmaint recreatelhc. Running this command performs three actions:

• Sets the value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ RUNTIME\PSRequired to 1.
• Deletes the existing local host cache (Imalhc.mdb)
• Creates an empty local host cache (Imalhc.mdb)

You must restart the IMA Service after running dsmaint recreatelhc. When the IMA Service starts, the local host cache is populated with fresh data from the data store.
The data store server must be available for dsmaint recreatelhc to work. If the data store is not available, the IMA Service fails to start.
Tuning Local Host Cache Synchronization

You can adjust the interval by which member servers query the farm’s data store for missed changes. The default interval is 30 minutes. In most cases, this default setting is sufficient.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

You can configure the interval by creating the following registry key on each server you want to adjust, with the value expressed in hexadecimal notation:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\IMA\ DCNChangePollingInterval (DWORD)
Value: 0x1B7740 (default 1,800,000 milliseconds)
You must restart the IMA Service for this setting to take effect.
Most changes made through the Citrix AppCenter are written to the data store. When you open one of these tools, it connects to a specified server. The Citrix Independent Management Architecture (IMA) Service running on this server performs all reads and write operations to the data store for the AppCenter.
If the data store is experiencing high CPU usage when few read or write operations to the data store are occurring, it is possible that the data store is not powerful enough to manage a query interval of 30 minutes. To determine whether or not the data store query interval is causing the high CPU usage on the data store, you can set the query interval to a very large number and test CPU usage. If the CPU usage returns to normal after you set a large query interval, the data store query interval is probably the cause of the high CPU usage. You can adjust the query interval based on performance testing.

To test the query interval, set the interval to 60 minutes and then restart all the servers in the farm. If the data store is still experiencing constant high CPU usage, increase the query interval further. If the CPU usage returns to normal, you can try a smaller value. Continue these adjustments until data store CPU usage is normal.
Important: Do not set the data store query interval higher than necessary. This interval serves as an important safeguard against lost updates. Setting the interval higher than necessary can cause delays in updating the local host cache of the farm’s member servers.

About Receiver Storefront

Citrix StoreFront authenticates users to XenDesktop sites, XenApp farms, and AppController, enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver or Receiver for Web sites. The StoreFront database records details of users’ application subscriptions to enable synchronization of those applications across all their devices.Receiver Storefront is an alternative to WebInterface in future. Has got very user interactive features.
Receiver Storefront installation is available as a role while installing xenapp 6.5 or you can download the setup from mycitrix.com and install it manually. While you have installed receiver storefront manually, you need to configure it via xenapp server role manager wizard.
After installing and configuring Receiver Storefront, we will find 5 options.
Authentication shows options, How the authentication must happen.
Stores operates as  services site(in WI).
Receiver for web operates as website(in WI). You can use it by right clicking on receiver for web and create new website.
Gateways option is for CAG
Beacons are used to determine users are from internal or external n/w
After creating Stores and Receiver for web, open your web browser and enter the web address that you created in Receiver for Web. If you want to use Receiver Storefront for Receiver, open preferences in your receiver and update the Stores address and save. Provide your username and pwd if prompted. Now you can access your applications as you do normally with WI. Reciever Storefront can also work behind CAG.

Application Streaming Utilities

CLIENTCACHE
This utility is used to change the client cache location or the maximum cache size. By default, when applications are streamed the target is extracted and cached in the \Program Files\Citrix\RadeCache directory. The default size of the client cache is 1024 megabytes (MB), which is equal to one gigabyte (GB). This tool is executed on the computer with the Streaming Client installed; it is located in the \Program Files\Citrix\Streaming Client directory. To run this utility, browse to the \Streaming Client directory and click the clientcache.exe executable.
More details about this tool can be found in CTX112526 – Citrix Application Streaming Guide – EN.
DSMAINT RECREATERADE
This utility is used to re-create the streaming offline license access database on the server running Presentation Server. This database may need to be re-created if corruption is suspected. The database is called radeoffline.mdb and is located in the \Program Files\Citrix\Independent Management Architecture directory. This database exists on each server running Presentation Server in the farm. This utility is included with the Presentation Server installation. To run this utility, stop the Citrix Independent Management Architecture service, open a command prompt on the server running Presentation Server, and issue the dsmaint recreaterade command.
RADECACHE
This utility is used to flush the cached files or registry entries on the client computer. It is located on the computer with Streaming Client 1.1 installed. At the command line, browse to the \Program Files\Citrix\Streaming Client directory and issue the command using the syntax below:
radecache [options] /flush:””
Options for this command:
-i = flush install root, files, and registry
-if = flush install root, files only
-ir = flush install root, registry only
-u = flush user root, files and registry
-uf = flush user root, files only
-ur = flush user root, registry only
flush all – radecache /flushall
Usage example:
radecache –i /flush:“adobe”
RADEDEPLOY
This utility is used to pre-deploy streamed application packages to a client or server running Presentation Server. Profile pre-deployment helps avoid overloading the file servers and network. During pre-deployment, the profile target is extracted and then copied and executed locally from the\Program Files\Citrix\Deploy directory. The utility is located on the components CD-ROM. To use Radedeploy, copy it to the computer with the Streaming Client installed. Use the syntax described below to run this utility:
radedeploy [-m] /deploy:”\\server\share\app.profile”
This is used to pre-deploy applications to the client. Filename is the .profile file. File names with embedded spaces should be surrounded with quotations (“). 
[-m] means to monitor the deployment until the process completes.
radedeploy /enum
radedeploy /delete:BrowserName
The command above is used to delete offline applications that have already been deployed to the client machine in the \Program Files\Citrix\Deploy folder. BrowserName refers to the name of the deployed application to be deleted. The application name (that is, BrowserName) can be found by issuing the radedeploy /enum command and looking under the Name column.

Usage examples:
radedeploy /deploy:\\2003Server\packages\adobe\adobe.profile
radedeploy /delete:Adobe
RADEMAINT OFFLINELICENSE
This utility is used to administer streaming offline licenses. It is located on the Presentation Server CD-ROM in the \Support\debug directory. Copy the utility to the server running Presentation Server and run the utility through the command line. Use the syntax described below:
Rademaint OFFLINELICENSE
/r:username – removes the offline license for the specified user
/l:[username (or *)] – lists the offline license for the specified user or all users if [ * ] is specified
/s – lists all of the sessions in the session cache
Usage example:
Rademaint OFFLINELICENSE /r:user1

Printer Definitions

Print Migrator:
Print Migrator provides complete backup, restore and migration operations for windows NT-based operating systems from Windows NT 4 to Windows 2003.
Stress Printer Tool:
This tool can be used to simulate multiple sessions autocreating printers using same printer driver.
Citrix Printing tool:
Citrix Printing tool 3.1 helps configuring and troubleshooting the citrix printing subsystem on xenapp, xenapp online plugin and xendesktop.
Print Detective:
Print Detective is an information gathering utility that can be used for troubleshooting problems related to print drivers. It enumerates all printer drivers from the specified windows machine, including driver specific information. It can also be used to delete specified print drivers. It allows for log file capabilities and provides a command-line interface as well.
Stress printers and print detective are the two tools that are designed to work with drivers.

XenApp 6.5 Best Features

XenApp 6.5 brings a host of features and benefits that most companies will need as the technology continues to evolve and user requirements continue to expand.Here are the list of features and explanation given below:
Simplified Installation
Single Management Console
Worker Groups
Policies and GPO Integration
Merchandizing Server and Windows Receiver
HDX
Provisioning Server
MultiStream ICA
Integration with Desktop Director
Pre-launch, Session Linger, and Fast Reconnect
Controller and Session-Host Feature

Simplified Installation

Beginning with XenApp 6 and continuing with XenApp 6.5, Citrix introduced a number of enhancements to the installation wizard. Before we discuss the roles wizard, let’s look at a typical Citrix Farm Architecture.
Small Citrix farms typically have the following roles:

1. Web Interface Server
2. License Server
3. XenApp Server

Although the Farm Data Store is an essential part of the Farm, it is not technically a “role.” It is a database server, typically SQL, that contains critical Farm Data. During the configuration wizard for XenApp, the administrator designates where the Data Store will be located. If a server is designated as a controller during installation, then it can become a Zone Data Collector (ZDC). If it is designated as a worker, then it will never attempt to become a ZDC and is, therefore, a member server.
Larger Citrix XenApp Farms are much more complex. They include components like Provisioning Services, EdgeSight monitoring, Dedicated Data Collectors, Remote Access Devices and increased redundancy with all essential servers.
Another change to the install process is that there is no configuration required during installation. This makes the install of each of the roles very simple. Once the installation is completed, the administrator is prompted to configure each of the roles.

Single Management Console

One challenge for Citrix administrators over the years has been the need for different consoles for many of the Citrix management tasks. In XenApp 6.0, Citrix has consolidated almost all administrative tasks in one console called the Delivery Services Console. In XenApp 6.5, Citrix has enhanced this console and changed the name to AppCenter.
With the AppCenter Console, an administrator can use one console to perform things like Publishing Applications, Creating Policies, Managing Worker Groups and Zones, along with many other tasks. With one console, you can now manage hundreds of servers and applications in a Citrix Server Farm.

Worker Groups

Worker Groups allow you to manage all servers within an App Silo as one object. This allows you to publish applications and set policies with a Worker Group rather than individual servers, making managing complex real-world Citrix environments much easier.
Another benefit of Worker Groups is the ability to perform Load Balancing between geographical locations or direct users to the XenApp servers closest to their current location.

Policies and GPO Integration

Citrix Administrators can now use GPOs and Organizational Units to manage their Citrix Policies, just like they do their Microsoft Policies, giving Administrators one tool to manage user rights. If you do not have rights at an Active Directory level, Citrix does still allow for IMA-Based Polices that are stored in the Citrix Data Store. These policies are created using the Delivery Services Console; however, they are superseded if GPO Based Citrix Policies exist.
New in XenApp 6.5 is the ability to filter policies in the XenApp Policy Editor. For example, you can look at XenApp 6.0 polices only, or vice versa, only look at what is new in XenApp 6.5.

Merchandizing Server and Windows Receiver

Merchandising Server allows administrators to centrally deploy and update Citrix clients. Merchandising Server is a virtual appliance that is free to download and import within XenServer.

HDX

Many of you have probably heard of HDX. It is short for High Definition Experience and represents a host of technologies (more than 60) that allow the user experience to be the best ever when connecting to hosted desktops or applications. See http://​hdx​.citrix​.com for a list of some of the HDX Technologies included in XenApp.

Provisioning Server

Provisioning Server is a technology that allows Citrix administrators to create a single master virtual disk (vDisk) and then connect multiple desktops or servers to that vDisk, all of which boot simultaneously.
With XenApp, we can leverage this technology to keep all of the Application Servers in a Citrix Farm consistent with the same applications, hotfixes, and patches. This ensures that users receive the same experience regardless of which server they are load-balanced to. With this technology, administrators can now update many servers by updating a single vDisk, making administering large server farms much simpler.

MultiStream ICA

MultiStream ICA is a new feature introduced with XenApp 6.5. In previous versions of Citrix, QoS (Quality of Service) was difficult with the ICA protocol because the various channels all flowed within the port 1494 or 2598 when using session reliability. If QoS were enabled, it would prioritize all types of ICA traffic (graphics, keyboard, mouse, audio, printing, clipboard, drive mapping, etc.). MultiStream ICA Protocol splits virtual desktop traffic into 5 streams – real time, interactive, background, bulk, and RTP Voice – to enable network administrators to prioritize traffic by type and maintain QoS with existing network tools.

Integration with Desktop Director

In previous versions of XenApp, if you wanted to give the Help Desk and other associates within your company administrative access to Citrix, you only had the option of giving them access to the same consoles you, as an Administrator, use. These consoles were notorious for being somewhat complex, and they required some training for new associates. With the introduction of XenApp 6.5, Citrix has given Desktop Director the ability to connect to XenApp. Desktop Director is a web-based dashboard and console that allows Help Desk and other support staff to manage and monitor XenApp sessions.

Pre-launch, Session Linger, and Fast Reconnect

This collection of features improves the user experience by eliminating delays when launching and maintaining sessions. First, with the use of Session Pre-launch policy settings, a session can be started automatically when a user logs on to the farm. By implementing Session Linger policy settings, sessions remain alive for a configurable period before termination, rather than terminating when users close applications. Finally, Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays when users reconnect to existing sessions.

XenApp 6.5 Features

Below are the new features in XenApp 6.5

• Delivery services console renamed to Citrix AppCenter
• Integration with windows desktop experience
• Dynamic Datacenter Provisioning
• Session Pre-launch, Session-Linger and Fast Reconnect
• Controller and Session-Host feature
• new profile settings
• citrix migration center
• Print optimizations
• Receiver storefront

New! XenApp 6.5 Available Now!

These are exciting times for desktop virtualization.  The industry is growing and Citrix is leading the charge.  The XenDesktop product line is getting plenty of well-deserved attention, but today Citrix is also announcing exciting new enhancements for XenApp 6.5. Whether included as a component of XenDesktop Enterprise and Platinum or deployed as a standalone product, XenApp has long been recognized as the de-facto standard in on-demand app delivery.  Now with turbo-charged app launches and a seamless multimedia experience over any network, XenApp 6.5 makes the user experience better than ever.
Instant App Access
The XenApp 6.5 feature generating the most excitement among customers is Instant App Access.  Gone are the days when users would have to wait several seconds for the creation of an ICA session before their application launched.  By creating an ICA session immediately upon user log-in to Citrix Receiver, Session Pre-Launch dramatically reduces overall application launch times. Since the ICA session is created even before the user clicks the application icon, the only remaining time to wait is for the application launch itself.  Depending on the application, this can be nearly instantaneous.
Similar technology allows an ICA session to linger after users close their last published app so that the next application launch is just as instantaneous.  While these features do consume a license, the time periods for lingering or pre-launch are configurable by the IT admin.
Seamless multimedia experience with HDX
With only a few exceptions, all of the HDX enhancements seen in XenDesktop 5.5 are also applicable for XenApp 6.5. For example, significant updates to HDX MediaStream for Flash mean that Adobe® Flash® content can be rendered locally over more network conditions than before.  This dynamically takes advantage of computing resources at the end point, resulting in even higher server scalability and a great user experience even at up to 300ms round-trip latency.
Multi-Stream ICA
IT administrators now have the option of delivering XenApp ICA traffic over up to four TCP/IP streams. Now instead of prioritizing the entire ICA pipeline over HTTP traffic, this feature enables more granular control for Quality of Service (QoS) routing.  Now customers can provide superior audio/visual quality for apps delivered over the WAN for example without disrupting other HTTP traffic.
Any Device, Anywhere with Citrix Receiver
XenApp 6.5 takes advantage of new Citrix Receiver enhancements for extreme multi-tasking, faster Windows app performance and advanced Linux device support. Customers can now deliver self-service apps to more than one billion devices, including PCs, Macs, tablets, smartphones, and thin clients – and all major device operating platforms, including new environments like iOS, Android, and Google ChromeOS.   Add it all up and we’re talking about over 1 Billion devices.
Enhanced Desktop Experience
Previously provided as an add-on pack for XenApp 6.0, support for an enhanced desktop experience is now included as an integrated feature of XenApp 6.5. IT can transform the typical server desktop published by XenApp.  This feature enables support for themes, installs accessory apps, and allows for the display of high-res wallpapers.  With a Windows-7 like Start Menu and taskbar, users can enjoy the look and feel of a Windows 7 desktop, while IT can benefit from the server density and locked down image management of a hosted shared desktop
Desktop Director
When end-users need support help with their XenApp delivered apps, help desk support staffs can use the popular Desktop Director console that now includes the integrated capability to assist users with applications delivered by XenApp and with desktops delivered by XenDesktop.
Dynamic Data Center Provisioning
Now XenApp 6.5 deployments can be scaled in record time by creating “controller” or “worker” roles in a XenApp server farm.  Because workers in the farm need to sync much less data, fewer overall database transactions are required.  Plus, these new roles make the process of joining a large number of servers to a XenApp farm faster and easier.
These are just a few of the new features in XenApp 6.5.  For a full list of all features and a comparison to previous versions, you can refer to the new comparative feature matrix.
Controller and Session-Host features

About XenApp 6.5

New features included in Citrix Xenapp 6.5 are:
Server Platform Support
Citrix AppCenter
Session Pre-launch, Session Linger, and Fast Reconnect
Controller and Session-Host feature
Integration with Desktop Director
Citrix HDX EnhancementsMigration Center with Graphical User InterfaceImproved Performance for Pooled DesktopsPrinting Optimization
Receiver Storefront
All the above features are explained below.
About Citrix XenApp 6.5 for Windows Server 2008 R2
This release includes several new features and enhancements to Citrix XenApp.
What’s New

• Server Platform Support
  The XenApp software can be installed on the following platforms. For all system requirements, see System Requirements.
  

  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2008 R2 Service Pack 1
• Windows Desktop Experience IntegrationInstalled by default when installing the XenApp server role, this feature provides a Windows 7 look and feel including desktop customization. PowerShell script options enable administrators to control desktop and environment defaults while allowing end users to customize their desktops.When installed and enabled, this feature also removes the Windows Server Manager Console from the XenApp server’s toolbar and relocates the Citrix XenApp administrative tools such as the AppCenter to the Start menu’s Administrative Tools\Citrix folder. See Delivering XenApp to Software Services Subscribers for more information.
• Citrix AppCenterThe AppCenter provides a streamlined interface for performing management functions. From the AppCenter, you can manage components administered through other Citrix products, such as Citrix Secure Access and Citrix Single Sign-On. For Citrix XenApp, you can configure and monitor servers, server farms, published resources, and sessions.
• Session Pre-launch, Session Linger, and Fast ReconnectThis collection of features improves the user experience by eliminating delays when launching and maintaining sessions. By using configurable Session Pre-launch policy settings, a session is started automatically when a user logs on to the farm. By implementing Session Linger policy settings, sessions remain alive for a configurable period before termination, rather than terminating when users close applications.Fast Reconnect, built into XenApp and requiring no configuration, helps minimize delays when users reconnect to existing sessions.
• Citrix HDX Enhancements
  XenApp includes the latest HDX enhancements:
  

  • HDX MediaStream Flash Redirection
  • Audio Settings
  • Multimedia Conferencing with HDX RealTime
  • Increased 2D and 3D Application Scalability and Performance
  • Assigning Priorities to Network Traffic
  • Dynamic Windows Preview Support
• Migration Center with Graphical User InterfaceWith the choice of using a PowerShell cmdlet command line or graphical user interface, XenApp administrators can import application, folder, server configuration, and other XenApp object types from farms running previous versions of XenApp into XenApp 6.5 farms. SeeXenApp Migration Center for requirement and installation information.
• Improved Performance for Pooled DesktopsApplication launch time in pooled desktop environments is improved through the use of virtual hard disks. Using the Streaming Profiler, virtual hard disks can be created when profiling an application. When the application is launched for the first time, the virtual hard disk is mounted and all the profile contents are copied to the virtual hard disk. For all subsequent launches, the application is launched from the virtual hard disk, resulting in a speedier launch.
• Printing OptimizationXenApp printing features include improved print session performance, lower bandwidth required for printing, and improved user experience when printing to redirected client printers. Universal Printing policy settings enable the administrator to control print quality, spooling, and optimization defaults. See the printing topics in the Manage node of this documentation for more information.
• Receiver StorefrontReceiver Storefront authenticates users to XenDesktop sites and XenApp farms, enumerating and aggregating available desktops and applications into stores that users access through Citrix Receiver or a Web page.If your XenApp installation media or download package contains the Citrix Receiver Storefront folder, you can install the Receiver Storefront through the XenApp Server Role Manager provided in that media/package. If your installation media or download package does not contain the Citrix Receiver Storefront folder, you can download an updated XenApp package from My Citrix.

Copy Clients in XenApp 6.5

This article describes how-to setup client deployment directly from the Web Interface (5.4.0). When the Web Interface is installed directly from the XenApp installation, there is no question/part where the clients are installed from the DVD.
First we copy the clients from the folder: “Citrix Receiver and Plug-ins” on the installation source to the following location: “C:\Program Files (x86)\Citrix\Web Interface\5.4.0\Client”


Then navigate to: “C:\inetpub\wwwroot\Citrix\XenApp\conf” and open (with notepad) WebInterface.conf

Search for the following section:

Uncomment the client which you want to deploy. If you want to deploy everything then it looks like this:

But the “Citrix Online Plugin” is replaced bij the Receiver. So the CitrixIcaWin32 line must be changed to:
ClientIcaWin32=Filename:CitrixReceiverEnterprise.exe,Directory:Windows,Mui:Yes,ClassID:238f6f83-b8b4-11cf-8771-00a024541ee3
And then the config file look like this:

Save it, restart the Web Interface (iisreset or restart server )
Open “Client Deployment” in the Web Interface management console.

Select: “Perform client detection at logon” (and/or Offer upgrades for clients)

Select: “Deploy a native client”

Now the following screen will appear when a user hasn’t got a client and want to access his applications:

Update: If the PNAgent isn’t required for your environment. The use the CitrixReciever.exe file. So the ClientIcaWin32 line would be:
ClientIcaWin32=Filename:CitrixReceiver.exe,Directory:Windows,Mui:Yes,ClassID:238f6f83-b8b4-11cf-8771-00a024541ee3

XenApp 6.5 Pre-Launch

To pre-launch applications to user devices

Use the pre-launch feature to reduce application launch time at high-traffic periods. For example, if your environment includes a large number of users who launch the same application within a ten-minute time-frame, the rapid succession of logon requests can overwhelm servers and slow down application launch for all users. The pre-launch feature allows a pre-launch session to be created when a user logs on, or at a scheduled time if the user is already logged on. This pre-launch session reduces the launch time of the first application. The default application ctxprelaunch.exe runs in the session, but is not visible to the user.

Considerations:

• When a pre-launch session is created, it takes up a license immediately, even if the user does not launch an application.
• When you enable this feature for an application, the setting applies to all users and servers configured for the application; in addition, the pre-launch session created for the application is also available for all other published applications on the listed servers.

To customize the inactivity behavior for the pre-launch application, configure the Citrix User policy for Session Limits:

• Pre-launch Terminate Timer IntervalMaximum amount of time before the pre-launch application exits (60 minutes by default). Starting a user application in the session also terminates the pre-launch application. Once the pre-launch application exits, the session remains alive if the user’s applications are running or if you configured session lingering.
• Pre-launch Disconnect Timer Interval Amount of time before the pre-launch application disconnects the session (60 minutes by default). Once disconnected, the session gives up the XenApp license. When a user launches an application, the session is reconnected. This timer does not disconnect a session if a user launches an application. If the interval is not configured, the pre-launch session is not ever disconnected.

Note: Customizing the pre-launch feature using Administrative Templates is not supported. However, you can change the pre-launch configuration by modifying the registry values, located at:

• For 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Prelaunch andHKEY_CURRENT_USER\Software\Citrix\ICA Client\Prelaunch
• For 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Prelaunch

To enable the pre-launch session:

1. In the AppCenter, from the navigation pane, select the server.
2. From the Applications list, select an application.
   Note: Select an application that is published for the groups of users and servers that are eligible for the pre-launch session.
3. From the Actions pane, select Other Tasks > Create pre-launch application.
4. This task creates a copy of the application with all its properties, users, and servers, and PreLaunch precedes the application name. This “application” is not enumerated to users. Refer to the table below for the application properties that you can modify.

Properties and tasks for pre-launch applications
The following table lists the properties and tasks that are inherited or configured for pre-launch applications.
The application name, display name, description, and icon are visible only in the AppCenter and do not apply to the pre-launch application.

Inherited from the original application. Modifications are applicable for a pre-launch application.	Not applicable for a pre-launch application. Modifications are not used.
Properties: Enable/disable application Servers Users Location Access conditions Access gateway filters Client audio requirement Connection encryption requirement Encryption level Session window color depth	Properties: Hide disabled application: The application is always hidden. Application type: The type is always an installed application. Working directory: The directory is always set to Systems32 folder in XenApp installation location. You can change this by editing the pre-launch application properties. Client application folder: The pre-launch application is not listed on the user device. Add to client’s start menu: The pre-launch application is not visible on the user device. Add shortcut to client’s desktop: The pre-launch application is not visible on the user device. File types: The pre-launch application does not have any associated file types. Maximum instances: Always one instance per user. Allow only one instance of application for each user: Always only one instance of the pre-launch application. If you configure more than one pre-launch application of the server and user combination, additional instances are not launched. Application importance: The pre-launch application is always the first application launched. Session window size: The pre-launch application is not visible on the user device. Hide application title bar: The pre-launch application is not visible on the user device. Maximize application at startup: The pre-launch application is not visible on the user device.
Tasks: Disable/enable application Duplication application Move to folder Delete application Refresh user data Attach application to a load evaluator

Posted in Citrix eDocs

Reducing Application Launch Time

Use the session pre-launch feature to reduce application launch time during normal or high traffic periods; thus, giving the user a better experience. The pre-launch feature allows a pre-launch session to be created when a user logs on to Receiver, or at a scheduled time if the user is already logged on. This pre-launch session reduces the launch time of the first application. The default application ctxprelaunch.exe is running in the session, but it is not visible to the user.
There are two types of pre-launch:

• Just-in-time pre-launch. Pre-Launch starts immediately after the user’s credentials are authenticated whether or not it is a high-traffic period.
• Scheduled pre-launch. Pre-launch starts at a scheduled time. Scheduled pre-launch starts only when the user device is already running and authenticated. If those two conditions are not met when the scheduled pre-launch time arrives, a session does not launch. To spread network and server load, the session launches within a window of when it is scheduled. For example, if the scheduled pre-launch is scheduled for 1:45 p.m., the session actually launches between 1:15 p.m. and 1:45 p.m.

Typically, you can use just-in-time pre-launch for normal traffic periods and scheduled pre-launch for known high-traffic periods.
An example of a high-traffic period – if your environment includes a large number of users who launch applications during peak periods such as when users start work or return from lunch, the rapid succession of logon requests might overwhelm servers and slow down application launch for all users.
Configuring pre-launch on the XenApp server consists of creating, modifying, or deleting pre-launch applications, as well as updating user policy settings that control the pre-launch application. See To pre-launch applications to user devices for information about configuring session pre-launch on the XenApp server.
Caution: Editing the Registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
Customizing the pre-launch feature using the icaclient.adm file is not supported. However, you can change the pre-launch configuration by modifying registry values during or after Receiver installation.
Receiver for Enterprise is a requirement for pre-launch.
Registry value for Windows 7, 64-bit
The value for Windows 7, 64-bit, is: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Prelaunch.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Prelaunch – Enables different users on the same user device to have different settings. It also allows a user to change the configuration without administrative permission. You can provide your users with scripts to accomplish this.
Name: State
Values:
0 – Disable pre-launch.
1 – Enable just-in-time pre-launch. (Pre-Launch starts after the user’s credentials are authenticated.)
2 – Enable scheduled pre-launch. (Pre-launch starts at the time scheduled in Schedule.)
Name: Schedule
Value:
The time (24 hour format) and days of week for scheduled pre-launch entered in the following format:
HH:MM|M:T:W:TH:F:S:SU where HH and MM are hours and minutes. M:T:W:TH:F:S:SU are the days of the week. For example, to enable scheduled pre-launch on Monday, Wednesday, and Friday at 1:45 p.m., set Schedule as Schedule=13:45|1:0:1:0:1:0:0 . The session actually launches between 1:15 p.m. and 1:45 p.m.
Registry values for other Windows systems
The values for all other supported Windows operating systems are:HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Prelaunch andHKEY_CURRENT_USER\Software\Citrix\ICA Client\Prelaunch.
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Prelaunch – Written at installation, with default values.
Name: UserOverride
Values:
0 – Use the HKEY_LOCAL_MACHINE values even if HKEY_CURRENT_USER values are also present.
1 – Use HKEY_CURRENT_USER values if they exist; otherwise, use the HKEY_LOCAL_MACHINE values.
Name: State
Values:
0 – Disable pre-launch.
1 – Enable just-in-time pre-launch. (Pre-Launch starts after the user’s credentials are authenticated.)
2 – Enable scheduled pre-launch. (Pre-launch starts at the time scheduled in Schedule.)
Name: Schedule
Value:
The time (24 hour format) and days of week for scheduled pre-launch entered in the following format:
HH:MM|M:T:W:TH:F:S:SU where HH and MM are hours and minutes. M:T:W:TH:F:S:SU are the days of the week. For example to enable scheduled pre-launch on Monday, Wednesday, and Friday at 1:45 p.m., set Schedule as Schedule=13:45|1:0:1:0:1:0:0 . The session actually launches between 1:15 p.m. and 1:45 p.m.
HKEY_CURRENT_USER\SOFTWARE\Citrix\ICA Client\Prelaunch – Enables different users on the same user device to have different settings. It also allows a user to change the configuration without administrative permission. You can provide your users with scripts to accomplish this.
Name: State
Values:
0 – Disable pre-launch.
1 – Enable just-in-time pre-launch. (Pre-Launch starts after the user’s credentials are authenticated.)
2 – Enable scheduled pre-launch. (Pre-launch starts at the time scheduled in Schedule.)
Name: Schedule
Value:
The time (24 hour format) and days of week for scheduled pre-launch entered in the following format:
HH:MM|M:T:W:TH:F:S:SU where HH and MM are hours and minutes. M:T:W:TH:F:S:SU are the days of the week. For example, to enable scheduled pre-launch on Monday, Wednesday, and Friday at 1:45 p.m., set Schedule as Schedule=13:45|1:0:1:0:1:0:0 . The session actually launches between 1:15 p.m. and 1:45 p.m.

XenApp Slow Logons Troubleshooting

Below are some of the points where user might face slow logons in accessing citrix apps/desktops:
Winlogon Troubleshooting Steps
Before investing too much time in troubleshooting Citrix, be sure to log onto the Xenapp server via RDP to make sure that logons remain slow there as well.
If you want to know everything that is happening during the logon process, there are verbose logs that can be enabled.  In Server 2003, you can enable the USERENV logging by following the KB article: http://support.microsoft.com/kb/221833
If you are using Server 2008, then you can enable something similar following this process:
http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/224c95bc-e6b3-4b66-82e1-22de625b7dc6/
Let’s examine some of the usual suspects:
Networking Problems
In order to prove whether or not there are networking problems in an environment, you’ll need to use some networking tools.  Some admins like tools like Wireshark for tracing network communication so you can pick up dropped packets, etc.  Recently, I found a great tool for Citrix called SMCC, which can be installed on a trouble Xenapp server.  The tool will give you instant feedback on whether there are network problems impacting the server.  Read more about it here:
http://www.thomaskoetzing.de/index.php?option=com_content&task=view&id=133&Itemid=205
Roaming Profiles
Roaming profiles are public enemy number 1 in a Citrix environment.  While there have been countless articles written about why roaming profiles are no longer the best practice, we can never seem to get away from them.  They are especially popular in hospital environments where user customization is important, and this is the way they’ve always done it.  These profiles can often grow very large in size, and before the Citrix administrator knows it – he is dealing with profiles that are 200MB+ in size.  For this reason, when you get a slow Citrix logins call, the first place you should look would be at the profile size.  Beyond size you should also look at the location of your roaming profiles, because if there is a wan connectivity issue or any networking problems – it could also impact the speed at which the roaming profile is loaded.   Be aware that you can rule roaming profiles in or out quickly by creating a local account for testing purposes, with no reference to the roaming profile.
Windows Group Policy
When a virtualized application is launched through Citrix, it kicks off a huge stream of events.  Profiles are engaged, printers are mapped, and policies are applied.  Some companies have more complex GPO structure than others, so it’s important to keep it simple whenever possible.  In environments where a Citrix farm might have been “inherited” from previously staff that is no longer there, you will sometimes deal with clients who have no idea what their GPO’s are doing or how they are set up.  When you suspect GPO’s are the cause of slow application launch, you should isolate a single Citrix server into a fresh OU, and block inheritance completely.  Test logins again, and if they improve drastically – you know to focus your efforts on simplifying GPO’s in the environment.
Logon Scripts
Now that you can accomplish just about anything in Server 2008 via GPO, it’s logon scripts are something that should become a thing of the past shortly.  You will still see a lot of these in use in many environments today, so it’s important to know what they do and monitor them closely.  If a particular set of Citrix users is experiencing slow logons, it may be important to isolate what logon script is causing the issue.  You can test the logon script by running it line-by-line from the command prompt of the Xenapp server that you have isolated for testing.  If you find a particular line that hangs for an extended period of time, you’ll know to investigate more closely.
Drive Mappings
Drive mappings can work great for years, and suddenly stop working for many reasons.  Maybe a fileserver has a loose cable, or maybe there is a network problem.  The result can be a long delay during logon until the bad drive mapping times out.  Most of the time you will discover these bad drive mappings in a log on script, or perhaps a GPO.  Once again you can test by logging in with a user account that doesn’t have a log on script or GPO applied to it to see if the log in speed increases.
Printer Mappings
The volume of printers a user has may cause a slow login depending on how your Citrix policies are configured.  Best practice is usually to configure your printer mappings to load in the background during the logon process.  If you have a policy that says to do the opposite, you could be waiting a long time to see your virtualized application pop up.
Hotfix Level
There have been several hotfixes included in the various roll up packs for Xenapp and Presentation server over the years to address slow logons.  For this reason, it is best practice to always make sure you are on the most recent roll up package available from Citrix.  If you ever end up opening a case with Citrix support, you will find that this will be one of the first things they check for.
Conclusion
There are various causes of slow logons in Citrix environments.  Be methodical with your troubleshooting methods, and limit your troubleshooting to a single user account on a single server.  By experimenting with AD GPO’s and enabling/disabling logon scripts, you should be able to narrow down the root cause of the issue quickly.
References:
http://support.citrix.com/article/CTX101705
http://support.citrix.com/article/CTX115251
http://support.microsoft.com/kb/221833
http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/224c95bc-e6b3-4b66-82e1-22de625b7dc6/
http://www.thomaskoetzing.de/index.php?option=com_content&task=view&id=133&Itemid=205
http://support.citrix.com/article/CTX124015
http://www.brianmadden.com/blogs/brianmadden/archive/2006/03/06/troubleshooting-slow-citrix-and-terminal-server-logons.aspx
Posted in CitrixTechs.com
Also check Citrix’s “Optimization Guide: User Logon”
I would try:

• Removing or blocking as many GPOs as possible.
• Removing or disabling your logon script. Also check no one has snuck anything into usrlogon.cmd on the XenApp server
• Disable Citrix Client Drive Mapping
• Disable Citrix Client Printer Mapping
• Disable Roaming Profiles
• Check there are no dodgy entries in DNS or in your hosts file on the XenApp server