How Web Interface 4.0 uses the Centralized Configuration Service

By now many have migrated to Presentation Server 4.0 (PS4)/Web Interface 4.

By now many have migrated to Presentation Server 4.0 (PS4)/Web Interface 4.0 (WI4) and are becoming familiar with the Access Suite Console (ASC). Along the same lines, many are familiar with how to run the "create site" wizard in the ASC to create a WI site. However, what’s going on behind the scenes with some of the options you’re presented with and so used to clicking through? This article takes a look at what the Centralized Configuration Service is and how it interacts with Web Interface.

What is the Centralized Configuration Service?

Prior to Web Interface 4.0, all of the configuration settings for a WI server were stored in a text file on the web server called "webinterface.conf." In WI4, Citrix introduced the option of storing WI configuration settings in the IMA data store instead of locally on each WI server. This option, seen in the "create site" wizard in the ASC, gives you the option to "Use local configuration file(s)" or "Use centralized configuration."

The "use local configuration file(s)" option refers to the traditional configuration method of storing a webinterface.conf file on each WI server. The "centralized configuration" alternative is the new option the WI servers’ settings are stored in the Presentation Server farm’s data store.

If you choose to use the centralized configuration, the Configuration Service comes into play. The Configuration Service is a DCOM application installed by default with PS4 on your PS4 server. (Note that this is a DCOM application, not a service which appears on your Windows server in Computer Management.) Each time the WI server boots, WI contacts this DCOM application on the PS4 server to communicate with the data store. Settings are retrieved from the data store using the configuration service/DCOM application and communicated back to the WI server. The configuration service is also invoked when changes made in the ASC to the site need to be communicated to the data store. You can read about the details of the DCOM application in Jay Tomlin’s Web Interface 4.0 Troubleshooter’s Guide.

Regardless of which configuration source you use, you still manage the configuration of your WI servers and sites via the ASC. The only change is where the settings are saved when you click the ‘apply’ button.

Understanding the bootstrap.conf File

Since WI4 can store its configuration locally or centrally, there has to be some way for the WI server to know which option it should use when it starts up. Citrix accomplishes this with a file called "bootstrap.conf."

The bootstrap.conf file is a simple text file that exists on every WI4 server regardless of its configuration source. Upon startup, WI checks the bootstrap.conf file. If it finds this line ConfigurationSourceType=ConfigurationService, the server contacts the configuration service running on a PS4 server (specified during the site creation and also written to the bootstrap.conf file) to retrieve configuration information from the data store. On the other hand, the line ConfigurationSourceType=Local tells the WI server to retrieve configuration information from the local webinterface.conf file.

Another important concept when thinking about the configuration service is that one single IMA data store can contain configuration information for multiple WI sites. To distinguish between sites, every Citrix WI site is granted a unique Site ID that's composed of the site path, name, and a 512-bit key. This Site ID is stored in both the bootstrap.conf file and the data store, so the WI server is able to request the configuration details about the proper site when it contacts the central configuration service.

Which method is best, local or centralized?

The centralized configuration option sounds good in theory, but it comes with practical limitations. The implementation is not that straightforward, and you usually need to play around with the DCOM application and its permissions to get it all working properly.

Once it’s working, the main drawback is that the centralized configuration option only manages the configuration information normally found in the webinterface.conf file—it does not handle any other configuration data stored locally on the WI server. For example, language files, the customized ICA client packages, and the actual ASPX web pages and their associated images are all still all stored locally and not managed using central configuration. Even when using the centralized configuration service you would still need to copy these files out to each WI server whenever a change is made. If you’re copying all of these files anyway, how hard is it to also copy the webinterface.conf file?

The centralized configuration service has potential in the future if it could become all-encompassing, but for now it’s easiest to avoid introduing a new complexity and work with webinterface.conf files locally on each server.


