XenApp Terminology!

XenApp Terminology!

Farms

Collection of XenApp servers combined to become a farm which shares a single databaseknown as data store. We can compare a citrix farm to Active Directory domain. It is a logical collection of XenApp servers.

Zone

Zone is a collection of XenApp servers that communicate with each other using common data collector. In each zone there is a XenApp server which is designated as data collector. Data collectors act as communication gateways. Zone can be compared to what site is in Active Directory terminology.

Zones are basically used to control the aggregation and replication of data in the farm. Usually zones are created by taking into consideration network topology where major geographical locations are created as one zone.

Best practice related to zone is to create zone for larger geographical locations if in case all small geographical locations are interconnected with adequate WAN links.

Data Collectors

Data collector is basically a XenApp server with additional functionality of Data Collector. In a farm with 100 XenApp servers there will be one server which will be designated as Data Collector.

All the dynamic information about the farm is stored by Data collectors. There is one server which is designated as Zone Data Collector (ZDC) in a zone. If a particular ZDC becomes unavailable election takes place to elect new data collector. Data collector relays all the information it has to all other citrix servers. It receives incremental updates from other servers. A zone data collector is a server that manages dynamic information about the servers in the zone.

Since each zone has ZDC, ZDCs in each zone talk to ZDCs of other zones and no other XenApp server communicate with each other in different or same zones.

Primary responsibilities of ZDC are:

1.      Server loads.

2.    Session status, users connected

3.    Published applications.

4.    License usage

5.     Load balancing of user sessions.

6.    Distributing updates to all servers in the zone.

Qfarm command can be used to know which server is holding the role of ZDC in a farm.

Data Stores

All the persistent / static information is stored in data stores. In earlier versions of XenApp , IBM DB2,  Data stores can be SQL or Oracle databases which store this information. Each farm has single data store and all the servers in the farm communicate with the datastore. If the datastore goes down administrators will not be able to make any changes to the citrix farm.

In earlier versions of XenApp , IBM DB2 database was supported as datastore but now XenApp 6 supports only SQL Server and Oracle as database.

Information stored in data store is as follows:

1.      Farm/server configuration such a published applications and access information.

2.    Total licenses

3.    Load balancing information

4.    Administrator accounts.

5.     Printer configuration.

DSview command can be used to view the contents of data store.

Local Host Cache (LHC)

LHC stores subset of the information stored in the datastore. On each server LHC is aMicrosoft Access database (MDB file) which holds information related to that particular server and no information is stored about other servers. LHC main purpose is to allow citrix server to run in case of datastore unavailability. Also it improves performance by caching information which is used by ICA clients for enumeration and application resolution. Actual file name of LHC is imalhc.mdb.

The below information is stored 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)

When the first XenApp member servers starts , LHC pulls above information from datastore. Once this is populated, IMA service is responsible for keeping LHC synchronised.

DSmaint recreatelhc command can be used to recreate LHC. In this case LHC pulls updated information from Data store.

IMA

IMA stands for Independent Management Architecture. IMA is not a protocol but main component of XenApp server. IMA provides a framework for server to server communication. IMA is installed on every XenApp server by default. It is an architecture which controls all XenApp servers.

IMA works on port 2512. Server to server communication happens on port 2512 and server to console communication happens over port 2513.

IMA Service

This service is a core service on Citrix servers.  When XenApp is installed on windows server this service gets installed apart from other citrix services. If this service is stopped then citrix server will not be able to communicate with rest of the citrix servers forcing server not to accept any user connections. This service is heart of the citrix servers.

This service is responsible for following activities:

1.      Tracking users, sessions, applications, licenses and server load

2.    Communication with other citrix servers.

3.    Tracks which users have permissions to access which applications

Citrix XML Service

This service is responsible for all communication to the IMA service. Like IMA service this service also runs on all citrix servers. All servers in the farm must have the same XML port number. The Citrix XML Service was introduced with MetaFrame 1.8 Service Pack 2 and a Feature Release 1 license needed to be installed. MetaFrame XP and later incorporates the Citrix XML Service as a standard feature.

