Windows Live Alerts
Start access
Support Forum
Remote Desktop Services
Terminal Services
Web Interface
Tips & Tools
Lassen Sie sich von einem Experten Beraten

Citrix Web Interface settings that should be default! Print E-mail
Written by Thomas Koetzing at Monday, 20 July 2009 | Article editor:

Article Details 
User Rating:   | 329

Citrix Web Interface is out for more than 10 years but still some settings are not default but they should. Recently I had a chat with the lead Architect for Web Interface and he asked me for settings that should be default. This article describes settings where I think they should be default and I will also explain why.

You disagree with me or want to add something, than leave a comment to the article.

XML Broker Load balancing vs Failover

The Web Interface default for "XML Broker" is load balancing. With this setting Web Interface uses all available XML Broker and goes from one server to the next. Many customers simply put every XML Broker in the list they can find.


                                            XML Broker are load balanced by default.

Problem with load balancing

When one XML Broker has a problem (corrupt local host cache, XML service issue) then randomly user have issues with Web Interface (no apps, white page etc.). Now to find the exact server with the issue can be challenging. Problems with XML Broker are quite common but administrators don't realize that fact.


With the Failover setting only the first server in the list will be used and only when failing Web Interface switches to the next in line. Now the first server should be the Citrix DataCollector because it holds the most current data. The second and maybe a third XML Brocker should be the most preferred servers in the Zone to become DataCollector. With the failover setting Web Interface uses always a DataCollector and therefore most current data for published applications.

The XML service is "light" performance wise and therefore not critical for the DataCollector. In Enterprise environments the DataCollector often doesn't host applications and just handles the XML traffic.


                              Default failover with the DataCollector as the first in line.

Default STA Failover

When using Citrix Gateway (Secure or Access) you should use the same STA servers as used for the XML Broker and also using failover and not load balancing. This time is not as criticall as for the XML Broker but keep the list small, since it helps troubleshooting.
Very important is to use the same STA server for Web Interface and the Citrix Gateway.


                 Make sure Web Interface and the Gateway has the same STA server(s).

Java Client Packages

The Citrix java client is often used for external access and as "clientless" solution. To keep the java client small for download the administrator can pre-select packages to include. Citrix has set some default packages whitch really shouldn't be selected as default.
Have you ever seen the java UI? Do you use ICA encryption other than basic? Don't you allow the clipboard?


                Default's for the Java Client packages. Very rarely used ICA encryption.

Default java packages

Again, the java client ist often use for external access and means secured by SSL/TLS. The local text echo helps with slow connections wich is common for external access as well. It's rare not to allow the clipboard feature to exchange simple text and should be default. Also the packages for client drive and printer should be default, since they are common to use too and can also be restriced by Citrix policies.


                Clipboard, SSL/TLS, local text echo, Client drive and printer should be defaults.

Sooket Pooling

The sooket pooling feature is only good for SSL connections between the Web Interface server and the XML Broker. Without SSL the transferred data in XML format are still secure, not highly secure but with a "scramble" of user information. Most companies don't bother with using certificates and the SSL Relay and use simply port 80 to access the XML service.

When not using SSL, then the enabled sooket pooling can have a negative effect on retrieving the XML data from the XML Broker. Therefore sooket pooling should be disabled by default.


          Default, sooket pooling is enabled but only good when using SSL for the XML Broker


Failover should be the default setting to handle XML Broker and STA server. Especially the XML Broker server should be Citrix DataCollector and most prefered DataCollector. This helps troubleshooting issues and ensures that Web Interface will get the most current data from the farm.

The Citrix Java Client is often used from outside the trusted network and therefore default packages should be SSL/TLS, local text echo, clipboard, Client -drive and -printer mapping.

Sooket pooling only helps when using SSL connection between Web Interface and an XML Broker whitch is often not the case and therefore sooket pooling should be disabled.

As a side note: Using XML DNS resoultion might not be a good idea and should only be enabled when really nessasery, especially when more XenApp farms are added to the same Web Interface farm.

The named changes should be set by the Web Interface development team as default and should also help many current environments.


Written by Guest on 2009-07-20 16:52:52
In the new WI version, the "Refresh" icon/button is not enabled by default...that is one of my pet peeves. I think it should be available by default as well...great feature when you're publishing apps and need to ping the XML Broker for any new apps on the fly.l

Keep it coming!
Written by andrewin on 2009-07-21 00:24:22
Thanks Thomas; some of these aren't areas I would have thought about, so it's great to have people pointing out our blindspots. 
BTW the DNS setting in WI by itself won't cause XenApp to return DNS addresses - there is another DNS flag in the farm and server properties that controls whether the DNS flag from WI is honoured. So we flipped the default in WI to essentially take it out of the picture. 
I must admit I keep getting caught out by the missing Refresh link too - not sure why it was removed. 
AndrewI (WI architect)

