Using One Citrix Web Interface Site With Multiple XenApp Farms PDF

Using One Citrix Web
Interface Site with

Multiple XenApp Farms
Carl Webster
CTP, CCIA, CCEE, CCEA
Published by Carl Webster
Tullahoma, TN 37388
First published 2011 by Carl Webster
Copyright Carl Webster 2011
All Rights Reserved
Usinf One Citrix Web Interface Site with Multiple XenApp Farms
Copyright 2011 Carl Webster, All Rights Reserved
Page 1
Contact Info:
webster@carlwebster.com
Article web site: http://CarlWebster.com
Page 2
Contents
Introduction .............................................................................................................................................. 4
How Does Web Interface Work ................................................................................................................ 7
Creating a Combined Web Interface Site................................................................................................ 13
Testing the Combined Web Interface Site .............................................................................................. 33
Configuring Citrix Secure Gateway and Web Interface .......................................................................... 44
Final Tests ............................................................................................................................................... 57
Appendix A Finding the Most Preferred Data Collector ......................................................................... 61
For XenApp 5 for Windows Server 2003 ............................................................................................. 61
For XenApp 5 for Windows Server 2008 ............................................................................................. 62
For XenApp 6.0.................................................................................................................................... 64
For XenApp 6.5.................................................................................................................................... 67
Appendix B Finding the XML Port for XenApp 5 for Windows Server 2003 ........................................... 69
Appendix C Finding the XML Port for XenApp 5 for Windows Server 2008 ........................................... 72
Appendix D Finding the XML Port for XenApp 6.0 .................................................................................. 75
Appendix E Finding the XML Port for XenApp 6.5 .................................................................................. 82
Page 3
Introduction
I frequent Experts Exchange (http://www.experts-exchange.com/) and because of my status there, I
often receive questions. Some of the questions have a common theme. Such as:
How do I show published applications to my users when I have multiple XenApp farms?
How can I use Web Interface to migrate users to a new XenApp farm while using both farms?
If I have the same application published in multiple farms, how can I control which farm the
application is run from?
In this article, you will learn how to configure Web Interface 5.4 and Citrix Secure Gateway 3.3 for
multiple XenApp farms.
There are several potential reasons for using multiple XenApp farms:
XenApp 6.0 and XenApp 6.5 require new farms

Distinct farms for 32-bit applications and 64-bit applications
Organizational security requirements
Business mergers and acquisitions
Multiple internal environments
XenApp 6.x cannot be integrated into the farm of an earlier version of XenApp or Presentation Server.
Similarly, XenApp 6.5 cannot be mixed with a XenApp 6.0 farm. Attempting to join a XenApp 6.x server
into an earlier farm will damage the data store.
Deploying a 32-bit application on a 64-bit server will install the application, by default, in the C:\Program
Files (x86)\ folder tree. Deploying a 32-bit application on a 32-bit server will install the application, by
default, in the C:\Program Files\ directory. This means that the default application location used when
publishing the application is different for 32-bit and 64-bit versions of Windows Server when installing a
32-bit application.
An enterprise may have applications that are required to be separated from other applications for
security or business requirements. Installing the applications to XenApp servers that are in different
farms can allow for segregated farm administration and more granular user access.
When one business merges with or acquires another business, it is possible that both businesses may
have pre-existing XenApp farms. Business requirements, during the transition phase, may necessitate
the need to keep the XenApp farms separate temporarily or permanently.
A highly structured environment with strict change management controls may require different farms
for different environments. For example, an organization may have Development, Test, QA, Training
and Production environments. An application may be installed into the Development farm until
network and systems administration procedures are documented. Once documented, the settings for
the application can be moved into the Test farm. The Test farm can then be used for user acceptance
Page 4
testing. Once user testing has been completed, the settings for the application can be moved into the
next farm. And so on, until the application is put into the production farm.
For this article, the following Virtual Machines (VMs) will be used:
Domain Controller: TrainingDC

o The VM will be assigned two virtual CPUs (vCPUs), 2GB of RAM and 24GB of Hard Drive
space
o Windows Server 2008 R2 SP1
o Domain Controller for the WebstersLab.com Active Directory domain
o Remote Desktop Services License server and Citrix Licensing server
o Static IP Address 192.168.1.100
SQL Server: TrainingSQL
o The VM will be assigned two vCPUs, 2GB of RAM and 24GB of Hard Drive space
o Hosts the SQL Server data stores for all four XenApp farms
o Microsoft SQL Server 2008 R2 SP1 on Windows Server 2008 R2 SP1
XenApp 5 #1: XA520031
o XenApp 5 for Server 2003 Hotfix Rollup Pack 7 on Windows Server 2003 SP2 32-bit
o Default XML port of 80
o Farm name XA52003
XenApp 5 #3: XA520081
o XenApp 5 for Server 2008 Hotfix Rollup Pack 1 on Windows Server 2008 SP2 32-bit
o Default XML port of 80
o Farm name XA52008
Web Interface and Citrix Secure Gateway: CitrixWI
o Windows Server 2003 SP2 32-bit
o Web Interface 5.4 with Hotfix WI540MSI002 and Citrix Secure Gateway 3.3
o Not a member of the WebstersLab.com domain
XenApp 6.0: XENAPP60
o XenApp 6.0 Hotfix Rollup Pack 1 on Windows Server 2008 R2 SP1
o XML port 8060
o Farm name XA60Farm
XenApp 6.5: XENAPP65
Page 5
o
o
o
o
o
The VM will be assigned two vCPUs, 4GB of RAM and 40GB of Hard Drive space
XenApp 6.5 on Windows Server 2008 R2 SP1
Static IP Address 192.168.1.107
XML port 8065
Farm name XA65Farm
In addition to the Administrator account, five accounts were created in the WebstersLab.com domain:
User03, who has access to only the XA52003 farm

User08, who has access to only the XA52008 farm
User60, who has access to only the XA60Farm farm
User65, who has access to only the XA65Farm farm
UserAll, who has access to all four farms
Each farm has two resources published.
XA52003
o Notepad
o Word 2010
XA52008
o Paint
o Word 2010
XA60Farm
o Calculator
o Word 2010
XA65Farm
o WordPad
o Word 2010
Page 6
How Does Web Interface Work

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, lets 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
Page 7
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 users 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 users 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
Page 8
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 2 shows some of the steps involved in the Web Interface process.
Figure 2
Step
Action
Graphic
Page 9
A user connects to a Web Interface server

from any device that has Citrix client
software installed.
The user enters their credentials on the

login page.
The web server reads the users credentials

and forwards the credentials to the Citrix
XML Service on the servers listed in the
server farms.
Page 10
If the users credentials are not valid,

return to Step 2. If the users 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 users resource
set. The Citrix XML Services returns the
resource list back to the Web Interface
server.
The Web Interface server builds a custom
HTML web page consisting of the resources
the user has permissions to run.
The user clicks one of the published

resource icons.
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 servers 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
Page 11
the least-busy server and returns the

servers IP address and session ticket to the
Web Interface server.
Web Interface creates a custom launch.ica
file and sends the file to the users Citrix
client.
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.
Page 12
Creating a Combined Web Interface Site

To create a XenApp Web Site that will support multiple XenApp farms, start the Citrix Web Interface
Management console from the Web Interface server, as shown in Figure 3.
Figure 3
Click on XenApp Web Sites in the left pane and then click Create Site in the Actions pane (Figure 4).
Figure 4
You can give the new site a Name or leave it as the default (which is XenApp). If you want, you can also
select the box to Set as the default page for the IIS site. For this article, this site will be the only site in
IIS. The site is given the name Combined and set as the default site as shown in Figure 5. Click Next.
Page 13
Figure 5
Leave the Point of Authentication set to At Web Interface and click Next (Figure 6).
Figure 6
Click Next on the Confirm Settings for New Site screen and click Next (Figure 7).
Page 14
Figure 7
After a few moments, the new site is created. Uncheck the Configure this site now option and click
Finish (Figure 8).
Figure 8
Select the new site in the top middle pane and click Server Farms in the Actions pane (Figure 9).
Page 15
Figure 9
Click Edit (Figure 10).

Figure 10
The Farm name entered here has nothing to do with the farm name given when the farm was created.
The name can be the same (recommended), but it is not required.
Page 16
Fellow CTP Thomas Koetzing makes this recommendation for the farm name:
For me best practice is to give speaking farm names in Web Interface (WI). Farm
names in WI are totally unrelated to the real farm name. So for example I would
use something like XA6_production, XA6_acceptance, XA6_development, XD_APAC
etc. The reason for that is that the farm name is logged in the server eventlog and
makes it more readable. In the eventlog you would get something like
XA6_production failed to contact XML Broker instead of Farm1 failed or XA60
failed. It helps troubleshooting.
Enter a Farm name and click Add (Figure 11). I am entering information for the XenApp 5 on Windows
Server 2003 farm.
Figure 11
Enter the fully qualified domain name (FQDN) of a XenApp server in the XenApp farm into the Server
name field and click OK (Figure 12).
Note: You can use the NetBIOS name of the XenApp server but using the FQDN could help speed up
name resolution. Please see http://support.microsoft.com/kb/172218 for an explanation of Microsoft
TCP/IP Host Name Resolution Order.
Note: In XenApp 5.x and XenApp 6.0, all XenApp servers can be Secure Ticket Authority servers, XML
Brokers and even a data collector. In XenApp 6.5, this is not the case. If you have designated a XenApp
server to be the Most Preferred Data Collector, you should list that server here. The server you list here
Page 17
should also be used for Citrix Secure Gateway. Because the server listed here will be used to receive the
users credentials from the Web Interface, Citrix refers to this server as an XML Broker.
Note: How do you find the Most Preferred Data Collector for a XenApp farm? Please see Appendix A
Finding the Most Preferred Data Collector for explanations for all four versions of XenApp used for this
article.
Figure 12
Select the server named localhost and click Remove (Figure 13).
Figure 13
Since the XA52003 farm uses the default XML port of 80, click OK (Figure 14). If the XenApp farm is
configured to use a different XML port, make sure the correct port number is entered. It is
recommended to have at least two servers in this list. This allows for some basic redundancy: if one
server becomes unavailable, the other server(s) would be used.
Note: To learn how to find the XML port please see Appendix B Finding the XML Port for XenApp 5 for
Windows Server 2003.
Page 18
Figure 14
To add the next XenApp farm, click Add (Figure 15).

Figure 15
Page 19
Enter the next Farm name and click Add (Figure 16). I am entering information for the XenApp 5 on
Windows Server 2008 farm.
Figure 16
Enter the Server name of an XML Broker in the XenApp farm and click OK (Figure 17).
Figure 17
Since the XA52008 farm uses the default XML port of 80, click OK (Figure 18). If the XenApp farm is
configured to use a different XML port, make sure the correct port number is entered. It is
recommended to have at least two servers in this list. This allows for some basic redundancy: if one
server becomes unavailable, the other server(s) would be used.
Note: To learn how to find the XML port please see Appendix C Finding the XML Port for XenApp 5 for
Windows Server 2008.
Page 20
Figure 18
To add the next XenApp farm, click Add (Figure 19).

Figure 19
Page 21
Enter the next Farm name and click Add (Figure 20). I am now entering information for the XenApp 6.0
farm.
Figure 20
Figure 21
Since the XA60Farm farm does not use the default XML port of 80, enter the proper XML port of 8060
and click OK (Figure 22). It is recommended to have at least two servers in this list. This allows for some
basic redundancy: if one server becomes unavailable, the other server(s) would be used.
Note: To learn how to find the XML port, please see Appendix D Finding the XML Port for XenApp 6.0.
Page 22
Figure 22
To add the last XenApp farm, click Add (Figure 23).

Figure 23
Page 23
Enter the next Farm name and click Add (Figure 24). I am now entering information for the XenApp 6.5
farm.
Figure 24
Note: XenApp 6.5 has two modes for a server:
Controller and session-host mode

Session-host mode
Only enter XenApp 6.5 servers that have Controller and Session-host modes enabled. If you enter a
XenApp 6.5 server that is Session-host mode only, your site will not enumerate applications.
Figure 25
Since the XA65Farm farm does not use the default XML port of 80, enter the proper XML port of 8065
and click OK (Figure 26). It is recommended to have at least two servers in this list. This allows for some
basic redundancy: if one server becomes unavailable, the other server(s) would be used.
Page 24
Note: To learn how to find the XML port please see Appendix E Finding the XML Port for XenApp 6.5.
Figure 26
Now that all the XenApp farms have been entered, click Advanced (Figure 27).
Page 25
Figure 27
If SSL is not being used between the Web Interface server and the XML Broker, socket pooling should be
disabled. Please see http://support.citrix.com/article/CTX125715 for more information on the Enable
socket pooling option. If you use socket pooling, you force WI to use a single TCP connection and pool
all requests. If that single connection fails, WI can have a production outage. If you disable socket
pooling, every request will use its own TCP connection. Therefore, if one connection fails, the entire WI
site does not suffer an outage.
To use SSL between the WI server and the XML Broker, you could use the Citrix SSLRelay utility. In a
high security environment, all network traffic may be required to be encrypted. In that case, using
SSLRelay will be one option to consider. Please see http://tinyurl.com/SSLRelay for more information on
configuring SSLRelay.
Since SSL is not used between the WI server and the XML Broker for this article, uncheck Enable socket
pooling as shown in Figure 28 and click OK.
Page 26
Figure 28
The site needs to be configured before users can access it. Select the site in the middle pane and click
Authentication Methods in the Actions pane (Figure 29).
Figure 29
Page 27
The Citrix online documentation for Web Interface 5.4 explains the authentication methods available.
Please see http://support.citrix.com/proddocs/topic/web-interface-impington/wi-authenticatewrapper-gransden.html.
For this article, select only Explicit and click Properties (Figure 30).
Figure 30
When users go to the Web Interface site, they will need to enter a user name, a password and a domain
name. You may not want your users having to know or remember the domain name. You can prepopulate the Active Directory domain name to keep users from having to know this information. For
this article, I am entering my domain name, which is websterslab.
Select Domain Restriction, then select Restrict domains to the following and click the Add button (Figure
31).
Page 28
Figure 31
Enter websterslab for the Logon domain name and click OK (Figure 32).
Note: There is a difference here between entering websterslab and websterslab.com. The difference
comes into play for Session Sharing. For an explanation, see the following article by fellow CTP Thomas
Koetzing.
http://www.thomaskoetzing.de/index.php?option=com_content&task=view&id=313&Itemid=302
When I logon to my XenApp servers, I am using websterslab\UserName. That is why I am entering
websterslab and not websterslab.com even though the latter is the actual Active Directory domain
name.
Figure 32
Select Authentication Type, then select Domain user name only and click Settings (Figure 33).
Page 29
Figure 33
Select Hide Domain box, select Pre-populated from the drop-down box and click Add (Figure 34).
Figure 34
Select websterslab and click OK (Figure 35).
Page 30
Figure 35
Click OK (Figure 36).

Figure 36
Page 31
Figure 37

Figure 38
For the purposes of this article, that is the entire configuration needed for this site.
Page 32
Testing the Combined Web Interface Site

To verify that the site loads with no issues, click Preview Site in the Actions pane (Figure 39).
Figure 39
The site should display with no errors as shown in Figure 40.

Figure 40
Page 33
To verify that each user can access only the XenApp farm they are configured to access, login as each
user. First up is User03 that can access the XA52003 farm which has Notepad and Word 2010 published,
as shown in Figure 41.
Figure 41
Both Notepad and Word 2010 run successfully, as shown in Figure 42.
Figure 42
Exit both applications and logoff from User03. Next up is User08 that can access the XA52008 farm
which has Paint and Word 2010 published, as shown in Figure 43.
Page 34
Figure 43
Both Paint and Word 2010 run successfully, as shown in Figure 44.
Figure 44
Exit both applications and logoff from User08. Next up is User60 that can access the XA60Farm farm
which has Calculator and Word 2010 published, as shown in Figure 45.
Page 35
Figure 45
Both Paint and Word 2010 run successfully, as shown in Figure 46.
Figure 46
Exit both applications and logoff from User60. Next up is User65 that can access the XA65Farm farm
which has WordPad and Word 2010 published, as shown in Figure 47.
Page 36
Figure 47
Both WordPad and Word 2010 run successfully, as shown in Figure 48.
Figure 48
Exit both applications and logoff from User65. Next up is UserAll that can access all four XenApp farms
and all published applications, as shown in Figure 49.
Page 37
Figure 49
All eight published applications run successfully, as shown in Figure 50.

Figure 50
Exit all applications, logoff UserAll and exit your Internet browser.
Page 38
As you can see, getting multiple XenApp farms to work through one Web Interface site is not difficult.
As long as you enter the correct XML port when entering the farm information and at least two XML
Brokers ( recommended), you should have no issues.
In the examples used for this article, there are four copies of Word 2010 with the same application
name of Word 2010. What if the user only needs to be shown one copy of Word 2010? Starting with
Web Interface 5.3, Citrix added a parameter to the
C:\Inetpub\wwwroot\Citrix\XenApp\conf\webinterface.conf file called SuppressDuplicateResources. By
default, this is set to Off.
In order to enable this suppression, on the Web Interface server, exit the Citrix Web Interface
Management console. Open C:\Inetpub\wwwroot\Citrix\XenApp\conf\webinterface.conf using
WordPad (do not use Notepad) and search for SuppressDuplicateResources as shown in Figure 51.
Note: webinterface.conf is a UTF-8 encoded file. Editing this file with Notepad could cause you to
experience errors when the Web Interface website is opened.
Figure 51
Cancel the search dialog. Remove the # from the beginning of the line and change the value to On as
shown in Figure 52.
Page 39
Figure 52
Save the file and exit WordPad. Launch your Internet browser, open the Web Interface site and logon as
UserAll. As shown in Figure 53, only one copy of the Word 2010 published application is displayed.
Figure 53
That is good, but from which XenApp farm and server will this Word 2010 be launched from? Can you
guess before I show you the answer?
I created a Word file named for each server in the Documents folder for UserAll on each of the four
XenApp servers. Logging in as UserAll, launching Word 2010 and then going to File, Open reveals the
answer, as shown in Figure 54.
Page 40
Figure 54
Word 2010 launched from the XA520031 server. Why? Because it is the first server in the Manage
Server Farms server list as shown in Figure 55.
Figure 55
What happens if I move XENAPP65 to the top of the list of servers as shown in Figure 56?
Page 41
Figure 56
Logging back in as UserAll, launching Word 2010 and going to File, Open reveals the answer, as shown in
Figure 57.
Figure 57
Page 42
If you have multiple farms containing the same application name and you want to restrict your users to
running only one version of the application, you should move the desired server to the top of the server
list.
This also illustrates that even though I made a manual change to the webinterface.conf file and then
made a change to the Web Interface site configuration, my manual change is still there. I also went back
and ordered the servers in the farm list as shown in Figure 58.
Figure 58
What if you are using Citrix Secure Gateway (CSG)? How does CSG handle multiple XenApp farms?
Page 43
Configuring Citrix Secure Gateway and Web Interface

Citrix Secure Gateway needs to be reconfigured to make the necessary changes to handle multiple
XenApp farms.
Click Start, All Programs, Citrix, Management Consoles and Secure Gateway Management Console
(Figure 59).
Figure 59
Click Secure Gateway Configuration (Figure 60).

Figure 60

Page 44
Figure 61
Select Advanced and click Next (Figure 62).

Figure 62
Select the correct SSL certificate and click Next (Figure 63).
Page 45
Figure 63
Select Secure Sockets Layer (SSLv3) and TLSv1, All and click Next (Figure 64).
Figure 64
Click Next (Figure 65).
Page 46
Figure 65
Select No outbound traffic restrictions and click Next (Figure 66).

Figure 66
This is where you will enter the same list of servers and XML ports that you did when you configured the
Web Interface site as seen back in Figure 58. Click Add (Figure 67).
Page 47
Figure 67
Enter the name of a XenApp farm XML Broker and if the farm is not using the default XML port of 80,
uncheck Use default and enter the correct XML port.
Note: To learn how to find the XML port, please see:
Appendix B Finding the XML Port for XenApp 5 for Windows Server 2003.
Appendix C Finding the XML Port for XenApp 5 for Windows Server 2008.
Appendix D Finding the XML Port for XenApp 6.0.
Appendix E Finding the XML Port for XenApp 6.5.
If you do not enter the correct XML port, you will see the following error as shown in Figure 68. If you
receive this error, click the Back button and correct the XML port.
Page 48
Figure 68
See Figure 69 through Figure 73 for the entries related to my four XenApp farms. I am entering the
Secure Ticket Authority (STA) servers in the order they appear in the Web Interface site farm settings
servers list.
Figure 69
Page 49
Figure 70
Figure 71
Page 50
Figure 72
Figure 73
Once CSG is configured, on the Web Interface server, start the Citrix Web Interface Management
console and click Secure Access in the Actions pane (Figure 74).
Page 51
Figure 74
Click the Default Direct option and click Edit (Figure 75).
Figure 75
Select Gateway direct from the dropdown list and click OK (Figure 76).
Page 52
Figure 76

Figure 77
Enter the appropriate external name to reach the Web Interface site, select Enable session reliability, do
not select Request tickets from two STAs, where available and click Next (Figure 78). When the option to
Request tickets from two STAs, where available was enabled, I always received a Protocol Driver Error
when attempting to launch any published application. The only thing I could do to resolve that error
message was to not select requesting tickets from two STAs.
Page 53
Figure 78
Click Add (Figure 79).

Figure 79
Enter the FQDN of your first STA server plus /scripts/ctxsta.dll and click OK (Figure 80).
Page 54
Figure 80
Figure 81 shows the result of adding the first STA server.

Figure 81
These should be entered in the same order they were entered in the CSG configuration. See Figure 73
for that information.
Repeat this process until all the necessary STA servers have been entered as shown in Figure 82. Click
Finish.
Note: It is not necessary to enter an STA server for each XenApp farm. For the purposes of this article,
and for learning, an STA server from each farm will be entered.
Page 55
Figure 82
Page 56
Final Tests
Open your Internet browser and go to the FQDN you specified in Figure 78 to reach the site. For me,
this is https://citrix.websterslab.com as shown in Figure 83.
Figure 83
Login in as UserAll, launch the applications and verify that all applications still work. Word 2010 is still
run from the XenApp 6.5 server as shown in Figure 84.
Figure 84
Page 57
What happens if one of the XenApp servers used as an XML Broker/STA server becomes unavailable? To
test this, I powered off the XenApp 6.5 server because it is the first in both lists.
When I logged back in as userall, there was about a 22-second delay until the publish resources were
shown (Figure 85).
Figure 85
Do you see which published resource is not shown? WordPad is not available since it is published on the
XenApp 6.5 server which is powered off. Word 2010 is published in all four farms. If I start Word 2010
now, do you know which XenApp farm it will be launched from? The result is shown in Figure 86.
Figure 86
Page 58
Why is Word 2010 running from the XenApp 6.0 farm? Because the XenApp 6.0 farm is second in the list
of XenApp farms for this Web Interface site as shown in Figure 58.
Imagine you are the accidental Citrix administrator trying to figure out why WordPad is not showing for
userall, why Word 2010 is running from the XenApp 6.0 farm, why your user took so long to log on and
to log off. Where would start to look for your answer?
Go to the Web Interface server and open the Application event log as shown in Figure 87.
Figure 87
If you look at the first error reported, you would see the following error recorded:
Site path: c:\inetpub\wwwroot\Citrix\XenApp.
An error occurred while attempting to connect to the server XENAPP65.websterslab.com on port 8065. Verify that the Citrix
XML Service is running and is using the correct port. If the XML Service is configured to share ports with Microsoft Internet
Information Services (IIS), verify that IIS is running. This message was reported from the XML Service at address . The
specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services.
[Unique Log ID: e7a98902]
The next error is:

Site path: c:\inetpub\wwwroot\Citrix\XenApp.
All the Citrix XML Services configured for farm XA65_Lab failed to respond to this XML Service transaction. [Unique Log ID:
cb3c03d4]
Web Interface tried 10 times before it gave up and stopped recording the error.
This shows the XenApp 6.5 server listed to be used as the XML Broker for the XenApp 6.5 farm did not
respond. This is one of the reasons you should use at least two XML Brokers.
Page 59
When userall went to log off Web Interface, there was also about a 22 second delay as four more
attempts to contact the XenApp 6.5 XML Broker were made (the last two errors shown in Figure 87).
Even after adding Citrix Secure Gateway, getting multiple XenApp farms to work through one Web
Interface site is fairly easy. As long as you enter the correct XML port when entering the farm
information and when adding the STA in the CSG configuration, you should have no issues.
I would like to thank my friends and fellow CTPs Thomas Koetzing and Pierre Marmignon for taking their
time to review this article and for making numerous technical corrections and suggestions.
As always, my friend, and Exchange MVP, Michael B. Smith forced me to make numerous corrections
and additions and used up all the red pixels on his computer doing so.
Jo Harder used her fair share of red pixels also on this article.
Thanks to all four of them for helping me turn this article into another one of my novels. Without them,
I would have been finished two months ago!
Page 60
Appendix A Finding the Most Preferred Data Collector

For XenApp 5 for Windows Server 2003
Click Start, All Programs, Citrix, Management Consoles and select XenApp Advanced Configuration
(Figure 88).
Figure 88
Right-click the XenApp farm and select Properties (Figure 89).

Figure 89
Click Zones and expand the zone by clicking the + sign to the left of the zone name (Figure 90).
Page 61
Figure 90
The server with the blue checkmark is the Most Preferred server as shown in
Figure 91.
Figure 91
For XenApp 5 for Windows Server 2008

Click Start, All Programs, Citrix, Administration Tools and select XenApp Advanced Configuration (Figure
92).
Page 62
Figure 92
Right-click the XenApp farm and select Properties (Figure 93).

Figure 93
Click Zones and expand the zone by clicking the + sign to the left of the zone name (Figure 94).
Page 63
Figure 94
The server with the blue checkmark is the Most Preferred server as shown in
Figure 95.
Figure 95
For XenApp 6.0

Click Start, All Programs, Citrix, Management Consoles and select Citrix Delivery Services Console (Figure
96).
Page 64
Figure 96
Expand the farm by clicking the + sign to the left of the farm name (Figure 97).
Figure 97
Expand the zone by clicking the + sign to the left of Zones (Figure 98).
Page 65
Figure 98
Click on the zone name server and the Most Preferred server is shown in the Election Preference
column
Figure 99.
Figure 99
Page 66
For XenApp 6.5

Click Start, All Programs, Citrix, Management Consoles and select Citrix AppCenter (Figure 100).
Figure 100
Figure 101
Expand the zone by clicking the + sign to the left of Zones (Figure 102).
Page 67
Figure 102
Click on the zone name server and the Most Preferred server is shown in the Election Preference
column
Figure 103.
Figure 103
Page 68
Appendix B Finding the XML Port for XenApp 5 for Windows Server 2003
Click Start, All Programs, Citrix, Management Consoles and select Delivery Services Console (Figure 104).
Figure 104
Figure 105
Expand the servers by clicking the + sign to the left of the Servers node ().
Page 69
Figure 106
Select the server being used as the XML Broker (Figure 107).
Figure 107
Right-click the server, click Modify server properties and click Modify all properties (Figure 108).
Page 70
Figure 108
Click XML Service and the current XML port is shown (Figure 109).
Figure 109
Page 71
Appendix C Finding the XML Port for XenApp 5 for Windows Server 2008
Click Start, All Programs, Citrix, Management Consoles and select Delivery Services Console (Figure 110).
Figure 110
Figure 111
Expand the servers by clicking the + sign to the left of the Servers node (Figure 112).
Page 72
Figure 112
Select the server being used as the XML Broker (Figure 113).
Figure 113
Right-click the server, click Modify server properties and click Modify all properties (Figure 114).
Page 73
Figure 114
Click XML Service and the current XML port is shown (Figure 115).
Figure 115
Page 74
Appendix D Finding the XML Port for XenApp 6.0

Click Start, All Programs, Citrix, Management Consoles and select Citrix Delivery Services Console (Figure
116).
Figure 116
Figure 117
XenApp 6.0 does not have individual server properties. Those properties are now contained within
Citrix Policies.
Click on the Policies node and then the Computer tab (Figure 118).
Page 75
Figure 118
If there is only one Citrix Computer Policy named Unfiltered, finding the XML port will be easy. Click the
Summary tab (Figure 119). If the XML port is not using the default of 80, the policy setting will be
shown. If the XML service port policy setting is not shown in the Summary tab, then the default port of
80 is being used.
Page 76
Figure 119
If there are multiple Citrix Computer Policies, the modeling wizard needs to be run to see if a policy is
configured for the server being used as the XML Broker. Click Run the modeling wizard in the Actions
pane (Figure 120).
Figure 120
Page 77
Figure 121

Figure 122
Select Computer and click Browse (Figure 123).
Page 78
Figure 123
Enter the name of the server being used as the XML Broker, click Check Names and click OK (Figure 124).
Figure 124
Select Skip to the final page of the wizard without collecting additional data and click Next (Figure 125).
Page 79
Figure 125
Click Run (Figure 126)

Figure 126
Click Close (Figure 127).
Page 80
Figure 127
The modeling results are displayed as shown in Figure 128. The Citrix Computer Policy that affects the
XML service port should be displayed. If it is not displayed, then the default port of 80 is being used.
Figure 128
Page 81
Appendix E Finding the XML Port for XenApp 6.5

Click Start, All Programs, Citrix, Management Consoles and select Citrix AppCenter (Figure 129).
Figure 129
Figure 130
XenApp 6.5 does not have individual server properties. Those properties are now contained within
Citrix Policies.
Click on the Policies node and then the Computer tab Figure 131).
Page 82
Figure 131
If there is only one Citrix Computer Policy named Unfiltered, finding the XML port will be easy. Click the
Summary tab (Figure 132). If the XML port is not using the default of 80, the policy setting will be
shown. If the XML service port policy setting is not shown in the Summary tab, then the default port of
80 is being used.
Page 83
Figure 132
If there are multiple Citrix Computer Policies, the modeling wizard needs to be run to see if a policy is
configured for the server being used as the XML Broker. Click Run the modeling wizard in the Actions
pane (Figure 133).
Figure 133
Page 84
Figure 134

