dropdown menu


Citrix XenApp (formerly Citrix WinFrame Server, Citrix MetaFrame Server and Citrix Presentation Server) can host applications on central servers and allow users to interact with them remotely or stream and deliver them to user devices for local execution.

(I will use mostly Metaframe in this article, but Xenapp may appear as well. Both are the same thing.)

You install MetaFrame on a UNIX machine that will be used as a server. MetaFrame allows multiple users to log on and run applications in separate sessions on the same server. The applications (Web browser, Java apps., etc.) must also be available on the server.

You install the ICA (Independent Computing Architecture) Client software on the client device, so users can connect to the MetaFrame server from a client device, such as a Windows PC.

MetaFrame uses the ICA protocol to send information (keystrokes, mouse clicks, screen updates) between the client device and the server. The application processing remains on the server, but to the user of the client device, it appears as if the software is running locally on the client.


Short for 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 the technologies used by Citrix servers.

The ICA protocol is responsible for sending input and output between the client machines and the actual server, which is running the application. Conceptually, the protocol is similar to X-Window, which serves the same purpose for UNIX systems.

The result is that network users on non-Windows machines (e.g., UNIX machines) can run Windows applications.

ports needed:
1494 tcp?    clients first request goes to this port on the server
1604 udp     ICA browser service uses this
80           HTTP port for XML



  Citrix.MetaFrame.anon  COMMITTED  MetaFrame for Unix anonymous
  Citrix.MetaFrame.boot  COMMITTED  MetaFrame for Unix
  Citrix.MetaFrame.man  COMMITTED  MetaFrame for Unix manual
  Citrix.MetaFrame.rte  COMMITTED  MetaFrame for Unix

.anon: Creates 15 anonymous user accounts. You cannot install this fileset on its own, Citrix.MetaFrame.rte fileset must also be installed.

.boot: During the installation of the .boot fileset, an entry is made in the /etc/inittab file that starts up ctxmfd and the Metaframe server, when booting up. If you choose this fileset, the daemon ctxmfd is installed in /usr/lpp/CTXSmf/sbin, and starts up automatically. You cannot install this fileset on its own, Citrix.MetaFrame.rtefileset must also be installed.

.rte: Choose to install the MetaFrame runtime environment (the programs and the configuration database).

.man: Choose to install the MetaFrame manual pages.



/usr/lpp/CTXSmf/sbin/ctxmfd:      MetaFrame Daemon: stopsrc/startsrc -s ctxmfd, controls all ctx processes, integrated into SRC)
                                  (child proc. of srcmstr, resp. for automatic MetaFrame activation/deact. during system start-up/shutdown)
/usr/lpp/CTXSmf/slib/ctxibrowser: ICA browser: ctxsrv start/stop browser   
/usr/lpp/CTXSmf/slib/ctxxmld:     Management Service and XML service: ctxsrv stop/start msd, it controls ctxxmldssup as well
/usr/lpp/CTXSmf/slib/ctxcdmd:     Client Drive Mapping: ctxsrv stop/start cdm   
/usr/lpp/CTXSmf/slib/ctxlsd:      License Service Daemon: ctxsrv stop/start lsd
ctxutmpd:                         not sure about it, probably manages user infos ctxsrv start/stop server
/usr/lpp/CTXSmf/slib/ctxfm:       Connection Server: ctxsrv start/stop server, client connections ctxfm (Frame Manager) calls ctxlogin binary.
                                  (this is the parent process of all citrix sessions)


ICA browser (ctxibrowser)

The ICA browser maintains data about published applications and servers. The ICA browser consists of a master browser, member browsers, and
plugins. The ICA browser uses directed packets to communicate with other ICA Browser Services running on servers.

Every server runs the ICA Browser Service. One server is elected the master browser; all other servers are member browsers. The master browser is a browser acting as a central information store. The master browser keeps track of the following information:
- The available servers
- The available published applications
- Performance and load information for servers

The refresh period controls how often the browser updates the master browser. The browser updates the master browser after the specified amount of time elapses. A short refresh period makes the master browser data more accurate, but increases CPU and network load.

If you stop the browser on a server, users cannot connect to published applications on this server, although they will still be able to connect to the server
desktop. If you stop the browser process on the master browser, a master browser election will occur among the other servers on the network.

The master browser for each network is chosen by a master browser election. If the current master browser on a network is not responding, a new master browser election is held automatically. Starting a server causes an election, and the master browser may change. The master browser takes some time to acquire information about applications available on the farm.

You can display and change the browser settings on a server using the ctxbrcfg tool.

ctxqserver -master             <--locating the master browser
ctxsrv {stop|start} browser    <--starting and stopping the browser:



