I think the concept is great, but the downfall to the feature is using DCOM for communication which becomes cumbersome in the enterprise. For instance when WI exists in the DMZ and CPS are located on the internal network many security/network teams will not allow the DCOM communication crossing the FW. If the feature doesn?t get dropped then maybe a web service or leveraging the existing XML Service architecture for pushing the configuration to IMA would do the trick.

Hi Peter, To clarify, DCOM is only used for communication from the AMC management console to the WI Configuration Manager DCOM server on Presentation Server. WI itself uses the XML service to fetch its configuration. Assuming WI is configured from the same place as CPS, there is no need to allow DCOM through the firewall. DMZ deployments of WI are something of a special case anyway; the usual feedback we receive is that local configuration is preferred so that the customer's security team can ensure changes are made in a controlled way. The other scenario in which central configuration has a special role is in providing GUI configuration support for the JSP version of WI. Today, customers that choose to run the JSP version would either need to use central configuration or rely on the export function in the AMC and then manually update webinterface.conf in their WAR file. If we did remove central configuration, one possibility is to give the AMC a "Create WAR file" task analogous to Create Site. Cheers, AndrewI

Al The whole push to centralise more and more of the Presentation Server environment is immensely valuable to me and I'm a strong advocate of this capability in WI 4.0. A single point of control provides the greatest assurance of consistancy across multiple servers as well as reducing the effort and time required to make changes across multiple servers. In my opinion dropping support for centralised management would be a significant disappointment. Regards Simon Bramfitt

Hi Simon, That's useful feedback - thanks. Out of interest, does the existing central configuration capability do everything you need or are there gaps you would like to see filled? Also, given that WI's AMC extension only handles configuration (no management or monitoring functions), would it be as effective if we changed to have a central deployment mechanism instead? This is something MSAM (n?e NFuse Elite) offered, and it is starting to make its way into the Windows platform through the Solution deployment capability in the latest Windows SharePoint Services add-on. If we went in this direction, it would be akin to the existing WAR file model for JSP - you would create a self-contained bundle that had the configuration data, rebranded images, customized web pages etc. This would then be rolled out to the web servers in a controlled way from a central point. Cheers, AndrewI

I was just about to respond saying although in principal the centralized configuration piece of WI4 it sounds good, I have yet to find an installation where the customer didn't want a little more customization than was available out of the box (when you offer it of course). With that said, I love your idea andrewi to "package and push" the configuration, images, content, etc. down to the web servers from a central source. That solves my biggest issue with the current implementation (limited scope) and helps me better keep things consistent between my front-end servers. It really needs to be all inclusive though. Andrew

In its actual form, central configuration makes no sense for most of our customers, because they all customize their WI installations more, than the GUI allows. That means, they have to keep in sync a lot more files as the central configuration can handle. If you could enhance it as you described in your last comment "package and push" this would be a great thing and would be used much more often. Regards Ecki

Hi Ecki, Thanks for the feedback - that fits with the majority view we've heard so far from customers (we are still asking around though). Our current thinking is that we will likely leave the central config capability in the product for a while longer (eg. a year or two), but deprecate it (reduce testing, and recommend customers not use it unless they really need it). We haven't got round to doing any detailed planning on how the "package and push" replacement would work though. The package part is simple enough but I expect many customers will have strong views on what push mechanism(s) would be suitable, and even whether they want us to supply one or use a variety of existing ones. I noted in a previous comment that Windows SharePoint Services supports distributing packages across a farm of web front end servers, but I strongly suspect most customers would balk at the suggestion they install WSS to get this (have a look at the requirements for using WSS and you'll see what I mean: http://technet2.microsoft.com/windowsserver/WSS/en/library/2acc2326-d2c6-4dea-aae8-212d83daeece1033.mspx). Cheers, AndrewI PS. Your bilingual blog is pretty slick.

AndrewI, I work in our Consulting group, so I have the lovely privilege of implementing WI for hundreds of our customers. And these are typically large to complex environments where the centralized configuration would *really* have come in handy - however, it never does with its current feature set. We always go with local configs because no one just wants the stuff in webinterface.conf. I would say 95% of the implementations always want a bit more - whether that be an image, custom aspx file, etc. So this feature always falls short. WSS is not going to fly. Please stay away from that if you can. I really think you should drop the feature or go after it and do it right - because it is pretty useless to be honest right now. The package and push architecture is the way to go...I think everyone knows what needs to be done - now its just a matter of execution. The trick will be finding the "acceptable" way to push/deploy the configured WI site to all the other (unconfigured) WI sites in the enterprise. Cheers, Nick.

Hello Andrew, When WI 4.0 first came out it require the use of the new Access Suite Console. At that time, the ASC was the most horrific and most unusable console so it was much easier to modify the WebInterface.conf file by hand. In fact, many of the options where only available by modifying the WebInferface.conf by hand. Granted WI 4.5 and the AMC 4.5 have come a looong ways in rectifying this. What would be nice, is the ability to modify a local config via the AMC from another machine. Eliminating the need for installing the AMC on the WebInterface server itself. Also, being a consultant. It's easy for me to have a pre-configured WebInterface.conf file for WI, PNAgent and MCM that I can use as part of my automation scripts.

hi, i have 2 persentation server and 1 web interface. The web interface is in DMZ. inside the lan a user can able to login and open the applications, but outside the lan, the user can able to login, but can't open the application. got error ' Citrix Server can be found for the specified network address'

Hi, I'm a Citrix consultant, Citrix advocate, and consumer of Citrix technologies. I'm also a frequent visitor and poster on brianmadden.com and constantly see people struggling to setup and customize the WI and make it fault tolerant. There is a lot of confusion about the purpose of centralized configuration, site grouping, MSNLB, and how these technologies can be combined to achieve load balancing and fault tolerance. There is also confusion about backup URLs for PNAgent and how to configure that feature properly. The WI 4.6 Admin Guide glosses over these topics but doesn't go into enough detail to actually set them up properly. Unfortunately, centralized configuration and site grouping falls far short of providing true load balancing of sites and shared configuration. It's just as simple to copy the webinterface.conf file and tweak it as invariably, clients want their WI branded or tweaked. I personally clone the entire WI server (use a VM) and use DDNS failover combined with intelligent round robin DNS (removal of dead hosts) to make WI load balanced and redundant, which is far more simple and reliable. Regarding the setup of WI and CSG, Citrix did a good job with CAE 2.0 of making the process simple. CAE's wizard driven configuration process should be reworked to make the config of WI and CSG simpler for CPS 4.x admins too. Have one of your developers do a search of Brian Madden Forums for CSG to get a sense of how much grief this causes. Finally, Citrix really needs to work on making branding and customization of the web interface simpler. With each new release, the files that need to get tweaked for branding and customization get renamed or depricated and it's like starting from scratch every time. Customizations like hiding icons, auto-launching applications, changing the skin of the interface, hiding Advanced Options, etc should be built into the AMC. A method of skinning the website similar to Wordpress templates would be invaluable and a huge time saver. Sorry for the rant Like I said off the top, I'm a Citrix consultant and advocate and I mention these gripes because I'm passionate about Citrix technologies and relish any opportunity to make people's experience with them easier. Cheers, Alan Osborne President VCIT Consulting web: http://www.vcit.ca blog: http://www.remote-desktop.ca