XenAPP 6.x Servers removed from farm still showing up in Delivery Console

Unable to remove a XenAPP 6.x server from the farm.  The server still shows up in the delivery console.  The elegant way of removing it gracefully was not possible because it was a Citrix Provisioned server.

Command line on a data collector


Server that shows up is in the list

dscheck /full servers /clean

Force a delete

dscheck /full servers /deletemf SERVERNAME

SERVERNAME is case sensitive

dscheck /full servers /clean

The server should now be out of the delivery console.

Client To Server Content Redirection


Right now I am researching a Citrix published applications and content redirection issue that happened once in the last three years in XenApp 6.0.  I simply unassociated the files association, applied, then re-associated.  No issues…. now it is happening and opening PDF reader instead of Office 2007 (don’t ask… I am afraid of introducing the new ribbon interface to the user community without training).

Uncheck “show all available file types for this application” (if necessary), click apply, and then recheck the option. This should refresh the file extensions added to the registry in previous steps.  This is exactly what I did a couple years ago, but it isn’t working after a day or less.  Also this time around it is opening PDF reader instead of office 2007?????

  • Server to Client content redirection; this makes it possible to start URLs locally on the client PC. Embedded URLs are intercepted on the server running Presentation Server and sent to the client. The user’s locally installed browser is used to display the website.
  • Client to Server content redirection; when a user double-clicks a file the corresponding application is started on the Citrix server.

Resources on Content Redirection on http://www.virtualizationadmin.com/ by [Published on 1 Aug. 2006 / Last Updated on 1 Aug. 2006]

Another resource:  https://www.conetrix.com/ Client-to-Server content redirection

  1. Command line to set file associations globally on a server:
    • To display a list of file extensions and their associations, type assoc at a command prompt, and then press ENTER.
    • To display the association for a specific file extension, type assoc .<xxx> at a command prompt, and then press ENTER, where <xxx> is the file extension whose association you want to view.
    • To change the association for a specific file extension, type assoc .<xxx>=<file type> at a command prompt, and then press ENTER, where <xxx> is the file extension whose association you want to change, and <file type> is the program, dynamic data exchange (DDE), or OLE object you want to associate with the file extension.
    • To display the open command to use when launching a certain file type, type ftype <file type>  at a command prompt, and the press ENTER, where <file type> is the program, dynamic data exchange (DDE), or OLE object you want to associate with the file extension.
    • To change the program association for a specific file type, type ftype <file type>=<program path> at a command prompt, and the press ENTER, where <file type> is the program, dynamic data exchange (DDE), or OLE object you want to associate with the file extension and <program path> is the path to the executable used to open the application.
    • If the file type for the extension you are wanting to add already exists (for example Excel.Sheet.12), all you would have to do is associate the new extension with that file type. This would allow the new extension to open with the program associated with that file type.
    • If the file type for the extension you are wanting to add does not exist or you do not know what its file type is, you would have to add both the association and the file type. The example below associates the extension .tstx with the file type test.document. It the associates the file type test.document to open with the program test.exe. This would allow any documents with the extension .tstx to open with test.exe.
  2. Once the association has been added to the registry, complete the following steps in the Citrix Management Console to view the new file associations:
    • Within the console, browse to Citrix server from which you are running the console (this should be the same server on which you added the file extensions)
    • Right click server, select Other Tasks > Update file types from registry.
    • Browse to published application with which new association should use content redirection with.
    • Right click application and choose application properties and select content redirection menu.

What the hell?????

XenApp 6.0 tidbits from www.thomaskoetzing.de

source: http://www.thomaskoetzing.de/

Citrix XenApp 6.0/6.5 and Microsoft Windows Server 2008 R2
I highly recommend to install service pack 1 for Server 2008 R2 because it fixes several Remote Desktop Service (Terminal Service) issues that are also affecting XenApp. Read the following KB for Known Issues CTX126711 with SP1 and CTX129241.

