CITRIX

Citrix Terms

2016-04-30T04:31:00.002-05:00

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

2016-04-30T04:29:00.004-05:00

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

2016-04-30T04:29:00.001-05:00

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

2016-04-30T04:27:00.001-05:00

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

2016-04-30T04:26:00.004-05:00

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

2016-04-30T04:26:00.002-05:00

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

2016-04-30T04:24:00.004-05:00

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:

Web Interface Server
License Server
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

2016-04-30T04:24:00.000-05:00

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

2016-04-30T04:23:00.000-05:00

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:
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

2016-04-30T04:22:00.002-05:00

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

2016-04-30T04:20:00.001-05:00

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:

In the AppCenter, from the navigation pane, select the server.
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.
From the Actions pane, select Other Tasks > Create pre-launch application.
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

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

2016-04-30T04:19:00.002-05:00

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

Differences between ICA Timeout and Session Reliability:

2016-04-30T04:18:00.002-05:00

Session reliability works at the client end. It allows a client to reconnect and avoid inconvenience to a user during a short network interruption. Instead of removing all unresponsive apps and desktops from the client workbench, they will be kept open until the ICA client is able to reconnect to the terminal server. It uses port 2598 and is available with Advanced and Enterprise versions.
Whereas ICA Keep-Alive works at the server end allowing a server to detect broken sessions and put them into a ‘disconnected’ state if it can’t ping the client device. This makes sure that users can reconnect to disconnected sessions before the sessions timeout. It uses port 1494.

Reset/Change admin password for Citrix Licensing Server?

2016-04-30T04:17:00.001-05:00

A default administrator account ‘admin’ is created during installation of the Citrix License Administration Console. You can set the password for this account during installation.
Try to logon with the default ‘admin’ password ‘admin’ to configure your domain users. NOTE: ‘admin’ is not ‘Admin’ they are case sensitive.
If you have lost the licensing server admin password then you can reset the admin password in the licence server configuration file.

Find the ‘server.xml’ file in Citrix Licensing folder
Open and Administrator CMD prompt to edit it.
Find the entry that looks something like this:

;

