Hi, We moved to using web interface when we migrated from Windows XP to PS3 then PS4.0 so consider myself "new" to web interface although we have been using this as our preferred method of deploying new applications. I have followed the guides from Toms site which gave me some nice "easy" tips on how to customize my web interface to give it a more corporate feel but still feel we could do more to make it unique and not just out-of-the-box with a different logo etc. My experience is Windows server, Terminal server and Citrix but not web development (as i assume lots of admins are) so find it hard to make changes other than posted on these sites to improve the look of W.I 4.0. What would be nice to have is a tool that basically links into the key area's of the W.I - The messages, The web page backgrounds, the titles, the log off screens etc for the people who are not web developers. Also, In the new W.I is there a better support for colours - i want to be able to change the icons for applications to much nicer icons but due to limited colour pallet supported by the W.I things just look dull - but atleast work. On the customising front - is there anything that must be kept on a screen to comply with copyright - an example of this is on the www.jasonconger.com site where i would like to apply the ICA client logo tip and replace the Citrix logo with our corporate logo. I'm really looking forward to the future developments of Citrix - Web interface, PSx and am so glad a site like this has arrived.....

We've made some improvements in this area for WI 4.5 (see http://www.thomaskoetzing.de/index.php?option=com_content for a quick preview), but nothing earth-shattering I'm afraid. However, we are actively thinking about how to make WI more easily rebrandable - it will inevitably be more of a long-term effort to make significant improvements, but we are acutely aware that nearly every customer wants to do this. Of course the fact that the majority have modest web skills makes it that much more challenging for us. The other fact that our HTML generating technology is, umm, a little closer to the 1990's than 2006 shall we say, doesn't help us out much either. We are looking at various web app frameworks that might help with this, btw. However we are constrained more than people may realize because we have to support non-Windows web servers as well as IIS, and we're currently not able to do that by having separate codebases for IIS and JSP environments.

Suggestions or recommendations are welcome!

Cheers,
AndrewI

Andrew I was drawn to your comment "However we are constrained more than people may realize because we have to support non-Windows web servers as well as IIS, and we're currently not able to do that by having separate codebases for IIS and JSP environments. " How much thought has gone into researching the need to support multiple platforms, and how big a cost is it to you in not being able to advance the product as far/fast as you want by taking this position. It's a pretty safe bet that the vast majority of your customers are Wintel shops, have you ever asked them what them want the most, a more functional more resiliant WI server or the choice of deploying on a non-windows platform? I wouln't be asking if I wasn't willing to offer an opinion, and for me the answer is very clear. Given a choice between flexibility of platform and a better WI, functionality wins every time.

Hi Simon,

As it happens, I was discussing exactly this issue a couple of days ago with our product manager and the WI team! Not for the first time though: it has come up probably at least once a year for as long as I can remember - we would love to not have to support two distinct web platforms, but we can't drop JSP. Although numerically not many CPS customers use the JSP version, those who do tend to be some of our largest customers - if we look at the number of CPS end users being served, JSP is bigger than you might think. Also a significant percentage of customers are still telling us that Windows (or sometimes more specifically IIS) is not permitted in their DMZ.

So for the foreseeable future, we need to have a non-Windows web platform support story, and given the web platforms these customers use that means JSP. That said, we are looking intently at how we can take better advantage of modern web app frameworks and the like to improve our productivity, and minimize the burden of supporting multiple platforms.

The winds seem to be in our favour at the moment, and it looks like we have an opportunity in the coming year to make significant changes in this respect. As I touched on in one of my other posts, usability concerns have recently been coming more to the foreground in Citrix, and we are looking to invest as much as we can in improving and updating the UI design of Web Interface with a usability-driven design process. I plan to talk a lot more about this over the coming months.

Cheers,
AndrewI

Hi Andrew, What are your thoughts on the performance of WI4.5 within a virtual machine - does it make the grade or should it be avoided? Thanks. ~Andy.

Hi Andy,

WI works fine in VMs as it is a rare installation that will come close to stressing even low spec servers. Our internal scalability tests show that WI typically can process something like 80,000 simulated user sessions per hour on ordinary hardware. (A session consists of a user logging in, launching two apps and logging out.) This is good enough to cope with the "9am" scenario in all but the largest farms.