I also highly recommend installing the Rollup Pack 1 for XenApp 6.0 and XenApp 6.5. See also Citrix recommended Microsoft and Citrix Hotfixes for XenApp 6 and Windows Server 2008 R2 at CTX129229

Citrix XenApp 6.0/6.5 update script
I modified my existing update script just for XenApp 6.0 on Server 2008 R2. The script will not work with older versions of XenApp. Also the script is not downloading or applying components like the role manager etc.

Download the script here: XA6xUpdate_v1.6.zip

Citrix XenApp 6.0/6.5 things to know:

Citrix XenApp 6.0/6.5 and Server 2008 R2 Service Pack 1 (SP1)

Citrix XenApp 6.0 / 6.5 bug list:

Windows Server 2008 R2 bug list:

  • Shadowing users with multi monitor is not possible right now and therefore also NOT for XenApp 6.0, this is really a pain for support personal
    Error: Shadow failed. Error code 7044
  • Annoying “Single-click” folder option for users on Server 2008 R2
    The group policy “Classic Shell activate” (Windows-Explorer) should fix that by enabling it but actually you should disable it! Then users have to set the folder option back and forth or you can set a registry value to do it for the users.

XenApp 6.x Commands Reference

XenApp Commands Reference

Citrix XenApp commands provide an alternative method to using the console for maintaining and configuring servers and farms. Citrix XenApp commands must be run from a command prompt on a server running Citrix XenApp.

Command Description
acrcfg Configure auto-reconnect settings.
altaddr Specify server alternate IP address.
app Run application execution shell.
auditlog Generate server logon/logoff reports.
change client Change client device mapping.
chfarm Change the server farm membership of the server, create an additional farm, and configure a replacement data store.
ctxkeytool Generate farm key for IMA encryption.
ctxxmlss Change the Citrix XML Service port number.
dscheck Validate the integrity of the server farm data store.
dsmaint Maintain the server farm’s data store.
enablelb Enable load balancing for servers that fail health monitoring tests.
icaport Configure TCP/IP port number used by the ICA protocol on the server.
imaport Change IMA ports.
migratetosqlexpress Migrate the server farm’s data store from a Microsoft Access database to a SQL Server Express database.
query View information about server farms, processes, ICA sessions, and users.
twconfig Configure ICA display settings.


Use query to display information about server farms within the network.


query farm [server [/addr | /app | /app appname | /load | /ltload]]
query farm [ /tcp ] [ /continue ]
query farm [ /app | /app appname | /disc | /load | /ltload | /lboff | /process]
query farm [/online | /online zonename]
query farm [/offline | /offline zonename]
query farm [/zone | /zone zonename]
query farm [/?]


The name of a published application.
The name of a server within the farm.
The name of a zone within the farm.


Displays information about servers within an IMA-based server farm. You can use qfarm as a shortened form of query farm.
server /addr
Displays address data for the specified server.
Displays application names and server load information for all servers within the farm or for a specific server.
/app appname
Displays information for the specified application and server load information for all servers within the farm or for a specific server.
Do not pause after each page of output.
Displays disconnected session data for the farm.
Displays server load information for all servers within the farm or for a specific server.
Displays server load throttling information for all servers within the farm or for a specific server.
Displays the names of the servers removed from load balancing by Health Monitoring & Recovery.
Displays active processes for the farm.
Displays TCP/IP data for the farm.
Displays servers online within the farm and all zones. The data collectors are represented by the notation “D.”
/online zonename
Displays servers online within a specified zone. The data collectors are represented by the notation “D.”
Displays servers offline within the farm and all zones. The data collectors are represented by the notation “D.”
/offline zonename
Displays servers offline within a specified zone. The data collectors are represented by the notation “D.”
Displays all data collectors in all zones.
/zone zonename
Displays the data collector within a specified zone.
Displays the syntax for the utility and information about the utility’s options.


Query farm returns information for IMA-based servers within a server farm.

Security Restrictions

You must be a Citrix administrator to run query farm .