Keep it coming!
Written by Thomas Koetzing on 2009-07-21 09:12:09
Hi Andrew  
>DNS flag in the farm and server properties  
That's the one I was talking about ;-) 
>missing Refresh link too - not sure why  
>it was removed.  
It's not removed but disabled by default and many don't realize that it can be simply enabled.  

Java Defaults
Written by Andrew on 2009-07-21 18:28:57
I disagree with your Java client recommendation to include drive mapping and clipboard by default. The Java client is more often used in highly secured external access scenarios or from untrusted external PC's (Internet cafes etc). Sure you can control via Citrix policy but more often than not Java connections do not use these features for security purposes. When connecting from external trusted (or at least user's home PC's) then the client is more likely to be a Win32 variant, not Java. Also, you CAN transfer files (up to about 2mb in size) using just the clipboard mapping feature, not just text as you mention. This is commonly overlooked and clipboard mapping is seen as 'safe' which is incorrect. 

Java Defaults
Written by Thomas Koetzing on 2009-07-21 18:27:50
Default should be for MOST customers and HIGH security as you say is probably only 5-20% of those who are using the Java Client and have an issue with the clipboard.  
Most custmer just want to have a working clientless access and restrict things with the Citrix policy whitch makes things more flexible.

Something else: AGWISO
Written by IgnasR on 2009-07-22 17:23:28
Why is the AGWISO code not part of the standard WI code? The WI and CAG are both products from Citrix for some time now, you would expect that SSO from the CAG to the WI is a common scenario that would be supported by default

Something else: AGWISO - Use AG 4.6!!!
Written by Thomas Koetzing on 2009-07-22 17:59:22
>Why is the AGWISO code not  
>part of the standard WI code? 
Since AG Version 4.6 NO code change is needed anymore!!! 
So it is supported by default.

Default ICA settings
Written by Guest on 2009-07-24 03:39:01
Some template ICA file settings would benefit from review too. One in particular that has hurt me is the ProxyUseFQDN setting tha gets reset to off when you do a Web Interface upgrade. 
Why wouldn't you always leave it ON ?

Default ICA settings
Written by Thomas Koetzing on 2009-07-24 09:58:50
>Why wouldn't you always leave it ON ? 
Because it manly depends on how a proxy server is configured. Most custerms can work with "off" and only some require "on". Somethimes it can be both at the same time and tricky to do with WI, read more

Written by Francesco Dipietromaria on 2009-08-25 13:32:43
Since XenApp Plugin version 11 the behaviour of the ProxyUSEFQDN has changed: please have a look at [#177622] 
Francesco Dipietromaria

PS 4 and PS4.5 - WI and Access gateway
Written by Guest on 2010-02-01 08:41:56
I found this article very helpfull but could someone shed some light on: 
If i have 2 PS4 servers added as STA in my Gatway Applince and have ONLY 4.5 servers in WI>ManageServerFarm>ServerList(failover order), it doesnt connect user session if the published resource is on PS4 server. It works fine if the published resource is on 4.5 server. STA and Farm management servers are NOT ZDC. I have tried adding 4.5 servers as STAs to access gateway but it doesnt work at all after making this change. WI is running 5.1.1. 
Any ideas will be highly appreciated. 

PS 4 and PS4.5 - WI and Access gateway
Written by Thomas Koetzing on 2010-02-01 08:49:28
Ask questions not related to the article in the forum, thanks.

Thank you
Written by Guest on 2012-07-09 01:43:22
Thank you for writing this clearly as this issue helped us resolve the problems that we had with the slow launch of applications. This was really helpful and we are able to launch it quicker. It would have been nice if we would upgrade the WI to latest version and not holding onto 4.6 version. But, unfortunately, that is not going to happen any soon.

Written by Guest on 2012-11-08 06:46:41

Written by Thomas Koetzing on 2012-11-08 06:52:59
You disagree just because there is a Citrix article out that has been written after I posted this? 
The core Citrix Architect for WI at that time Andrew comment on this article and for many it solved issues with Web Interface. I write things because of my experience from the field. 
If you prefere Citrix article written by who knows than it's your right to do so.

NOTE  You have to register in the Forum to post comments with your name.

Write Comment
BBCode:Web AddressEmail AddressBold TextItalic TextUnderlined TextQuoteCodeOpen ListList ItemClose List

Code Verification
CAPTCHA Security Code Security Code *

find or follow me @