XML service uses port 8080 which is shared with IIS which is the default port and which can be changed using command – CTXXMLSS.EXE. Refer CTX article - CTX104063 for knowing more about command line options.

This service gets its information from the servers IMA service and sends information to whomever has requested it. XML service generates XML files which are generated dynamically and contain information which is requested by clients.

ICA protocol

ICA stands for Independent Computing Architecture.

ICA is a very thin protocol which is created by Citrix for client to server communication. ICA protocol is a Presentation layer protocol on the OSI model.

It is both a protocol and file type. When a citrix session is established between client and server, this protocol is responsible for sending keystrokes and mouse movements from client to server and sending screen updates from server to client. When a particular application is published on Citrix server actual processing happens on citrix server and all the screen images are transmitted to client machine using ICA protocol. This protocol is a very high level protocol which works on top of all other protocols such a TCP/IP, IPX/SPX and NetBIOs.

Port number of ICA protocol is 1494.

If we open up a client machine and check for file of extension .ica we will find some files with .ica extension which are basically ICA files which can be opened using text editor such as notepad which will show the citrix server addresses and other ICA parameters in order to connect to citrix farm. This is how ICA client machine connects to citrix server.

HDX

HDX is a new concept and stands for High Definition Experience. HDX is nor a protocol or feature. HDX basically contains set of citrix technologies. In order to improve user experience Citrix has created HDX.

Technologies which are under HDX are:

HDX MediaStream

HDX RealTime

HDX Broadcast

HDX SmartAccess

HDX Plug-n-Play

HDX RichGraphics with RemoteFX

HDX WAN Optimization

HDX Adaptive Orchestration

License Server

License server takes care of all licensing of citrix products.

Web Interface

Web Interface is basically a web server. User connects to web interface server while accessing applications.

Application Publishing

 When we deploy a particular application on citrix we call it a published application. We install application on citrix server and give access to users so that users can execute the same application from their client devices. Actual processing / execution of application happen on citrix server and only the screen updates are traversed to client machine.

Advantages of application publishing are

1.      Remote access to applications – Application can be accessed from multiple devices such as PCs, laptops, tablets, Smart Phones and other devices outside of corporate networks.

2.    Maintenance of applications – Since application is installed on only citrix server, any changes to application is easy.  Updates or version changes can be done on server without bothering users.

Program Neighborhood / Receiver

In older days citrix receiver was known as Program Neighborhood which has been discontinued by Citrix and no more available. Please refer CTX article - CTX12172 for more details.

Just to quote what Program Neighborhood is from citrix site itself :

Program Neighborhood is the legacy user interface included in the Citrix online plug-in (formerly Program Neighborhood Agent). With this interface, users can browse for groups of published resources (referred to as application sets) or create custom connections to individually published resources or to computers running Citrix XenApp.

Instead of Program Neighborhood we have now ICA clients known as Receivers (Also referred as Citrix online plug-in). Latest Online plug-ins is known as Receiver.

Program Neighborhood Agent

Citrix online plug-in

Citrix Receiver

There are Citrix receivers which are available now for different operating systems and devices:

Operating Systems	Devices
Microsoft Windows	Apple iPhone
Mac OS X	Apple iPad
Linux	Android – All Android based devices such as Samsung Galaxy tablets/Phones etc, Sony tablets.
Chromebook	Blackberry Phones
	Blackberry PlayBook – Tablet
	Windows Mobile – Any phone which is using Windows Mobile such Nokia Lumia phones

Worker Group

In earlier XenApp versions only way to group similar servers which were hosting same application is to create folders in console. This functionality has been taken by a new concept called worker groups in XenApp 6 onwards. Worker group is a collection of XenApp servers which are hosting similar applications to be managed as one. For example if there are 5 servers hosting Microsoft Office applications then all these 5 servers can be combined to become a worker group. Worker group is closely associated with “Application silo” concept. All servers in a worker group share same citrix settings and same published applications. Worker groups can only consist of XenApp servers in the same farm. Worker groups allow collecting servers into groups for publishing applications, load balancing and policy filtering.

Though zones and server folders still exist in XenApp 6, worker group has been added as additional concept for load balancing policies. In earlier versions of XenApp , zones were created to control load balancing via the Zone Preference and Failover feature but this has been replaced by citrix policies in XenApp 6. Worker groups should be created to define load balancing policies and zones should be created for data replication between data collectors.