This article contains examples of PowerShell script designed to launch XenApp commands and being able to perform data manipulation between commands in one script.


  • Microsoft Windows Server 2008 R2
  • Citrix XenApp 6.0 or 6.5
  • Microsoft PowerShell


In some cases administrators have the need to capture information from PowerShell and also manipulate it for other wrong commands. Many PowerShell commands can be combined together using pipes. For example: Get-XAApplication | Clear-XAApplicationLoadEvaluator

This command removes the load evaluator from each one of the applications.

In this one line command example, the administrator has no opportunity to see the data captured by the Get-XAApplication before it is used under the Clear-XAApplicationLoadEvaluator, this article contains examples of other ways to launch this command so there is space in between for some data manipulation or data reporting.

PowerShell Script Designed to Launch XenApp Commands

Following are two examples to understand PowerShell script designed to launch XenApp commands:

Example 1


The following PowerShell command reports each application name and removes its load evaluator.

Write-Host "Adding Citrix Powershell Snapin..."

Add-PSSnapin Citrix.XenApp.Commands

Write-Host "Checking applicatoon list and removing load evaluators."

ForEach ($App in Get-XAApplication)


        Clear-XAApplicationLoadEvaluator -BrowserName $App.BrowserName


Write-Host "Job Done, Have a Nice Day !!"

This script works the same as the preceding one line command. The data between the steps can be worked on in this approach. This method provides flexibility to report or validate with certain condition.

Example 2


The following PowerShell command reports each application name, removes its load evaluator, except on applications from the Microsoft Office Suite.

Write-Host "Adding Citrix Powershell Snapin..."

Add-PSSnapin Citrix.XenApp.Commands

$y = 0

Write-Host "Checking applicatoon list and removing load evaluators."

ForEach ($App in Get-XAApplication)


      if($App.DisplayName-notlike "*Microsoft*")


        Clear-XAApplicationLoadEvaluator -BrowserName $App.BrowserName




        $y += 1



Write-Host "The load evaluator was not removed from $z application(s)."

Write-Host "Job Done, Have a Nice Day !!"

Adding extra steps to the script can verify each application name and validate if it contains the word Microsoft, if it exists load evaluator is not removed, if it does not exist the load evaluator for the application is cleared.

In certain areas of the script, code is added to write messages to the console, this is useful for farms that have a lot of applications. Using this message an administrator gets an idea that the script is running and the progress so far. Also this script contains a count result to report how many applications were not modified in total.


This article implies that the XenApp PowerShell commands are quite flexible, similar to the native commands existing in Windows PowerShell. Many tasks can be completed using the same logic. This can be used for monitoring, reporting, configurations, and so on. The one line commands as mentioned at the beginning of the article can be used, but to have all or most of your routines simplified or even automated this is a good approach. This helps reducing resources in routine and replacing it with higher priority tasks.

Additional Resources

Citrix Download – Citrix XenApp 6.0 SDK

Citrix Download – Citrix XenApp 6.5 SDKCTX126471 – How to Install and Enable XenApp 6.0 SDK

CTX126287 – How to Use Microsoft PowerShell with Configuration Logging to Export DataCTX126987 – How to Capture a CDF Trace with PowerShell in XenApp 6

Applicable Products

Citrix XenApp 6: 12 Command-Line Tools Worth Knowing

While managing your Citrix XenApp 6 farm from the comfort of the Citrix Delivery Services Console GUI tool is a very powerful thing, you should know that XenApp 6 also has a subset of command-line tools that are at your disposal and can help with advanced farm management and troubleshooting:

1. Altaddr: If you’re a Citrix old timer, you probably remember using this tool before secure gateway was available, in order to extend the published applications to users outside the secure network. In essence, what Altaddr allows you to do is give your XenApp server an alternate IP address. Traditionally this was an outside facing public IP address or some kind of a NAT. Of course, the down side is if you have 100 XenApp servers, you would need 100 public IP addresses. Altaddr is not in use or popular anymore, but it is still there if you have the distinct situation where it makes sense.