Delete the text in the password section, in the above example change password=”(ERD-32)IUJ676h43wedftQ(lots-of-characters-encrypting-your-password–” to password=”Password”
Change passwordExpired to ‘true’
Restart the licensing services, ‘Citrix Licensing Server’
Log onto the licensing console using user name ‘admin’ and the ‘Password’
Change your password and you are done.

Load Evaluators

2016-04-30T04:15:00.001-05:00

Working with Load Evaluators

These load evaluators are included in Load Manager:

Default. Load Manager attaches the Default load evaluator to each server after you add your license to the server farm. It contains two rules: Server User Load, which reports a full load when 100 users log on to the attached server; and Load Throttling, which specifies the impact that logging on has on load and limits the number of concurrent connection attempts the server is expected to handle.
Advanced. This load evaluator contains the CPU Utilization, Memory Usage, Page Swaps, and Load Throttling rules.

You can create new load evaluators based on the rules available in Load Manager.

Important: Each server or published application can have only one load evaluator attached to it.

You can attach one load evaluator to a server and one load evaluator to each published application on the same server. For example, you can keep the Default load evaluator attached to your server and attach another load evaluator to each of your published applications on that server.

Viewing Load Evaluator

Depending on the version of XenApp you have installed:
- From the Start menu, open All Programs > Citrix > Administration Tools and choose XenApp Advanced Configuration.
- From the ICA toolbar, open the Presentation Server Console.
Select Load Evaluators in the left pane.

Right-clicking a load evaluator allows you to copy it, delete it, view its properies, or create a new load evaluator.

Important: You cannot delete the Citrix-provided Advanced or Default load evaluators

Enable XenApp Maintenance Mode

2016-04-30T04:10:00.002-05:00

Enable XenApp Maintenance Mode

Prior to version XenApp 6.5 the most common method was to use Custom Load Evaluator that will report a full load when assigned to a server. The main reasons to use Load Evaluator were:

Load Evaluator assigment is stored in data store, so Load Evaluator can be assigned to a server, even while server is offline.
Load Evaluator will reject new sessions, but it will allow user to reconect to disconnected session
Load Evaluator will affect only ICA sessions and RDP connection will still be allowed

In XenApp version 6.5 ability to directly assign Load Evaluator to specific servers was removed, instead Load Evaluator can be assigned to the Worker Group (Worker Groups are collections of XenApp servers, residing in the same farm, that are managed as a single unit). The ability to put a single server into maitenance mode is provided by logon mode control.
By default, logons are enabled for each server in a farm, allowing connections, reconnections, and session sharing. Before taking a server offline, such as for maintenance, use these options to reroute logons to other servers.

Allow logons and reconnections. Enable all logons, reconnections, and session sharing (default setting).
Prohibit logons and reconnections. Reroute all logons, reconnections, and session sharing to other servers.
Prohibit logons only. Reroute new connections and session sharing, but allowing users to reconnect to disconnected sessions. This state persists until you change it manually.
Prohibit logons until server restart. Reroute new connections and session sharing, as above, but after restarting the server, the setting automatically changes back to Allow logons and reconnections.

Ability to disable access to offline server
Logon mode for RDP is per-server configuration that is stored in registry. Configuration of logon mode is stored in registry in two different locations:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\TSServerDrainMode
0 = Allow all connections
1 = Allow reconnections, but prevent new logon until reboot
2 = Allow reconnections, but prevent new logon
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\WinStationsDisabled
0 = Enabled
1 = Disabled
When server is in drain mode, WinStationDisabled is always 0 (enabled).
Now the interesting part is that XenApp logon control is actually managed through data store and is updated using LHC synchronization notification. So when you change the logon mode in console, this change is actually not immediately done on the registry of the target machine. When XenApp server is offline and you change the logon mode, it will get notification from data store during boot and automatically apply the logon mode that you’ve configured in the console. This allows you to change logon mode even while server is offline.
Temporary drain mode (Prohibit logons until server restart) is however available only when server is online.
Logon Mode in PowerShell
Especially in larger and more dynamic environments, it’s very common to automate the whole maintenance process. If you want to automate assignment of logon modes, there are two commands that you can use:
To assign logon mode to server:
Set-XAServerLogOnMode -LogOnMode $LogonMode -ServerName $Server
Since logon mode is enumeration, you can use this universal method to get all allowed values:
[Enum]::GetValues(“Citrix.XenApp.Commands.LogOnMode”)
To save you some time, I’m also going to list all allowed values for $LogonMode:

AllowLogOns
ProhibitNewLogOnsUntilRestart
ProhibitNewLogOns
ProhibitLogOns

To get logon mode assigned to server, it’s one of the properties of the regular server object:
$(Get-XAServer -ServerName $Server).LogonMode
For xa 5, and xa 6, create custom load evaluator and assign it to individual servers. From xa 6.5, use the new prohibit logons feature and change the registry setting to enable RDP to admin users.

Session Linger

2016-04-30T04:09:00.002-05:00

A user session ends after user processes and visible windows end (for example, when a user exits from an application, the session ends). You can use session linger to provide a better user experience by eliminating the launch delay between applications.

To use session linger for named user sessions, configure the following Citrix User policy settings:

Linger Terminate Timer Interval specifies the number of minutes a session remains active after the last application terminates. If a new application starts during this interval, the user session returns to the active monitoring state. If no application starts during this interval, the session ends.If this policy setting is not used, session linger is disabled.
Linger Disconnect Timer Interval specifies the number of minutes to wait after lingering begins before disconnecting the session. If a new application starts during this interval, the user session returns to the active monitoring state. It is possible that other factors may cause a session to be disconnected before the Linger Disconnect Timer Interval expires.If this policy setting is not used, a lingering session will not disconnect.

Anonymous user sessions do not have a disconnected state; they are either active or terminated. Therefore, if the Linger Terminate Timer Interval and Linger Disconnect Timer Interval policy settings are used, the effective Linger Terminate Timer Interval setting is the same as the Linger Disconnect Timer Interval setting.
For a non-seamless named user session, the disconnected session remains in the disconnected state until the Linger Terminate Timer Interval expires.
Posted in Citrix eDocs
In XenApp 6.5, new solution comes in — Session Linger
Session Linger is a new feature in XenApp 6.5 that allows user ICA session to hold as active state for a period of time after the last published application close.
Let ‘s see how to configure it.
Session Linger is configured in XenApp user policy. The following is an example:

Linger Disconnected Timer interval — time to change the session to disconnected state after linger activated. (it is useless if its value is greater than Linger Terminate Timer Interval.)
Notes: XenApp will kill disconnected session according to ICA connection configuration
Linger Terminate Timer Interval — length of time that session lingering will activate. The ICA session will end after this time period.
When Session Linger function, the session state will appear as “Lingering” like the following screen

During “Lingering” state, the session is still active so that user can still launch another published application in this XenApp server in same session (remember “Session Sharing”?) without problem.
After “Session Disconnected Timer Interval” expires, you will the “Disconnected” state like the screen below

User can still reconnect this disconnected “Lingering” session.
How long do you need to set this Linger Terminate Timer ? It depends on users behavior in your environment. 15 min is a common value in customers.

Session Reliability and Keep-Alive

2016-04-30T04:07:00.001-05:00

Configuring Session Reliability
Session Reliability keeps sessions active and on the user’s screen when network connectivity is interrupted. Users continue to see the application they are using until network connectivity resumes.
This feature is especially useful for mobile users with wireless connections. Take, for example, a user with a wireless connection who enters a railroad tunnel and momentarily loses connectivity. Ordinarily, the session is disconnected and disappears from the user’s screen, and the user has to reconnect to the disconnected session.
With Session Reliability, the session remains active on the server. To indicate that connectivity is lost, the user’s display freezes and the cursor changes to a spinning hourglass until connectivity resumes on the other side of the tunnel. The user continues to access the display during the interruption and can resume interacting with the application when the network connection is restored. Session Reliability reconnects users without reauthentication prompts.
Users of Program Neighborhood can override the Session Reliability setting by selecting or clearing the Enable session reliability option in their application or connection settings. Users of the Citrix XenApp plugin and the Citrix XenApp Web Plugin cannot override the server setting.
By default, Session Reliability is enabled at the server farm level through the Access Management Console or the Delivery Services Console, depending on the version of XenApp you have installed. You can customize the settings for this feature from the server farm’s Properties page and modifying the Session Reliability settings as appropriate. You can edit the port on which XenApp listens for session reliability traffic and edit the amount of time Session Reliability keeps an interrupted session connected.
The Seconds to keep sessions active option has a default of 180 seconds, or three minutes. Though you can extend the amount of time Session Reliability keeps a session open, this feature is designed to be convenient to the user and it does not, therefore, prompt the user for reauthentication. If you extend the amount of time a session is kept open indiscriminately, chances increase that a user may get distracted and walk away from the client device, potentially leaving the session accessible to unauthorized users.
Note: You can use Session Reliability in conjunction with Secure Sockets Layer (SSL).
If you do not want users to be able to reconnect to interrupted sessions without having to reauthenticate, use the Auto Client Reconnect feature. You can configure Auto Client Reconnect to prompt users to reauthenticate when reconnecting to interrupted sessions.
If you use both Session Reliability and Auto Client Reconnect, the two features work in sequence. Session Reliability closes, or disconnects, the user session after the amount of time you specify in Seconds to keep sessions active. After that, the settings you configure for Auto Client Reconnect take effect, attempting to reconnect the user to the disconnected session.
Important: If the Session Reliability feature is enabled, the default port used for session communication changes from 1494 to 2598.
Configuring ICA Keep-Alive
Enabling the ICA Keep-Alive feature prevents broken connections from being disconnected. When enabled, if XenApp detects no activity (for example, no clock change, no mouse movement, no screen updates), this feature prevents Remote Desktop Services from disconnecting that session. XenApp sends keep-alive packets every few seconds to detect if the session is active. If the session is no longer active, XenApp marks the session as disconnected.
However, the ICA Keep-Alive feature does not work if you are using Session Reliability. Session Reliability has its own mechanisms to handle this issue. Only configure ICA Keep-Alive for connections that do not use Session Reliability.
ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group Policy.
Configure the following Citrix Computer policy settings:
ICA keep alive timeout. Specifies the interval (1-3600 seconds) used to send ICA keep-alive messages. Do not configure this option if you want your network monitoring software to close inactive connections in environments where broken connections are so infrequent that allowing users to reconnect to sessions is not a concern.
The 60 second default interval causes ICA Keep-Alive packets to be sent to client devices every 60 seconds. If a client device does not respond in 60 seconds, the status of the ICA sessions changes to disconnected.
ICA keep alives. Sends or prevents sending ICA keep-alive messages periodically.

Best Practice – Assigning Apps to Users

2016-04-30T04:06:00.002-05:00

Assigning published applications to users may be a very simple task, but if not managed well, it can end up creating more problems. I have seen customers assigning individual user accounts to the published apps in the Citrix admin console and this can get very problematic as there are danger of assignment inconsistency. Usually, we use Active Directory groups to manage the assignments. In Microsoft world, there are 3 types of AD groups – domain local, global and universal group. I am frequently asked by customers what is the best practice in managing the applications assignment, and I would refer them toMicrosoft’s best practice (scroll to the last section of the page).
According to Microsoft’s recommendation, use Domain local group to manage access to resources, i.e. published apps. Next, use global groups to manage users in a particular domain, then grant the users access to the published apps by making the global groups a member of the local group. Finally there is universal group which can consolidate global groups from different domains, but so far I have not come across customers using universal groups yet.
To give a XenApp specific scenario for example, let’s say there are two different domains, Domain A and Domain B, and the XenApp servers are in Domain A. To assign, let’s say HR users from both Domains to the published apps, create global groups “G_HR” for each Domains and assigned the HR users to the respective Domain global group. In the XenApp servers’ domain (Domain A), create a local group for each applications and make the “DomainA\G_HR” and “DomainB\G_HR” member of these local groups if they need to use the applications.

Even if there is only 1 Domain, I would recommend to use this approach. If there is a need to migrate your users or XA servers to a different Domain in the future, it may help to make the transition smoother.

Citrix Products Evolution

2016-04-30T04:05:00.001-05:00

From the time citrix started below are the editions and name changes with year numbers. Citrix was founded in Richardson, Texas, in 1989 by former IBM developer Ed Iacobucci .

Citrix Version Name	Year
MultiUser 1.0	1991
MultiUser 2.0	1992
WinView	1993
WinFrame	1995
MetaFrame 1.8 TSE(Terminal Services Edition)	1998
MetaFrame 1.8 and MetaFrame 1.8 Feature Release 1 and Metaframe sof solaris, IBM AIX, and HP UX	2000
MetaFrame XP TSE and Metaframe XP TSE FR1	2001
MetaFrame XP FR2	2002
MetaFrame XP FR3	2003
MetaFrame Presentation Server 3.0	2004
Citrix Presentation Server 4.0	2005
Citrix Presentation Server 4.5 and 4.5 FP1	2007
Citrix XenApp 5.0	2008
XenApp 5.0 FP1 and FP2	2009
Citrix XenApp 6.0	2010
Citrix XenApp 6.5	2011
Citrix XenApp 6.5 FP1	2012
Citrix XenApp 6.5 FP2	2013
XenDesktop 7	2013

Till winframe product, citrix used microsoft source kernel code and developed those editions. From MetaFrame1.8 TSE, citrix didnt use MS code. It started as a seperate product which can be installed on top of microsoft OS.
XenDesktop Evolution:
Below are the names and features given in different versions along with years.

XenDesktop Name	Year
XenDesktop 2.0 and Hyperv,scvmm support	2008
XenDesktop 3.0 and 4.0	2009
XenDesktop 5.0 .net architecture and MCS	2010
XenDesktop 5.5 better user exp and better monitoring	2011
XenDesktop 5.6 with personal vdisk	2012
XenDesktop 7.0 and 7.1	2013

License version numbers for different citrix products

2016-04-30T04:03:00.001-05:00

If you are unsure if your license server version is current, you can verify it by comparing your version with the number on the Downloads site.

On a license server with the License Administration Console:

Start the License Administration Console from the programs menu: Citrix > Management Consoles > License Administration Console.
Click Administration and select the System Information tab. See the release version in the information list.

On a license server without the License Administration Console:

Open the Registry Editor (Start > Run > regedit).
Note: Use Registry Editor to view the license server information only. Editing the Registry can cause serious problems that may require you to reinstall your operating system.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\LicenseServer\Install.
The version number appears in the Version key in the format: 11.5.0.0 build 9014.

On servers running Windows 2008 Server 64-bit the registry key is

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\LicenseServer\Install

Citrix License Server on Windows

Product Release	License Server	Version in Registry	Version on Download Page	Documentation
XenApp/XenDesktop 7.x	Citrix License Server	11.12.1	11.12.1	Get started
XenApp 6.5	Citrix License Server	11.10 build 12012	11.10 build 12012	Getting Started with Citrix Licensing
XenDesktop 5.6	Citrix License Server	11.10 build 12012	11.10 build 12012	Getting Started with Citrix Licensing
XenDesktop 5 Service Pack 1	Citrix License Server	11.9 build 11007	11.9 build 11007 (no longer available)	Getting Started with Citrix Licensing
Products released after 03/23/10	Citrix License Server	11.6.1 build 10007	11.6.1 build 10007 (no longer available)	Getting Started with Citrix Licensing
Products released 03/23/09 to 03/22/10	Citrix License Server	11.6.1 build 9019/9020	11.6.1 build 9020 (no longer available)	Getting Started with Citrix Licensing
All editions	Citrix License Server	11.6.1 build 9019/9020	11.6.1 build 9020 (no longer available)	Getting Started with Citrix Licensing
Products 04/14/08 to 03/23/09	Citrix License Server	4.6 or	11.5 (no longer available)	Getting Started with Citrix Licensing
All editions	Citrix License Server	11.5.x.x build xxxx	11.5 (no longer available)	Getting Started with Citrix Licensing
Presentation Server 4.5 Advanced, Enterprise, and Platinum editions	Citrix License Server	4.5	11.3 (no longer available)	Getting Started with Citrix Licensing Guide (v11.3)
Access Suite Presentation Server 4.0	Access Suite License Server 4.0	2	9.2 (no longer available)	Citrix Access Suite Licensing Guide

Citrix License Server VPX

Product Release	License Server	Version in XenServer	Version on Download Page	Documentation
Citrix License Server Virtual Appliance	Citrix License Server VPX 11.12 .1	11.12.1 build 14005	11.12.1 build 14005	Get started

Citrix License Server on UNIX

Product Release	License Server	Version in Registry	Version on Download Page	Documentation
Citrix License Server for Citrix XenApp 4.0, with Feature Pack 1, for UNIX	Citrix License Server	11.5	11.5 (no longer available)	Getting Started with Citrix Licensing
Citrix Presentation Server for UNIX 4.0	Citrix License Server for Presentation Server for UNIX 4.0	9.2	9.2 (no longer available)	Citrix Access Suite Licensing Guide

License Management Console tasks

License Server 11.6.1 began March 24, 2010 to include a new console, the License Administration Console. Previous versions of License Server 11.6.1 used the License Management Console. If you are using a prior version of License Server 11.6.1 with the License Management Console, see Citrix Licensing 11.5-11.6 for information about License Management Console tasks.

Citrix Ports and Commands

2016-04-30T03:57:00.002-05:00

Citrix Most used port list:

License Manager Daemon(lmgrd.exe)	27000	Handles initial point of contact for license request.
Citrix Vendor Daemon(Citrix.exe)	7279	Check-in/check-out of Citrix licenses
License Management Console	8082	Web-based administration console
Citrix Receiver	80/443	Communication with Merchandising Server
ICA	1494	Access to applications and virtual desktops
Session Reliability	2598	Access to applications and virtual desktops
IMA	2512	Communication between Xenapp Servers.
Management Console	2513	Citrix Management Consoles
Application / Desktop Request	80/8080/443	XML Service
STA	80/8080/443	Secure Ticketing Authority (embedded into XML Service)
RDP	3389	To access the windows desktop remotely
SQL Server Port	1433	Used for Data Store.
Edgesight Server	9035	Communications to Edgesight Server

XenDesktop and XenApp use port 8008 for Receiver for HTML5 connections.
By default the Citrix XML service listens on TCP port: 80. Although this is the default port, Citrix recommends using port 8080.We can change this port by ctxxmlss.exe command.
Citrix IMP Commands(Not all)

aierun Run isolation environment. Primarily for use in scripting environments.
Aiesetup Install or uninstall an application from an isolation environment.
altaddr Specify server alternate IP address.(Use altaddr to query and set the alternate (external) IP address for a server running Citrix XenApp. The alternate address is returned to clients that request it and is used to access a server that is behind a firewall.)
app Run application execution shell.(App is a script interpreter for secure application execution. Use App to read execution scripts that copy standardized .ini type files to user directories before starting an application, or to perform application-related cleanup after an application terminates.)
apputil Add servers to Configured Servers list for published applications.
auditlog Generate server logon/logoff reports.
chfarm Change the server farm membership of the server.
CTXKEYTOOL Use ctxkeytool to enable and disable the IMA encryption feature and generate, load, replace, enable, disable, or back up farm key files.
dscheck Validate the integrity of the server farm data store.
dsmaint Configure the server farm’s data store.
enablelb Enable load balancing for servers that fail health monitoring tests.
acrcfg – Configure Auto Client Reconnect settings
auditlog – allows you to get an audit for the user,time, failed and success logons in detail.
change – allows you to change logon or change port or change user.
ctxxmlss – used to configure citrix xml service port number(Default is 80).
icaport – change value of tcp/ip port for ica terminal sessions.(def is 1494. if u want to change it, use icaport cmd)
imaport – change ima port configuration utility
query – used to query farm, process,server, session,termserver and user.
qfarm /load – displays load on server
qfarm /app – display published applications currently being run
qfarm /online – displays online servers
qfarm /offline – displays server that are offline or hung, IMA service not running
qwinsta- Display information about Remote Desktop Sessions. Default is current server. Displays users for current(or any given) server.
twconfig – configure ica settings for graphics performance.

dsmaint verifylhc [/autorepair] run this command atleast an year to verify LHC. All the citrix ports and their usage is given at link: Citrix Ports and Usage and Xenapp 6 Commands

XA Troubleshooting

2016-04-30T03:54:00.001-05:00

When there is a dependency for an application to start another exe before it is started, Created script in startup folder so that the supporting exe will be started up and users manually launch their required app later
We use XenDesktop 7.5 with UPM 5.1, so the same user profile is used by XA. User’s default browser is Google Chrome. When he launch Outlook 2013 installed on server from Storefront and try to open URL from letter, an error “Application not found” is appears.Google Chrome is not installed on XA server. Is it possible to redirect URL opening to IE? If not, need I only install Google Chrome to server to open URLs from installed apps in it, if this browser is default in user profile? ANS: create script to check if chrome is installed. if yes, exit. if no, set ie as default browser.
getting error while publishing app. change icon of that app and publish to diff folder.
when you have multiple policies to be implemented, best practise is to use single GPO for all of them rather than creating multiple policies for all.
default unfiltered policy must be at the bottom
when there are 50 servers, advanced load evaluator is set for all the servers in unfiltered computer policy.but 2 servers still show default only. Gpudate, reboot, remove servers from farm and rejoin, all didnt work. ANS: There are two files responsible for enumerating and applying group policy changes in XenApp. They are both .gpf files here: C:\ProgramData\Citrix\Group Policy Delete those two files and reboot the system.
when you have multiple reboot policies for xa servers, you can set one reboot policy on one day and create scheduled task do it next time. (This is a workaround, not exact solution). IMA takes only one reboot policy at a time. you cant create multiple reboot policies.
if you have permissions to create ad policies, create AD policies rather than citrix policies.
XenApp 6.x Session Limit policies are controlled through the Remote Desktop Services policy. The settings are enabled in the MMC or gpedit.msc: User Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits
If the citrix policy is visible on some servers but not others then it’s because software is missing on the other servers. If the policy is missing on all servers then it’s probably datastore corruption and the database needs to be restored.
gives more info about sessions: Citrix Management Session tools.
out of 100 servers, only for one server, Load was going to a load of 20000 right away. Licensing was set in policy and was working for all other servers.Exporting HKLM\Software\Policies\Citrix and importing it on the broken machine and after restarting IMA, everything was working fine.For some reason, this one machine wasn’t getting all of the Citrix policies. It looks like it was getting the licensing information, but it wasn’t getting the version information (enterprise, platinum).
We had issues on one of the xenapp server. For two of our users when connecting to one particular xenapp server, gives errors and application doesnt launch. To isolate the issue, we have disabled logons for all the servers one by one and we asked user to login to the application everytime. For all the servers, application opened successfully but for one server, it gave errors. When we checked the server, user’s profile is getting corrupted on that server. In registry, we have identified that for the user’s profile .bak files are created. using delprof2 tool, we have removed their profiles completely and this solved the issue.
Make sure your IMA service is set to Network Service. It should not be like logon as local service, or anything else. In particular you have any issues, only then change it to the id who has admin rights on the database. If not, IMA should be set to Network Service only.
When opening xenapp console is slow, Untick the internet explorer preferences for ‘check for publishers certification revocation’, untick ‘check for server certificate revocation*’ and ‘check for signatures on downloaded programs’. If your xenapp applications are loading slowly,
* My recommendation will be to check the system logs to make sure you don’t have system issues.
* Make sure you have all of the recommended rollupack and hotfixed and MS updates.
* Make sure you have all of the anti-virus exclusions in place.
* Use DSCheck to determent potential issues. http://support.citrix.com/article/CTX133925.

XenApp application dual monitor issue

2016-04-30T03:52:00.002-05:00

XenApp application dual monitor issue

Problem: When user double clicks the ica file, Application launches in the middle of the dual monitors. Half on one side of laptop and half on the other side of monitor.
Solution: Open the ica file with text editor and goto the value TWIMode=On. Now change this value to off, like TWIMode=Off. This will resolve the issue.

Problem: Sometimes when we try to open license management console(Localhost:portnumber) doesnt open anything. When we check in services.msc, citrix licensing service is set to automatic but it is stopped. When we try to start it, we get an error message saying, “Could not start the CitrixLicensing service on local computer. Error 1067: The process terminated unexpectedly.”
A workaround is to move or delete the following two files:
c:\Program Files (x86)\citrix\licensing\ls\conf\activation_state.xml
c:\Program Files (x86)\citrix\licensing\ls\conf\concurrent_state.xml
Now restart citrix licensing service.

Everyday users need to set their env variables in xenapp apps

2016-04-30T03:51:00.001-05:00

Issue: Users need to set their env variables for a citrix app every day.
Brief Overview:
For an application(xenapp published app), users have to set their enviornment variables for the very first time they login. From next time, these variables are automatically set from their profiles which are on the xenapp servers. A script has been set to reboot these servers every night by some other team person and from next morning, users have to set their variables again everyday.
Solution: We have disabled server reboot for some time period and that solved our problem.