Web Interface 4.0 Troubleshooter’s Guide – Jay Tomlin
How to Load Balance two Citrix Web Interface Servers – Brian Madden
A First Look at Citrix Web Interface 4.0 –Thomas Koetzing
Citrix Web Interface Administrator’s Guide

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Katie, a nice and clear article. Specially the part of the bootstrap is helpfull for those who initially said to use a the centrally configuration files instead of locally. By modifying this manually you can fool the wizzard. I once had the WI wrongly configured and it took me a bit of a strugle to get it back to local configuration files.
Thank you for your feedback, mutsje.
What happens when you reboot a WI server and the data store is not a centralized environment?  Will the WI site be unavailable until the data store can be contacted?
If the data store is not available.....neither are your published applications. Web Interface would not work.
This article clears up the whole concept.
I think it is business as usual in using the local files on each web interface.
Citrix will get it right the next version I am sure.
Thanks for your comments. 

If the data store is not available.....neither are your published applications. Web Interface would not work.

Just to clarify things, if you lost your data store your published applications would still be available as your Presentation Servers would use thier Local Host Cache (LHC).  As to whether you could access application via a WI site configured to use the configuration service, this is a great question.  I don't know the answer, I will have to get back to you. Thanks for bringing up a great point!
Article is very helpful for me specially for the bootstrap.conf and the dcom stuff.
thx and keep on the good work.
Bjorn Bats
The netherlands
Thanks Bjorn. I appreciate the feedback.
I hope all is well in the Netherlands!
Excellent - has probably saved me a few hours finding out more about this ( and a few more trying to find it in the first place.
I'm sort of assuming that this really comes into its own when you don't carry out any customisation and you want to load balance WI servers (although I realise that this is a whole article in its own right).
Below, Jay Tomlin responds to mutsje's original question, "What happens when you reboot a WI server and the data store is not a centralized environment?  Will the WI site be unavailable until the data store can be contacted?".
From Jay Tomlin:

The data store is not needed, but Config Manager process is.
When using remote configuration, the configuration data is not cached on the WI server anywhere. (One of the requirements for WI 4.0 was to be able to run on a locked-down web server where drive access is read-only.)
Configuration data is drawn from the data store on first request by the Confguration Manager, an executable that runs on CPS 4.0 and higher. The Configuration Manager process caches a copy of the WI configuration, so temporary outages of the data store do not affect the availability of WI.
If the data store goes down and WI is restarted, but CPS remains online, then WI will be able to obtain its configuration from the cached copy held by the configuration manager. However, if the data store goes offline, then the configuration manager process is terminated, and then WI is restarted, then WI will not be able to get its configuration data from that CPS server.
Backup URLs for the configuration service help to mitigate the risk of a Configuration Server being unavailable when WI needs to download its config.
Good article, thanks a lot Katie.


 I'm very new to Citrix so I any assistance would be greatly appreciated.

My issue:

I have 2 WI 4.2 servers that use Centralized WI configuration stored on a SQL 2005 backend. 

Our remote users are required to access published application by first connecting to a portal on Juniper's SSL VPN.  Juniper requires that I change the AddressResolutionType field from IPv4 to DNS due to a limitation on Juniper's side.  Right now, my remote users are not able to access the published applications on CITRIX via this Juniper SLL VPN site.

Since the 2 WI 4.2 servers are load balanced, I have not found a way to change the AddressResolutionType field.  I renamed the Webinterface.conf.default to Webinterface.conf and set the AddressResolutionType to =DNS.  The default had the rem symbol #AddressResolutionType=IPv4.  I made this change on both servers' Webinterface.conf files.  I rebooted both servers but to no avail.

Reading one of the articles, I found the bootsrap.conf file which points to ConfigurationSourceType=ConfigurationService. 

IF I change this field to point to Local would it have any adverse affect?

Will the 2 WI servers use their local Webinterface.conf upon booting rather than the centralized database? 

Do I have to enable all the other # remmed fields or can I leave those with their defaul values and just change AddressResolutionType=dns as I have already done in the servers' local webinterface.conf files?

Thanks in advance.