A server farm is a group of servers running MetaFrame Presentation Server that is managed as a single entity.

Using a server farm allows you to:
- Deploy published applications and resources to all servers in the farm quickly and easily.
- You can administer the farm from any server in the farm

Ports used for communication between servers:

2897 TCP     administration commands and management information updates and queries
1604 UDP    interserver comm. between ICA browsers (packets directed to master browser with info about load, available appl., disconnected sessions)

When you create a new server farm, the server on which you create the farm becomes the Management Service Master. The master has authorative control of the farm and it holds the master copy of the farm’s data store.

Data Store

The data store is a human-readable text file that stores persistent data for the farm, such as configuration information about the servers and published applications in the farm. The Management Service Master holds the master file, while other servers in the farm each hold a copy of the data store. When a server joins the farm, the data store is updated to reflect the addition of the new server, and the new server is given a copy of the farm’s data store.

There are 2 services related to server farms: Management Service and XML Service

Management Service

The Management Service is a daemon (msd) that runs on each server in the farm that communicates server farm information, such as details about the published applications in the farm. When you make a configuration change to the server farm (for example, you publish a new application in the farm), the Management Service Master communicates this change to the other servers in the farm using the Management Service. The Management Service Master is the server on which you first create the farm.

XML Service

The Citrix XML Service runs as a daemon on all servers in a server farm. The Citrix XML Service is included automatically when you install XenApp for UNIX, and the XML process starts automatically. If you create a server farm, the XML Service runs on each server in the farm. Configuration information required by the XML Service is stored in ctxxmld.cfg

The key features and benefits of using the XML Service:
Web-based application deployment: Using the XML Service, you can deploy applications published on XenApp servers to your users through the Web. The XML Service communicates information about the UNIX applications published in a server farm to the Citrix Web Interface. The Web Interface provides users with an HTML-based presentation of the server farm. Users can access their published applications using a standard Web browser

HTTP browsing: You can provide your users with HTTP (HyperText Transport Protocol) browsing. The plugin uses HTTP to communicate with the Citrix XML Service to fulfill browser requests. HTTP browsing uses the standard HTTP port (80)

SSL Relay support: The XML Service provides SSL Relay support. You can use SSL Relay to secure communications in a Web Interface deployment between the Web
server and the XenApp server

ctxsrv start msd                  <--start XML and Management Service
ctxsrv stop msd                   <--stop XML and Management Service
ctxnfusesrv -l                    <--shows current port config for XML
ctxnfusesrv -port <portnumber>    <--configures XML service port


License Service Daemon (lsd) (ctxlsd)

You use a license server and a user interface for managing licenses, known as the License Management Console. Install the license server and the License Management Console on a Windows machine. License files then are downloaded from the Citrix Web site and stored on the license server.

license configuration:

# ctxlsdcfg
License Config>  server server1.domain.com
License Config>  port 27000
License Config>  exit
Do you wish to save your changes? y


Client Drive Mapping

The client drive mapping feature enables users to access their local drives from within an ICA session. When a user makes an ICA connection to a XenApp server, the user’s local drives are mounted automatically, such as floppy disk drives, network drives, CD-ROM drives, and hard disk drives.

These drives are available for the duration of the session. When a session is disconnected, all the mapped drives belonging to the session are released immediately.


Published Applications:

You can publish any application that can run on AIX. To a client user, a published application is an application that appears similar to an
application running locally on the client device.

publishing an application:
# ctxappcfg
App Config>  publish
Type ? for help at any prompt.
Name:  xterm
Command line:  /usr/bin/X11/xterm
(after finsihing it, type "exit" to leave this tool)

displaying a published application:
# ctxappcfg
App Config>  list                            <--lists published applications
Name:  "firefox"

Name:  "xterm"

App Config>  select xterm                    <--shows details of the selected publ. appl.
Name:  xterm
Command line:  /usr/bin/X11/xterm
Working directory:  User's home directory.