Folders can be created to organize severs in the management console which basically creates a hierarchy of servers. Also they can be used to control permissions for delegated administration.

If we navigate to the properties of each published application in XenApp farm it has got the server list which tells us on which server’s application has been published. So in case when you have set of applications which are published on a set of servers and in case if you wanted to add/remove servers from these applications then only way to achieve this was to manually edit through the properties of each of these published applications.  With XenApp 6 we can create an AD container called “worker group” and assign settings such as computer policies, load balancing polices and applications published on those worker group. So once we create  a worker group and add servers into worker group all the settings gets applied to all servers in that worker group. We can add / remove servers from worker group and there is no need to go to each application properties page. In the server list page instead of adding list of servers we will add worker groups.

Benefits of worker groups.

Ads not by this site

	Worker Group	Similar functionality
Location	A single server can belong to multiple worker groups. Servers can be grouped into worker groups both by geographical location or by the applications they are hosting	Single server cannot be part of two folders simultaneously.
Load balancing	Worker groups can be used to control load balancing within a single site. A worker group can contain a single server.	Zones can be used for load balancing.
Dynamic	Worker groups are more dynamic as when AD containers are added to a worker group and if there are any changes to AD container then they are automatically reflected in the server’s worker group memberships.	This functionality is not present in earlier versions of XenApp.

Worker Group Preference

Worker group preference is a new feature in load balancing policies. This feature is used to load balance specific set of users to specific set of servers. We can use this feature in following scenarios:

§  Allow user to connect to application from the nearest site in order to reduce WAN traffic and enhance overall user experience.

§  Allow users to connect to backup site in case of disaster.

§  Dedicating servers for specific group of servers.

Session Reliability and ICA keep Alive

Session reliability is a feature which keeps the session reliable. Common example which is given is when a user who is travelling , who has connected to application over wireless connection and when he passes through a tunnel wireless connection drops then session reliability feature kicks in and keeps the session active so that user does not get disconnected from session. When session reliability is enabled users continue to see the application they are using until network connectivity resumes. When user loses wireless connectivity user’s display freezes and cursor changes to hourglass until connectivity resumes. With session reliability user’s session remains active on the server and it does not get disconnected.

Session reliability works on port 2598.

Port used by ICA session is 1494 but if Session Reliability feature is enabled, the default port used for session communication changes from 1494 to 2598.

If Session reliability is enabled then ICA keep- alive feature does not work.

ICA Keep –alive feature keeps broken connections from being disconnected. So that means that both session reliability and keep-alive tries to keep the sessions active. When keep-alive is enabled, even if there is no mouse movement, no screen updates than that session does not get disconnected. ICA Keep-alive feature has to be enabled only when session reliability is not used.

By design, Session Reliability overrides the ICA KeepAlive setting & this applies to PS 4.0, PS 4.5 as well as XenApp 5.0 product versions. Refer CTX107659.

Common Ports

Component	Type	Port Number	Details
IMA	TCP	2512	Independent Management Architecture (IMA)
Management Console	TCP	2513	Citrix Management Consoles  ( console to XenApp server communication)
ICA / HDX	TCP	1494	Access to applications and virtual desktops
ICA with session reliability	TCP	2598	Access to applications and virtual desktops
Application / Desktop Request	TCP	80/8080/443	XML Service
Secure Sockets Layer	TCP	443	SSL
License Manager Daemon	TCP	27000	Handles initial point of contact for license requests (Lmadmin.exe)
License Management console	TCP	8082	Web-based administration console (Lmadmin.exe)
Citrix Vendor Daemon	TCP	7279	Check-in/check-out of Citrix licenses (Citrix.exe)
RDP	TCP	3389	Remote Desktop Protocol
Database	TCP	1433	Microsoft SQL Server
LDAP	TCP/UDP	389	LDAP connection
LDAP	TCP/UDP	636	LDAP SSL connection
Active Directory	TCP	3268	LDAP connection to Global Catalog
Active Directory	TCP	3269	LDAP SSL connection to Global Catalog