Figure 135
Select Computer and click Browse (Figure 136).
Page 85
Figure 136
Enter the name of the server being used as the XML Broker, click Check Names and click OK (Figure 137).
Figure 137
Select Skip to the final page of the wizard without collecting additional data and click Next (Figure 138).
Page 86
Figure 138
Click Run (Figure 139)

Figure 139
Click Close (Figure 140).
Page 87
Figure 140
The modeling results are displayed as shown in Figure 141. The Citrix Computer Policy that affects the
XML service port should be displayed. If it is not displayed, then the default port of 80 is being used.
Figure 141
Page 88

Using One Citrix Web Interface Site With Multiple XenApp Farms PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Using One Citrix Web Interface Site With Multiple XenApp Farms PDF

Uploaded by

Copyright:

Available Formats

Using One Citrix Web

Interface Site with

Published by Carl Webster

XenApp 6.0 and XenApp 6.5 require new farms

Domain Controller: TrainingDC

User03, who has access to only the XA52003 farm

Each farm has two resources published.

How Does Web Interface Work

Farm configuration information,

What is a Zone? A Zone is a logical grouping of XenApp servers that share a

servers in a particular zone communicate their dynamic information to the data

A user connects to a Web Interface server

The user enters their credentials on the

The web server reads the users credentials