Ron Oglesby recommended hosting WI on VMs for several reasons - this interview podcast is well worth listening to since Ron has lots of experience with VMs (http://www.brianmadden.com/content/content.asp?id=579).

Cheers,
AndrewI

Hi Andrews, Extentrix has introduced web services for CPS (http://www.extentrix.com/web%20services/). Extentrix Web Services for Citrix Presentation Server provides a suite of web services APIs that allows developers for the first time to integrate Citrix published applications into their products and portals. It enables users to access Citrix application delivery platform by invoking an open standard web services API. To demo its power, we have integrated the WI with Extentrix Web Services to enumerate and launch the applications. There is a white paper posted on DABCC.com http://www.dabcc.com/downloadfile.aspx?id=365 that explains the steps to do the integrations. To testdrive the product, please click on: http://www.extentrix.com/Web%20Services/Test%20Drive.htm?id=6 Thanks, Alaa

Not sure if it's been mentioned but my #1 wish for the web interface is to overcome firewall and port issues with the basic product so that the HTTP protocol is used if nothing else works. Also, the Java interface should be the bee's knees in functionality, matching or exceeding that of the ICA client. On the subjet of the ICA client - Citrix PS itself is a lovely product. The PN always lets it down. How it can have reached v10 and still keep creating bugs is embarassing. Cheers, Rob.

Hi Andrew, We have been using WI since WinFrame/MetaFrame time. For the new version of WI, version 4.6, it is great, it does what it advertised. However, I have some wish list that is more focus on HA and failover area. We use WI as a core product to deliver CPS published apps and desktops. We are also about to turn all thin clients to use WI in stead of direct ICA connection to CPS so we can utilize "smooth roaming" on thin clients. With that, I am afread of WI because it does not focus much on HA and failover. Why? WI servers can be in a NLB cluster and it works great. However, I can only specify ONE CSG server in the configuration. Why can't WI have more than 1 CSG configured? If not for load balancing, can we configure another CSG just for failover? One or single is not a good word for enterprise infrastructure. Please, I don't like to use Netscaler if possible Other than that, I am a happy user of WI/CSG. Thanks. Jamie Lin

Hi Rob,

Our research group built a prototype ICA client some years ago that used HTTP to communicate with CPS. If I remember right, they found that it added quite a bit of latency though - web servers aren't designed to proxy semi real time traffic.

Avoiding extra ports is the main reason we chose the HTTPS port by default for running ICA inside SSL. The Java client has served us pretty well over the years. While we feel we more or less reached the limits of what we could sensibly do with Java applets (before reaching the point of diminishing returns that is), .NET should be a good platform to build a next generation client for Windows.

Interestingly the Java client was used as the basis for an experimental .NET client port when .NET first came out. Unfortunately performance wasn't very good, because the original .NET runtime wasn't optimized for the kind of drawing the ICA client does. Probably it offers better low-level graphics methods now; I don't know if we've tried yet. With the likely emergence of Silverlight as a viable cross-platform environment though, this will become quite an interesting direction to explore further.

Cheers,
AndrewI

Hi Jamie,

For CSG load balancing and redundancy, the idea is that all the servers should share the same DNS name (and server certificate), and either rely on DNS round-robin techniques to share load, or use NLB to provide LB and quick failover. I haven't tested it myself, but I can't see any reason why NLB shouldn't work with CSG. I appreciate that AG and Netscaler aren't attractive for everyone, but the enterprise edition of AG has built-in HA capabilities, and NetScaler offers GSLB (global server LB) as another means of directing connections to multiple gateways.

Cheers,
AndrewI

Great improvements with WI 4.6, but there are few things that still annoy me. With each new version (4.2, 4.5, 4.6) the name of the default ICA client keeps changing. In 4.5 it was ica32pkg.msi and in 4.6 it is ica32web.msi. I understand that the differences between ica32pkg.msi and ica32web.msi is simply what is selected as the default. That's great and all, but I still need to modify the package. Be having to rename the package to ica32pkg to create and administrative build (then rename back) I've gained nothing (but a few extra steps) over the old way of deploying the client (ica32pkg.msi). This includes the client size foot print. It is identical to the ica32pkg.msi. What really was a big issue was the ica32pkg.msi to ica32web.msi change was not documented or included the release notes. Joe

Hi Joe,

I agree, the change to a new web client for CPS 4.5 didn't really work out as well as I would have liked.

A bit of history: prior to 4.5 we offered several .exe installers and a .cab package for providing a "web" client download. The .exe versions could be download by clicking on an explicit link in WI, and used for the auto-install/update feature (using ActiveX mechanisms in IE). The web client(s) had reduced levels of functionality, according to the package that was used, and were relatively compact (certainly compared to ica32web.msi).

For 4.5 though we wanted an ICA install package that didn't need admin privileges to install the basic ICA client. We also wanted to reduce the number of different install packages we offer, since it obviously increases the engineering (especially test) costs to have so many. This lead to a decision to standardize on MSI as the primary installer technology. Originally we only planned to have ica32pkg.msi, but late on (too near WI 4.5 release to make the change) it was realized that this package wasn't suitable to offer from Web Interface because it tried to install components that weren't needed with WI and would confuse users by asking many irrelevant questions.

Thus the ica32web.msi variant was created to improve the usability (or rather recover most of the usability losses suffered by moving away from the older web clients). However, as a variant of ica32pkg.msi, the web msi needed to still include the other components so that it could upgrade them when installing from an older version of ica32pkg.msi. Then with Feature Pack 1 we added Vista support and changed ica32web.msi into a distinct package which is no longer a customized variant of ica32pkg.msi. I don't know the full details of exactly how it is different, but it still contains the other client components for upgrade purposes.

BTW, the main reason the client install packages are larger now is that they are multilingual or MUI - that is, they contain all of the localizations provided by Citrix, which now covers 6 languages.

Cheers,
AndrewI

AndrewI,

We have been using WI for a few years now and it is the CORE way that all our users connect internally and externally (approx 7000).

The version we have customised it quite a lot to meet the requirements of our Marketing Department. The issue we have is that we are on V4.2 and Citrix, even though you state you can migrate the "settings" you do not offer any method for upgrading the customisation. This is something I raised at the KTE event in Edinburgh last year and at a one-to-one at iForum. But heard nothing back. I'll be raising it again this year Even our TAM has come up against a brick wall.....

Can you please advise how we get our customisation from V4.2 to V5?

Stuart