xterm>  drop                                  <--deselects the current application (gives back the "App Config" prompt
                                              (the command "delete" will remove the publ. appl. from all servers)
App Config>  select firefox                   <--then you can select another application
Name:  firefox
Command line:  /usr/bin/firefox
Working directory:  User's home directory.


Load Balancing:

Load balancing determines which servers are least busy and can best run an application. The master browser keeps track of the load levels and the number of users connected on each server. When a published application or desktop is launched from a client, the master browser selects which server will run the application or desktop session, based on server load.

By default, MetaFrame Presentation Server automatically monitors the number of users connected to each server and sends new connections to the server that is least busy. If you find that some servers become busier than others with evenly distributed connections, you can tune load balancing so that this is taken into account: ctxcfg -k <loadfactor>. (loadfactor can be any number between 1 and 1000)

By default, each server has a load factor of 100. However, if you have a server that is more powerful (by 150%) relative to the other servers in the group, you can increase the load factor to ensure that this server receives more connections:

1. ctxsrv stop browser             <--stop bowser
2. ctxcfg -k loadfactor=150        <--tune loadfactor (displaying the loadfactor: ctxcfg -g | grep loadfactor)
3. ctxsrv start browser            <--start browser



Citrix Logon Process :

1. The ICA listener will wait for a client connection. (listen state)
2. When it receives one, the Frame Manager ctxfm will invoke the ctxlogin binary.
3. The ctxlogin binary does two things; it logs the user in and it communicates with the Citrix X server (ctxXtw).
4. Once the user authentication is complete, the user shell scripts (i.e. .login, .profile or .cshrc) are invoked.
5. after this, ctxlogin process will launch the script: /opt/CTXSmf/lib/ctxsession.sh.
   (This sets the $SESSION_ID environment variable that is unique to each ICA session connected to the server.)
6. If ~/.ctx.session.sh script exists, then it will be invoked
7. Finally the published application is launched (i.e. Star Office or Netscape).


/usr/lpp/CTXSmf/data/C/logo.xpm    this displays the login screen (you can change it to another one, just renaming is needed)

ctxsrv start all                   start MetaFrame Presentation server
ctxsrv start <component>           starts a component (browser, sslrelay, cdm, lsd, msd, server)
ctxsrv stop <component>            stops a component (browser, sslrelay, cdm, lsd, msd, server)
ctxshutdown                        if there are no open sessions it will shutdown right away
                                   (if there are open sessions, it waits 60 seconds and sends message to user sessions)
ctxshutdown -m 60 "Please log off" display a message and begin the shut down process after 60 seconds

ctxcreatefarm                      creates a serverfarm (asks for farmname and passphrase, which is used for joining a server to the farm)
ctxfarm -c                         creates a serverfarm (same as above9
ctxfarm -l                         identifying the servers in a farm
ctxfarm -j                         joins a server to the farm (asks for farmname, passphrase...)(ctxjoinfarm is the same)
ctxfarm -r <server>                remove a server from a farm (if no server name is specified, the local server name is removed)
                                   (after removal its published applications are not available)

ctxlscdfg                          license configuation (you can add server, port)
ctxlsdcfg --> list                 lists license configuration

ctxappcfg --> publish              configures publ. appl. (Name, Command Line, Anonymous (no), User, Group, Server, the others are default)

ctxcfg -g                          generates a list of current settings
ctxcfg -a list                     shows logon settings
ctxcfg -l list                     shows the number of logons permitted (ctxcfg -l max=<number> changes the max logon setting)
ctxcfg -c list                     shows config for broken connection

ctxbrcfg                           browser (ICA) config tool

ctxqsession                        displays sessions on the local server
ctxqsession -s <server>            displays sessions on the specified server in the farm
ctxqsession -S                     displays sessions on all the servers in the farm

                        listen    -the session is listening for new incoming connections
                        active    -indicates an established, active connection
                        connq     -indicates a brief init. phase that occurs before logon prompt appears, and during reconnect
                        init      -a brief session initialization phase
                        conn      -indicates a session that is being connected (login screen is up, butdid not login yet)
                        disc      -indicates a disconnected session
                        down      -indicates a broken session
                        shadow    -indicates that the user of this session is shadowing another
                        reset     -indicates a session currently being reset

ctxquser                          displays user sessions on the local server
ctxquser -s <server> user <user>  displays a specific user session on the specified server
ctxquser -S                       displays all user session on all servers in the farm

ctxqserver                        displays information about servers on the subnet
ctxlogoff <id>                    logs off users from sessions on local server (ctxlogoff <server>::<id>)
ctxdisconnect <id>                disconnects a session on the local server, it will show "disc" state (ctxdisconnect <server>::<id>)
ctxmsg <id> <msg>                 sends a message to the spcified session on the local server (ctxmsg <server>::<id> <message>)
ctxmsg -s <server> <message>      sends message to all sessions on a particular server
ctxmsg -a <message>               sends a message to all sessions on the local server
ctxmsg -S <message>               sends a message to all sessions in all servers


Installations and Setting Up:

1. Configure a license server (if you configure a license server after the installation then ctxlsdcfg command is needed to configure communication with the license server mannually)

2. Consider the desing of the server farm (the server where you create the farm, will become the Master)

3. Set up accounts: ctxadm group, ctxsrv (or ctxadmin) user

4. Install the MetaFrame Presentation Server software, and you can start it with "ctxsrv start"
(it will be started automatically at boot: ctxmfd:2:wait:/usr/bin/startsrc -sctxmfd)
(the daemon ctxmfd is installed in /usr/lpp/CTXSmf/sbin and an entry is made in /etc/inittab which starts it up automatically)

To complete the installation, you must configure the following settings manually:
- Set the XML Service port number: ctxnfusesrv -port portnumber                <--by default port 80 will be used
- Start the Management Service daemon: ctxsrv start msd                        <--needed if it is not running (e.g. after port config)
- Create or join a server farm: ctxcreatefarm or ctxjoinfarm
- Configure communication with the license server: ctxlsdcfg
- If you want to enable SSL Relay, write SSL_ENABLED=1 to /var/CTXSmf/ssl/config
- Add a line to /etc/syslog.conf: user.notice;user.info /var/log/citrix.log
- Add the MetaFrame path(s) to your path, so that you can run the MetaFrame commands:
  User commands:                /usr/lpp/CTXSmf/bin
  System Administrator commands:    /usr/lpp/CTXSmf/sbin

MetaFrame uses the security set up on the UNIX server. Therefore, you do not need to set up new user accounts for MetaFrame, the user at the client device can log on using their existing UNIX user account and password. Make sure that all users who connect to the server have a home directory path that is valid on the server, and that can be written by the user. If a user has no home directory and tries to connect, the logon fails.

6. install client software on client systems

7. create ICA connections to your server


Checking user access to published appl.

1. ctxappcfg
2. list                    <--lists published appl.-s
3. select <publ. appl.>    <--select publ. appl.
4. list users              <--shows users who has access to appl.


Ending/Disconnecting a session:

- ctxdisconnect: Disconnecting a session terminates the connection between the server and client. However, the user is not logged off and all running programs remain active, and the user can later reconnect to the disconnected session.

- ctxlogoff: Logging off a session terminates the connection and all running programs, and the user cannot reconnect to the session.

- ctxreset: In the event of an error you can reset a session. The system will attempt to terminate all processes running within that session. Resetting a session may cause applications to close without saving data.

1. ctxqsession
ctxadmin@aix14: / # ctxqsession
aix14.domain.com:0     -          listen   wdica -
aix14.domain.com:14    ctxadmin   active   wdica aix31              <--identify session id (here 14)

2. ctxdisconnect or ctxlogoff or ctxreset
- ctxadmin@aix14: / # ctxdisconnect 14                              <--disconnects a session (state of the session will be "disc")
                                                                    (re-connecting again is possible with "ctxconnect 14")

- ctxadmin@aix14: / # ctxlogoff 14                                  <--logging off a session

- ctxadmin@aix14: / # ctxreset 14                                   <--resetting a session


Controlling load on a server:

When a user experiencing problems runnig a session, or the server has no more free resources, you can do the followings:

- set the load factor to a lower value (this not explicitly limits that no new logins will be made):
    ctxqserver -app <publ. appl.> <server>                        <--displaying the load of a publ. appl. on a specific server
    ctxcfg -g | grep loadfactor                                   <--displaying the loadfactor on the server (e.g. 100)
    ctxsrv stop browser                                           <--stop bowser
    ctxcfg -k loadfactor=75                                       <--allow 25% less load than on the other servers
    ctxsrv start browser                                          <--start browser

- tune the number of connections on the server:
    ctxcfg -l max=200                                             <--it will maximize the number of connection to 200

- disable logons on the server:
    ctxcfg -k


- /usr/lpp/CTXSmf/sbin/ctxfarm -l shows: The Management Service is not available. Please restart the Management Service and try again.
- Process count for /usr/lpp/CTXSmf/slib//ctxxmldssup --run-as-root is below 1
- /usr/lpp/CTXSmf/bin/ctxquery -f Saupi -S: Session information is not available for the following servers: _NODE_

- internal communication between farm servers is disturbed

1. Log in via ssh to the affected node (_NODE_) with root login

2. Restart citrix msd. with /usr/lpp/CTXSmf/sbin/ctxsrv start msd
   If command fails /usr/lpp/CTXSmf/slib/ctxxmld has to be stopped manually:
     - ps -ef|grep xml
     - look for the xml process with parent process number 1 and owner ctxsrvr and "kill -9" them
     (i.e. ctxsrvr 123456 1 0 12:12:12 - 0:00 /usr/lpp/CTXSmf/slib/ctxxmld)
     - then try to restart again: /usr/lpp/CTXSmf/sbin/ctxsrv start msd

1 comment:

  1. nice blog for system administrator , ................thanq u to blog poster