If the users credentials are not valid,

The user clicks one of the published

The Citrix XML Service locates a server in

the least-busy server and returns the

The Citrix client software receives the file

The published resource runs on the XenApp

Creating a Combined Web Interface Site

Click Edit (Figure 10).

To add the next XenApp farm, click Add (Figure 15).

To add the next XenApp farm, click Add (Figure 19).

To add the last XenApp farm, click Add (Figure 23).

Controller and session-host mode

Select websterslab and click OK (Figure 35).

Click OK (Figure 36).

Click OK (Figure 37).

Click OK (Figure 38).

Testing the Combined Web Interface Site

The site should display with no errors as shown in Figure 40.

All eight published applications run successfully, as shown in Figure 50.

Configuring Citrix Secure Gateway and Web Interface

Click Secure Gateway Configuration (Figure 60).

Click OK (Figure 61).

Select Advanced and click Next (Figure 62).

Click Next (Figure 65).

Select No outbound traffic restrictions and click Next (Figure 66).

Click Next (Figure 77).

Click Add (Figure 79).

Figure 81 shows the result of adding the first STA server.

The next error is:

Appendix A Finding the Most Preferred Data Collector

Right-click the XenApp farm and select Properties (Figure 89).

For XenApp 5 for Windows Server 2008

Right-click the XenApp farm and select Properties (Figure 93).

For XenApp 6.0

For XenApp 6.5

Appendix D Finding the XML Port for XenApp 6.0

Click Next (Figure 121).

Click Next (Figure 122).

Select Computer and click Browse (Figure 123).

Click Run (Figure 126)

Click Close (Figure 127).

Appendix E Finding the XML Port for XenApp 6.5

Click Next (Figure 134).

Click Next (Figure 135).

Select Computer and click Browse (Figure 136).

Click Run (Figure 139)

Click Close (Figure 140).

You might also like