2. App: Typically used for scripting or customizing an application’s behavior. You can use App in your scripts to control the application’s environment or to satisfy its prerequisites before the application runs.

3. Auditlog: A handy utility that, for the most part, dumps the security event log from Windows and allows you to pipe that log into a text file. You can use the output to audit who logged in or out of the server and when. This could come in handy if you are troubleshooting, for example, if your print service crashes; you can see who logged in during that time and if they are mapping a bad driver, etc.

4. Change client: Allows you to change the client device mappings in an ICA session, LOT, COM, USB mappings. etc.

5. Ctxkeytool: You can use this utility to generate an encryption key that can be used when enabling IMA encrypted communication in the Citrix farm.

6. Ctxxmlss: This handy little utility allows you to modify the XML port on the XenApp servers should you need to change that port for any reason.

7. Dscheck: I use this tool frequently to check for consistency on the Citrix IMA data store. It is particularly handy in conjunction with the /clean switch, which you would use to clear out any inconsistencies in the database.

8. Dsmaint: All interaction with your data store can be manipulated using this tool. For example, if you want to change data store database servers, you can use Dsmaint to do so. You can also use it to verify the local host cache on the XenApp server. The Local Host Cache or LHC is a subset of the data store database that runs on each XenApp server. Sometimes, as a troubleshooting step, you may want to verify the accuracy of that data or even refresh it altogether.

9. Enablelb: This utility restores XenApp servers into the load balancing mix after they have failed Citrix health monitoring tests.

10. Icaport: Here’s a too that allows you to change the default port that the ICA protocol typically runs on.

11. Imaport: allows you to change the default port that the IMA protocol runs on

12. Query: Arguably the most useful command-line tool, I use the query command for troubleshooting, for verifying load on the server, for just about anything administration related. If I need to know, I always start with the query command. It has a subset of values:

  • Query Farm or QFARM returns information on the XenApp servers in the farm and which one is a data collector
  • Query Session returns information about the sessions that are running on the XenApp server
  • Query Process will return the all the running processes on the server
  • Query User or QUSER returns information about all the users on the server

All these tools are available to you with the default installation of XenApp 6. However, as you can see from the list above, the number of Citrix XenApp 6 command-line tools has been shrinking with each new version and that is not because of insufficient development. Instead, it’s because Citrix is kind of following the Microsoft lead and porting most of its command-line tools to PowerShell. Event so, XenApp 6 has a very rich PowerShell footprint, wihich I plan to explore more in future blogs.

Using One Citrix Web Interface Site with Multiple XenApp Farms

How Does Web Interface Work

source: Carl Webster The Accidental Citrix Admin

In a Microsoft Windows environment, Web Interface works with Internet Information Services (IIS) to provide users with access to published resources. Users will use a standards based Internet browser or the Citrix Receiver to access their resources.

A Web Interface (WI) server will have one or more XenApp Web sites or XenApp Services sites configured. Each site will be configured for one or more XenApp farms. Each XenApp farm will have one or more XML Brokers listed to handle user authentication and resource enumeration. Once a user has been authenticated and selects a published resource, the Zone Data Collector (DC) is contacted. The DC determine s if the user has an existing session on the server hosting the published resource and if a session exists, that session is reused (called Session Sharing). If the user does not have an existing session, a session is created and the published resource is started.

The XML Broker will also request a session ticket from the Secure Ticket Authority (STA). The STA is responsible for issuing session tickets in response to the request to connect to the published resources. These session tickets form the basis of authentication and authorization for access to the published resources.

A Web Interface server is normally placed in a DMZ; however, it may be placed inside the corporate network. Web Interface requires no XenApp components to be installed. A Web Interface server is not typically a member of a XenApp farm, nor is it typically a member of an Active Directory domain. However, in the smallest of networks, it is possible and common for Web Interface to be deployed on a XenApp farm member and/or on a member of an Active Directory domain.

First, let’s stop, take a step back and review some basics.

What is a XenApp farm? A XenApp farm is a group of XenApp servers that can be managed as a unit, enabling the administrator to configure features and settings for the entire XenApp farm rather than being required to configure each server individually. All the servers in a farm share a single data store.What is a data store? The data store provides a repository of persistent information about the farm that each server can reference, including the following:

  • Farm configuration information,
  • Published resource configurations,
  • Server configurations,
  • XenApp administrator accounts,
  • Printers,
  • Printer drivers,
  • Policies,
  • Load Evaluators, and
  • Folders.

What is a Zone? A Zone is a logical grouping of XenApp servers that share a common zone data collector. Zones allow the efficient collection of dynamic farm information. Each zone in a farm has exactly one data collector. All of the member servers in a particular zone communicate their dynamic information to the data collector for their zone.

What is a zone data collector? A zone data collector is a server that stores and manages dynamic information about the XenApp servers in a zone, including:

  • Published resource usage,
  • Server load,
  • User sessions,
  • Online servers,
  • Connected sessions,
  • Disconnected sessions, and
  • Load balancing information.

The data collector shares this information with all other data collectors in the XenApp farm.

All XenApp servers in the farm use the Independent Management Architecture (IMA) service and protocol in server-to-server communication. IMA also is used by the Access Management Console or the Delivery Services Console or AppCenter (depending on the version of XenApp used) to allow XenApp farm administrators to manage and configure various XenApp farm and server settings.

What is an XML Broker? The Citrix XML Broker functions as an intermediary between the XenApp servers in the XenApp 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 XenApp farm for a list of published resources that the user has permission to access. The XML Broker retrieves this application set from the IMA system and returns it to the Web Interface.
  • Upon receiving the user’s request to launch a resource, the DC 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 DC 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 the XenApp installation process. Multiple XenApp servers can have their XML Service specified in Web Interface to allow those servers to function as a XML Broker. The XML Service on the other farm servers still runs but is not used for servicing end-user connections.

The Secure Ticket Authority is also installed on every XenApp server.

For most small to medium sized XenApp farms, one XenApp server is dedicated to be the Zone Data Collector, XML Broker and STA server. In some large XenApp farms, it may be necessary to dedicate a XenApp server for each of the three roles.

Dedicating a XenApp server for each role is easy to do. You would have three XenApp servers with no end-user applications installed. In the Zone settings for the farm, you would configure one of the servers as the Most Preferred data collector and the other two as Preferred data collectors. The server to be dedicated as the XML Broker would only be used when an XML Broker needs to be entered. The server to be dedicated as the STA server would only be used when an STA server needs to be entered.

Figure 1 illustrates the interaction between Web Interface and other servers in a XenApp farm.

Figure 1

Figure 1

Figure 2 shows some of the steps involved in the Web Interface process.

Figure 2

Step Action Graphic
1 A user connects to a Web Interface server from any device that has Citrix client software installed.
2 The user enters their credentials on the login page.
3 The web server reads the user’s credentials and forwards the credentials to the Citrix XML Service on the servers listed in the server farms.
4 If the user’s credentials are not valid, return to Step 2. If the user’s credentials are valid, the Citrix XML Service retrieves a list of resources from the XenApp servers the user has permission to access. This list of resources is called the user’s resource set. The Citrix XML Services returns the resource list back to the Web Interface server.
5 The Web Interface server builds a custom HTML web page consisting of the resources the user has permissions to run.
6 The user clicks one of the published resource icons.
7 The Citrix XML Service locates a server in the required farm that has an existing session for the user and the settings for the resource being launched match the settings for the resources running in the existing session. If those conditions match, the Citrix XML Service requests a session ticket and returns the server’s IP address and session ticket to the Web Interface server. If those conditions are not met, the Citrix XML Service requests a session ticket from the least-busy server and returns the server’s IP address and session ticket to the Web Interface server.
8 Web Interface creates a custom launch.ica file and sends the file to the user’s Citrix client.
9 The Citrix client software receives the file and initiates a session with the server specified in the file.
10 The published resource runs on the XenApp server and is displayed on the end-user device.