DABCC will be hosting a webinar Nov 4, 2009 on Web Interface customization leveraging Extentrix Web Optimizer ... details here: http://www.dabcc.com/media.aspx?id=647

You can register through the above link. Key topics covered:

– Make your Web Interface "look and feel" consistent with your corporate and intranet web sites
– Quickly add custom graphics and themes
– Simple and easy to use interface and available quick start templates get you up and running quickly
– Unrivaled support for mobile devices

Over the last couple of months there has been lots of communication around the XenApp 5 FP2 release.

One of the components of XenApp that was updated with FP2 which hasen't received much publicity is the Web Interface 5.2 update.

I would like to take sometime to share with you what is new in this release.

For those of you who haven't had a chance to review the new features, see the list below, then watch my video for an overview of each feature and basic use case.

New features in Web Interface 5.2

• XenApp VM Hosted Apps
• XenDesktop User Roaming
• Disaster Recovery
• New Management Console
• Secure Ticket Authority Redundancy

David
Twitter - http://twitter.com/citrixreadiness
Citrix Support on Facebook - http://www.facebook.com/citrixsupport

This is an interview with Andrew Innes.  Andrew is the Platform Architect for user interaction components of XenApp and XenDesktop, notably Web Interface and the desktop integration clients.  His job entails finding creative ways to improve the usability and security of these products, and helping strike the right balance between them.

Here is Andrew:

 Q: Andrew, what are the security issues Citrix Admins should be aware of with Web Interface?
A: Hi Kate.  There are two main categories of issues admins need to think about: security of the web server itself and security of the whole XenApp or XenDesktop delivery system.  For the web server itself, there are all the standard hardening rules to follow, especially if it is facing the Internet - I won't try to summarize these here.  The aim is to prevent intrusions into the web server itself or the network behind it.

It's worth mentioning though that Web Interface has undergone probably hundreds of evaluations in customer environments as well as regular security audits within Citrix as part of our secure development process.  It has been engineered with all the known web application threats in mind, and we track 'webappsec' developments closely to build in defenses against new styles of attack as they emerge. 

Hardening the web server itself is the #1 recommended best practice for everyone.  Some customers will still want to employ extra measures, such as a web app firewall or other monitoring systems to spot potential attacks.  NetScaler can easily be configured to provide web app firewall, SSL and detailed logs.

For the Citrix specific aspects of security, the admin should start by understanding the business reason for publishing resources (apps, desktops, documents etc) via the web, and the appropriate policies on access rights and restrictions.  These feed into the design requirements for the delivery system, including the configuration of Web Interface.  The aim here is primarily to ensure authorized users are allowed access in the intended way while unauthorized users are denied access, and that policies are not circumvented.
Web Interface has a brokering role in the delivery system, making it an effective place to enforce certain policies, for instance ensuring strong authentication happens before access is granted.  It can be augmented with Citrix Access Gateway to scan end point devices to make fine-grained access decisions; in this case Web Interface plays a supporting role in upholding those policy mechanisms.  It also implements a number of sensitive features, like password change and password reset, which can be enabled when the usability gains outweigh the security considerations.

Q: What are the prescribed security precautions Citrix Admins should use with WI?
A:  There are a few standard precautions we recommend all customers follow:
   -      Require SSL on the Web Interface server; this protects user credentials in transit and helps prevent spoofing attacks (like those that could result from the recent DNS vulnerabilities). 
   -    Use SSL or IPSec for requests to the XML service on XenApp or XenDesktop; again this protects credentials.
   -      Follow best practices for web server administration; this protects against accidental or malicious reconfiguration.
   -      Disabling the HTTP port, or having it redirect to the HTTPS port can be helpful.  Then to prevent potential phishing attacks (MITM against the HTTP connection that redirects to a replicated WI site) the Internet Option setting "Websites in less privileged web content zone can navigate into this zone" should be disabled.

Where possible, we encourage customers to consider using the Kerberos or smart card support in XenApp which avoids the need to send passwords at all.

Q: Do you have any Knowledge Base articles to reference that might be of help?
A:  There is a collection of technotes for Web Interface which cover useful points, but my favorite reference is the Troubleshooter's Guide for Web Interface.

As promised in the TechTalk "Learn What's New in Citrix XenApp 5 to Address Your Windows Application Delivery Needs", I am posting the link to the power point and summarizing the attendee Q&A.

XenApp 5 Upgrade/Migration Q&A

Q: What is the upgrade path from PS 4 or PS 4.5 to XenApp 5?

A: Please see the migration guide for moving from PS 4 or PS 4.5 to XenApp 5. Also view the webinar on best practices to upgrading/migrating to XenApp 5.

Application Streaming Q&A

Q: I still don't understand the difference between publishing an app and streaming an app.

A: Streaming puts the application on the target device like the server or the client. It's merle y a delivery method. Publishing is how an administrator controls which applications are available to what users and how. When publishing an application you can choose how the user gets access to that application - it can be either streamed to the user's end point (desktop/laptop) or streamed to the server and accessed using the XenApp hosted client. So streaming is a delivery vehicle, publishing is delivery control.

Q: Can you describe the application profiling process for those of us that are unfamiliar with it?

A: You simply run the profiler, follow the instructions, and install the application. It's actually pretty simple.

Q: Is there a document on the web to research how to setup a streaming application in XenApp to test it and "play"?

A: The Streaming admin guide is actually very well written for this purpose.

Q: Is 4.5 application isolation the same as in 5.0?

A: It is actually very different. We added new features in 5.0 like inter-isolation communication and also made significant application compatibility enhancements.

Q: Does the application profiler capture windows services?

A: Not yet.

Q: So would streaming improve the performance of apps in a limited bandwidth environment?

A: ICA is the thinnest way of delivering client\server applications. You would stream to the server and then remotely display from there to the client. Streaming is best used for applications that need to be used offline such as productivity apps. In this case, streaming simplifies their delivery and management and offload their resource needs from the server to the client. The application would use it's native networking requirements when you stream to the client. Hence, streaming to the client does not improve bandwidth. it improves management, maintenance, and application compatibility. Streaming tot he server does it all.

Q: Do I need to buy the Access Gateway in order for me to be able to stream an app over the WAN?

A: No. Application Streaming is part of XenApp Enterprise & Platinum editions. You can optionally buy the Citrix branch repeater to improve application streaming performance for branch office users.

Q: Does application streaming support isolation of Windows services?

A: Not Available

Web Interface Q&A

Q: Does new Web Interface work with PS 4.5

A: Yes

Q: Can the new Web Interface be used with both XenApp & XenDesktop?

A: Yes. Use Web Interface 5.0.1 that supports both XenApp and XenDesktop

Q: What Platforms does Web Interface 5.x support?

A: It supports both Windows Server 2003 and Windows Server 2008.

Licensing Q&A

Q: Does the license server need to be upgraded when moving from 4.5 to 5?

A: Yes. Remember that the latest LS is backward compatible with previous versions of XenApp

Q: Will I need new licenses for running XenApp 5?

A: The SA Eligibility date for XenApp 5 is August 27th 2008. Hence if your XenApp licenses are current on SA by that date, you should be set.

Q: How can I get a 90-day evaluation license for XenApp5?

A: Please contact a local reseller (find yours at http://www.citrix.com/partners/locator) or you can call 800-4CITRIX. We are also planning on offering a preconfigured Evaluation Virtual Appliance for the Windows Server 2003 platform sometime in Q4.

Q: Can I mix and match XenApp edition licenses? Platinum is cost prohibitive as an existing Advanced customer but I could possibly see a benefit for supporting some of my users with Platinum features

A: Check out my blog on this topic

Q: If you stream an application to a XenApp server and then publish that application as a XenApp hosted application, does that only use one concurrent license or two?

A: It uses one license. Only one CCU license is consumed per client device when accessing hosted XenApp applications.

Q: Do you need a separate license for streaming ?

A: You can use a XenApp Enterprise or Platinum licenses for streaming applications to desktops/laptops or you can purchase additional add on streaming licenses.

XenApp clients Q&A

Q: Any news on making an ICA client for the iPhone?

A: Check this blog for more details

Q: Is PN Agent still available in XenApp 5?

A: Yes. It is called XenApp applications

Q: What is the minimum ICA client version supported by XenApp 5?

A: To avail all the new functionalities, you need to use XenApp hosted client version 11.0 and streamed client version 1.2

Q: I understand that the name has been changed but will Program Neighborhood Agent be still available with XenApp 5?

A: Yes

Misc Q&A

Q: What are the key differences that separate PS 4.5 and XenApp 5?

A: Please see the feature comparison matrix.

Q: Are there any enhancements to terminal server roaming profiles and management of them?

A: Check out our User Profile Manager Tech Preview. It will be released in Q4 2008 for general use.

Q: Have you made improvements to the Resource Manager that was available in Presentation Server? Our company has always had need to query database directly, to cross-reference our own HR and account databases against the network ID trapped by Citrix.

A: The new Resource Manager that was made available in XenApp 5 is built on Citrix EdgeSight technology. It provides better reporting capabilities than previous version.

Q: Is an additional appliance required to implement EasyCall?

A: Yes. EasyCall requires the EasyCall appliance. XenApp includes the user licenses and hence you just need to purchase the appliance for using EasyCall in your XenApp environment.

Q: I've read XenApp 5 has improvements on multi-monitor support. What do these improvements contain?

A: Support for higher resolution similar as Microsoft increased the video buffer on Windows Server 2008 to enable us to support larger video spaces.

Q: Is there a new version of Secure Gateway?

A: Yes. Secure Gateway 3.1

Q: Has the 128-bit encryption option in the ICA protocol been discontinued? We currently require this for some published apps and would prefer not to be forced into an SSL VPN solution.

A: No. It is still available

Q: Does the new Installation Manager work on 64 bit?

A: Yes. It is supported on Windows Server 2008 x32 and x64.

Q: Can we install XenApp in a virtualized environment (XenServer) or it a better practice to install it on physical server?

A: Check out this blog on this topic

Q: Will the WANScaler be out of product line and replaced with WAN optimizer software in each client?

A: The WANScaler client is the new Citrix Accelerator client and can be deployed on laptops and desktops to improve branch office user and roaming user experience.

Q: We use PS 4.5 today with Oracle DB. How will oracle DB be supported in XenApp 5 ?

A: Oracle Database is still supported as a data store option in XenApp 5
 

As promised in the TechTalk, here is the the link to the power point and following is the summarized attendee Q&A.

Web Interface Q&A

Q: Can Web Interface front end both XenApp and XenDesktop?

A: Yes. Use the latest Web Interface 5.0.1 that supports XenApp and XenDesktop

Q: Does the account unlock feature of Web Interface require password manager?

A: Yes

Q: Can you use Web Interface 5.x with PS 4.5?

A: Yes

Q: What are the companies you listed in your presentation that are doing Web Interface customizations

A: www.extentrix.com and www.techstur.com

Q: Web Interface changes are great, but what my users really want is PNAgent support via CSG. When is that going to happen?

A: This is supported with the latest XenApp client and Secure Gateway 3.1

XenApp clients Q&A

Q: Will there be a XenApp client for BlackBerry?

A: Since our Blackberry client partner ROVE suspended support for ICA Client, we are working with a new partner to provide similar support. Stay tuned.

Q: Can you use the new XenApp Plugin with PS 4.5?

A: Yes

XenApp Upgrade/Migration Q&A

Q: Can we upgrade from PS 4.0 to XA 5.0 or do we need to upgrade to PS 4.5 first?

A: You can move directly from PS 4.0 to XA 5.0. For specific details, refer to the upgrade/migration white paper and attend the "Upgrading/Migrating to XenApp 5 TechTalk" as well.

Misc Q&A

Q: What is Citrix Branch Repeater?

Q: Citrix Branch Repeater is an appliance that combines our WAN optimization technology with Windows Branch infrastructure services. Visit the branch repeater page for more information. 

There are literally hundreds of features built into XenApp 5.0. In my opinion, three of the features are critical to success in almost every single XenApp farm. View the embedded presentation below for more info on the three keys to success with XenApp.

(click here to see the presentation in full screen)

Click here for the XenApp Web (aka Web Interface 5.01) Administrator's Guide. You can find the ReadMe here.

Click here to watch a video with one of the developer's of Preferential Load Balancing, Prasanna Padmanabhan (the video covers the beta version). You can listen to an audio interview on PLB here.

Go here to watch a video interview I did with Gary Barton (Citrix Printing developer) at Citrix Synergy.

You can view the schedule for archived and upcoming XenApp 5.0 webinars here.

Summary

This article describes how to run Web Interface 5.0 in a 64-bit Internet Information Services (IIS) process.

Background

This article applies to Citrix Web Interface 5.0 running on Microsoft Internet Information Services (IIS) 6.0 or 7.0 with an appropriate version of Visual J#.NET 2.0 Second Edition on a 64-bit computer.

Web Interface 5.0 is a .NET application that is compiled so that it can be used on both 32-bit and 64-bit versions of ASP.NET. Web Interface makes use of Visual J# and 64-bit support is added by Visual J#.NET 2.0 Second Edition. This allows the Web Interface to run inside a 64-bit IIS process.

The ability to run inside a 64-bit process can prove particularly useful on IIS 6.0, where the entire IIS Web site is either a 32-bit process or a 64-bit process. This makes it easier for the Web Interface to coexist with 64-bit Web applications on the same IIS site.

Procedure to allow the Web Interface to run as a 64-bit process on IIS 7.0

1. Open the Microsoft Management Console (MMC) IIS Manager snap-in on the server running the Web Interface.

2. In the left pane, click Application Pools and, in the Features View, select the application pool that your Web Interface site uses (usually called CitrixWebInterface5.0.xAppPool).

3. In the Actions pane, click Advanced Settings.

4. In the General section, change the Enable 32-Bit Applications setting to False.

To allow the Web Interface to run as a 64-bit process on IIS 6.0

1. When you install the Web Interface, allow the installer to switch IIS to 32-bit mode.

2. To switch IIS back to 64-bit mode and register the 64-bit version of ASP.NET, click Start, click Run, type cmd, and then click OK.

3. From the command prompt, type the following command to disable 32-bit mode:

cscript <systemdrive>\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0

4. Type the following command to install the version of ASP.NET 2.0 and to install the script maps at the IIS root and under:

<systemroot>\Microsoft.NET\Framework64\version\aspnet_regiis.exe -i

where version is the build version number of ASP.NET.

5. Open the MMC IIS Manager snap-in on the server running the Web Interface.

6. Click Web Service Extensions under the server running the Web Interface and ensure that the status of the appropriate ASP.NET version is set to Allowed in the details pane.

• More Information

For more information about ASP.NET on IIS 6.0, see Microsoft Support Article 894435

As part of Synergy Underground project, we interviewed many of the people in the XenApp booth in the TechLab to talk about the different features and components of Citrix XenApp Platinum.

(Each of these videos were shot and streamed live to the Underground site via a Nokia N95 cell phone. The convienience and ability to stream live video directly to the net is the trade off for the lower audio and video quality. Read this post for an explanation of the process and a video on how the live streaming worked.)

Here are three of those video interviews -

Jay Tomlin on Smart Access

David Wagner talks about the new User profile Manager Tech Preview

Victor Thu talks about Easy Call
(low audio in first half)

Wow, I landed here in Houston and got on a cab towards the convention center - I open my laptop and I get a new feed alert, " Silverlight Web Interface Sneak Peek", from Jason's bog.

I'm thinking: "Damn Jason did it again... this kid is on fire!"

He just posted a video preview of his next project, running Web Interface with a Silverlight front-end.

He used the new APIs on WI 4.5 along with AJAX, and Citrix XenApp 4.5.

Check this out:

Keep a close look on JasonConger.com

cheers,

Gus Pinto
Microsoft MVP - Virtualization
Follow Me

Like most techie geeks, our developers like to play with the latest technology and explore what's possible.  Sometimes they even get the chance to do it as part of their job...

Folks who have seen Thomas Koetzing's peek at the upcoming version of the XenApp Web Interface component will be aware that we've made some fairly major changes to the look and feel.  Certainly this is the most significant design uplift since WI (originally known as NFuse) was first released in 1999.  As you can imagine we're really excited by this, and we hope you'll not only like the new sleek look, but find the usability improvements we've made genuinely useful.  It's been in the works for a good long time (getting on for 2 years).

However that isn't what I wanted to highlight just yet (I'm hoping to get the people who were deeply involved in doing the usability work and defining and refining the design to talk about it).  Instead I'd like to show you something else we prototyped late last year, as part of some work to explore new user interface concepts and technologies.  If you follow developments in the web development world at all, you will have heard about Silverlight, the new cross platform browser-base rich internet application framework Microsoft is creating.  Derek Thorslund linked to the blog announcement this week from the Microsoft team busy working on Silverlight 2.0.

From our perspective, this is pretty neat stuff.  Citrix is already a very heavy user of Microsoft technologies, and our UI and Visual design teams have been eagerly following what Microsoft has been doing in building a strong design/code separation into WPF and now Silverlight.  For them, the ability to easily and safely update our product UIs without disrupting the code (oh I don't know, because someone wanted to change the look and names of a few products let's say...) - THAT would be the holy grail for them.

But WPF and Silverlight also offer a great chance to start being more expressive and trying out fresh approaches to UI tasks.  As it happens, WI is the most commonly used interface for people to get access to Citrix delivered apps, so it is a natural one to focus on.  So we let a couple of developers loose with some simple instructions: learn about Silverlight and come up with something that looks cool.  Well, they didn't give us cool: they gave us bling - lots of bling!  Have a look...

If you like that, have a look at this short video clip to get a better sense for what else it can do.  (You'll need the Techsmith codec.)  By the way, something cool that you can't tell from just looking is that it's powered by a new set of web service interfaces we're prototyping, designed to allow custom UIs to be built by all sorts of people (including us).  Actually, they aren't totally new; the first generation shipped inside the Web Interface integration for Microsoft Office SharePoint Server - give that a try if you're using SharePoint, it works with the Windows SharePoint Services component of Windows Server 2003 as well.

Interestingly, our techie guys, along with a lot of other early adopter developers, gave Microsoft some pretty detailed feedback on what was good and what was missing from the early alpha.  With the 1.1 alpha lots of standard UI controls were missing, leaving fairly low-level drawing primitives as the main tool to use, which ironically forced us to be more creative and come up with something that looks really new.  However it's great to see Microsoft is addressing the many gaps in a very major way!  (See Scott Guthrie's post for a lot more detail on what is now going to be the 2.0 version.)

Now, is this really a good user interface?  I don't know - it was a learning exercise, and a nice way to test whether our service interfaces are good ones.  But will we really ever do a Silverlight front-end to XenApp though?  Now that's a very good question....

Would you like us to?

Cheers,
AndrewI

I had a customer ask me and Pete if it is possible to save user session data as cookies? They asked because with cookies users would be able to "save" their preferred domain. For this particular customer, they have the problem where users from many domains are all using one single web interface. Therefore for many of the users, the default domain name that comes up doesn't match their default and can cause user confusion. Even if you fix the problem with a support call, if the user doesn't login frequently, they may forget the simple fix of typing in or selecting your domain name. Enabling cookies to store this data can solve the problem.

Our super cool PM, Al Grandville, got this answer from engineering. You can achieve what you want (remember a user's domain each time they log in) by making a simple customisation to WI. It only works for WI 4.5 and above. We disable the functionality by default for security reasons, but with a code tweak you can turn it back on. Here's what you need to do:

• Find the "login.aspxf" or "LoginASP.cs" file within the WI site (depends on your version). It should be located at (for example) C:\inetpub\wwwroot\Citrix\AccessPlatform\app_data\auth\serverscripts\login.aspxf           -or-C:\inetpub\wwwroot\Citrix\AccessPlatform\app_code\PagesCs\pages\auth\LoginASP.cs
• Open the file in any text editor
• Locate line 513 in the LoginASP.cs file or about line 200 in the login.aspxf file --  this is what we call a "customization point" in WI, which is a portion of code that is highlighted as an area that customers will want to modify. The customization point includes some instructions on how to comment out the existing line of code and replace it with another that will provide the "remember domain" functionality.
• Follow the instructions and save the file to update the site.

Enjoy! Thanks to the Michael Bednarek, Al Grandville and the Web Interface Dev team.

If you haven't already seen this, Thomas Koetzing (one of our CTPs) has reviewed the new WI 5.0 that will be shipped with Delaware. This review is from a private build we sent to the CTPs. Check the review here. For all the others who want to get the new WI, we will have a Delaware release preview in the near future.

So here I sit in my kitchen, connecting to my laptop sitting on my desk at Citrix. I forget sometimes how cool it is to be able to do this. I forget the early days when I never worked from home - because I didn't want to set up my "work machine" as a MetaFrame Server and publish my server. And yes, I'll confess, I still like to install apps locally, just because, well, it's MY computer, right?

Yes, I can log in through Web Interface or other connections and have all my work apps, launch a published browser to get to all my sharepoint sites, and web applications, but it just isn't as homey or comfy to me as knowing I'm on my own computer.

It's funny to see that as I was thinking about writing this post, we had a survey published about the same topic - even though I'm sadly no longer in that age group.

Because who are we kidding - we like working in casual attire (I didn't say PJs). We like snacking on leftovers, and talking to our pets about the latest email we got from our project team.  We like dialing into meetings and walking around the house while making our points.

And yes, I multi-task. I sort laundry while I listen to project meetings, with the phone on mute.  Trust me, it's way better than sitting quietly in a chair at a table with 15 other people waiting for your turn to speak.

So, hooray for remote access! Hooray for GoToMyPC! And hooray for companies that support working from home - I for one, thank you!

I have a clean CPS 4.5 installation and run into a strange problem. When I visit the web interface login page, I would get an internal error has occurred error. The event log shows the following whenever this error occurs.

code: 3008

Event message: A configuration error has occurred.

Event time: 10/9/2007 11:56:07 AM

Event time (UTC): 10/9/2007 3:56:07 PM

Event ID: dc2535769fd24e80bcc65338977a195f

Event sequence: 1

Event occurrence: 1

Event detail code: 0

Application information:

Application domain: /LM/W3SVC/1/ROOT/Citrix/AccessPlatform-1-128364189657368327

Trust level: Full

Application Virtual Path: /Citrix/AccessPlatform

Application Path: c:\inetpub\wwwroot\Citrix\AccessPlatform\

Machine name: RAYVCPS45

Process information:

Process ID: 63876

Process name: w3wp.exe

Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:

Exception type: HttpException

Exception message: Could not load file or assembly Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a or one of its dependencies. The system cannot find the path specified.

Request information:

Request URL: http://10.2.248.112/Citrix/AccessPlatform/auth/login.aspx

Request path: /Citrix/AccessPlatform/auth/login.aspx

User host address: 10.7.83.182

User:

Is authenticated: False

Authentication Type:

Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:

Thread ID: 1

Thread account name: NT AUTHORITY\NETWORK SERVICE

Is impersonating: False

Stack trace: at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled()

at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)

Custom event details:

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I don know why it is happening. But after I performed a repair of .net framework 2.0, the problem went away.

Hope it helps in case someone else runs into the same problem

For the next release of Web Interface we have revamped the way we detect client software and help the user select and if necessary install and enable the most appropriate software for accessing applications.  We call this the Client Detection and Download wizard, or CDD for short.

I've described the problem and our approach before, so I won't rehash that here.  We're now in closedown on the next release that includes CDD, so I wanted to give people a peek at what it looks like in action.

Almost no-one expected CDD to be so much work; I'm told there are something like 50 different screens in total because we wanted to tailor the user assistance to each browser we support, and cope with as many configuration as we can.  Quite possibly it has ended up being too complicated, but it is our first attempt to fully tackle the complexity of coping with a wide range of browser configurations and client combinations whilst striving for high usability.  Also, we made a serious attempt to follow best practice in handling informed consent for installing software - we think that will be increasingly important in making sure our products are perceived as dependable and trustworthy.

As always, let me know if you think we've got it wrong!

On to the screenshots

Initially, nothing looks different when the user hits the login page; behind the scenes a (mostly) silent detection process has taken place to attempt to detect any of the allowed client options.  In my example, only the native ICA client is permitted and was not found to be installed.

If the site had been configured to allow the Java or RDP clients one of them would have been selected automatically, and the warning message would instead have just been an informational message to advise that a better client is available.

If the user simply logs in, he will be advised that client software is needed, because none of the allowed client options could be detected automatically:

Choosing to detect client leads into the primary page of the CDD - an automatic mode designed to help the user select and enable the most useful client from available options with minimum interaction.  The user is offered options to bail out of the process at any time, or simply logout if they don't have time to continue.  The option most likely to help them get their task done is highlighted to make it quick to find, but with the security warning shield immediately under it to help flag that some caution may be needed before proceeding.  More detail is available if the user is unsure what might happen next.

In this case, clicking the recommended Download action will initiate the download and install of the ICA web client for Windows.  Although the web client install process is not as streamlined as we would like (or as previous versions were), it is a multilingual client package that can be installed by users without local admin privileges, and so stands the best chance of being usable whatever the circumstances.

After installation of the web client completes, or is abandoned, the user is prompted to indicate the final outcome because WI cannot reliably detect this, as we'll see.

If the user reports the installation was successful, the CDD wizard then attempts to verify this and ensure the browser is configured to be able to see and use the client (this no longer happens automatically with IE6 SP2 and IE7).  With default IE7 settings, the user will need to allow the installed client to be accessed by web sites by opting-in through the IE Information Bar:

Having navigated through the steps to get a usable client, the user is now shown their list of applications ready to launch.  In my example, we have some streamed applications available as well but the streaming client hasn't been installed, so there is a notification about that. 

There is also a warning that applications might not launch smoothly because of the possibility that browser lockdown settings may block or intercept launch attempts (in ways that WI cannot detect).  The specific reason here is that the WI site is in the Internet security zone and is accessed by https - the normal situation when accessing WI for remote access from arbitrary machines on the internet.  The first point forces WI to rely on downloading a launch.ica file (which might be blocked outright) and the second point means that file downloads might trip on the IE setting "Do not save encrypted pages to disk". In practice neither setting is likely to be an issue, and for the latter the required user action is simply to save and then open the file, so we elected to just have a warning. 

By the way, as an important point of principle, we have deliberately avoided asking (or as our security architect might say "enticing") the user to change any of the browser's security settings unless it is necessary (there is one case where it is necessary).  Instead we try to provide the best possible user experience within the limitations of the actual settings.  In my example, if the WI site had been in Local Intranet or Trusted Sites, then the warning message would not have appeared.  To avoid problems with browser lockdown making file downloads less usable, WI will now use the ICA ActiveX control whenever possible to launch applications - in practice that requires the WI site to be in Local Intranet or Trusted Sites, because of the ICA client's own security policy.

I will point out that one side-effect of using the ActiveX control for lauches is that the old trick of right clicking on launch links in order to save the ICA file no longer works in most cases.  We've been getting a bit of grief on that even from our own support folks who consider it a valuable debugging tool.  There is probably a way to enable it by customizing the WI scripts to detect right click in javascript and have WI switch to ICA file download, but I haven't tried it.

Cheers,
AndrewI

Most people have a fairly well developed ability to assess trust when interacting with other people, which enables them to sense when situations are safe or not and whether to trust what other people say or to be suspicious of their intentions.

Let me give you an example, which perhaps just illustrates how some people (like me) aren't actually that well attuned to the signs.  A couple of months ago, my wife and I agreed to let a double-glazing sales rep visit; we've been thinking we need to replace our windows before long anyway, so when a salesman rang we thought why not get a quote?  (Hey, not everyone's sense of suspicion kicks in right away; I do try not to be cynical.)

So we agree a date and time with the sales guy on the phone, and no-one shows up.  We're a bit irritated, because we changed our plans to wait in. Next week, the phone sales guy rings again, and when confronted apologizes that the rep who was supposed to visit the first time didn't come - he says the rep claims he visited and gave us a quote.  It's impressive how persuasive good phone sales guys can be - he says he will offer us a 60% discount because of it - and after some hesitation we agree to a new time.

This time a rep does show up, and right away apologizes for the other rep not showing first time - and says "he was fired".  (Hmmm.) Anyway, this one seems amiable enough and does the necessary inspection then gets down to the sales pitch.  It is rather drawn out but finally he quotes a rather large number - then my wife points out that the phone sales guy promised us a 60% discount.  The rep manages to look suitably furious and rings the office on his mobile, talks angrily for 10 minutes about how the phone sales guy has done it again and how he will have to honour the discount but it makes him so cross etc, then finishes the call and tells us the phone sales guy "will be demoted this time".

Okay, so if you were in my position, what would you be thinking now?  Is this an honest situation, where circumstances and events should be taken at face value?

We respond sceptically about the price (the one with the 60% discount), and are about to start serving supper.  The rep then quickly rings the office again and comes back with "we've got a job near here in three weeks and could do it that day - I'll give you an extra discount if you decide tonight".  As it happens, I'll be travelling that day so we decline politely and show him out the door. Afterwards, we realize he seems to have forgotten to leave the written quote.  (Surprising, that.)  A quick web search reveals some interesting comments from previous customers about the sales tactics employed by this company, the commission structure for its reps and the quality of their products and work.  Suffice to say, we aren't regretting our decision to pass on the generous offer we were made that night.

My point is that when interacting with another person face to face (or on the phone), we usually have plenty of indicators we can look at to assess how much we should trust the other person, how risky the situation is, whether things are what they seem. "The other rep was fired", "The phone sales guy will be demoted this time" - yes, I wonder whether he would answer today if we ring and ask for Frankie ("like the fish"), sounding as cheerful and matey as ever.

How does this relate to Citrix? Simple: trust is critical to what we do in supporting remote application delivery and how people perceive that, as customers and users.

Trust me, I'm a software developer.  (I've got a compiler and a certificate!)

Trust is an issue in many ways and on many levels - for example, do you trust Citrix to write good products that work as they should and don't pose a risk to your systems?  If so, why do you trust Citrix to do this?  Is it because of how many customers we have, who we have as customers, what customers and third parties say about our products, or because you tested our products in your own environment?  Or maybe you know someone you respect who works at Citrix and that gives you confidence in what we produce?

Already you can see that often there are ways open to you to assess something of the true state of affairs, and so reduce the need to blindly trust us to have written solid products.  But it isn't so easy in every situation.

Right now, I'm wrestling with trust issues that relate to how Web Interface works and how users are or should be involved in making decisions affecting security, especially of their own system.  Most of the key decisions come down to questions of trust.

The core of the problem is that people have very few indicators they can make sense of when visiting a web site on the Internet, to judge accurately whether that site is what they think it is, and whether they are safe visiting it.  The current acute problem with phishing is evidence enough of that.

If that site is Web Interface, one of the first things it does is try to use an ActiveX control - that alone can trigger a warning from the browser these days.  If not found, Web Interface will normally provide a link to a program that must be downloaded and installed to use the site.  If the user elects to do that, they will be faced with a couple of rather cryptic security questions that talk obliquely about trust, but don't really give the user anything useful to go on:

How is an employee of a business partner remotely accessing your system supposed to make an informed and accurate judgement about these questions?  Nothing in either dialog tells the user that the program, if run, will actually try to install something on their computer (unless they know that .msi files are installation packages).  The Web Client for Citrix link just takes the user to the Citrix home page; they would have to really dig to find out what the Web Client actually does.  The publisher link shows them the detailed digital certificate information - barely useful even if you know how to inspect the certificate fields and interpret them.

The business partner employee is implicitly faced with the question "do you trust Citrix to write good products" but without the benefit of the types of evidence someone purchasing the product would likely have.

Even worse than the browser security dialogs are some that the ICA client itself throws up, usually when the user is in the middle of doing something else.  Here is the classic example (this typically appears when browsing My Computer in the Open and Save dialogs of most applications):

I won't go into a critique of this one now - I want to finish this post today!

Can we translate trust judgements about remote systems into judgements about things people instinctively understand?

That is the question I am trying to answer in the context of Web Interface, to improve the way users experience our products and maximize their actual level of security.  I'm willing to forego a theoretically stronger security mechanism that in practice would often be undermined or bypassed for an apparently weaker security mechanism if it will be so easy to use and understand that most people would receive its full benefit.

The idea is that instead of allowing security to depend on individual users making judgements about technical risks they often don't even understand let alone have the means to assess, we should find ways to design the technology so that users are only part of the chain of trust decisions when they are in a position to understand what's happening, and have more natural ways of assessing risks - more akin to the face-to-face indicators I had when judging whether the double-glazing salesman was being honest with me, or trying to lure or pressure me into accepting an offer that wasn't really good value (for me).

Certainly that is possible in some cases.  For example, employers could give employees who need access from home a CD or USB stick that will configure their home PC to trust the company's Web Interface site without needing them to enter the correct URL or manually reconfigure their PC. The employee is making his primary trust decision on the basis of a person he knows (his employer or an IT person at work) giving him a CD for this particular purpose; he will probably assess intention and competence to some extent without even realizing it.  He can also make a secondary trust decision about whether the CD or USB stick could have been tampered with or swapped for a trojan once he received it, because it is a physical object he took home with him and people are fairly good at knowing how to look after small objects. (Or at least better at it than knowing when they have visited a phishing site.)

Of course the software installation process started by using that CD or USB stick needs to allow the individual sufficient control over what is happening, as well as ensuring they are properly informed (in terms they can actually understand) about what is happening to the security settings or posture of their system, why that is desirable or necessary, how the user can change their mind later etc.  This is where Citrix needs to do its homework, to make sure we design our products to minimize the chance they could be used maliciously to endanger anyone's systems.  (That still doesn't quite answer how any particular individual, who might be a third-party user of a Citrix system, can tell whether they should trust Citrix software to behave this way though.)

There are lots of even more complicated scenarios that get interesting, when you look at the relationships between application provider, application consumer, application data owner, device owner and application + device user.  I'll talk more about those actors and their relationships another time.

As I said earlier, trust is critical to how Citrix products work and are used, and there are many varied facets and levels of trust we could talk about.  Let me know if I've oversimplified things, or missed something you think is vitally important.

Cheers,
AndrewI

PS.  I've deliberately been imprecise in using the word trust, to try and speak to the various 'natural' meanings that different people assume. It turns out there are some quite interesting articles that talk at length about the nature of trust, which make insightful reading.  One that I've been reading recently is "Designing Systems That People Will Trust", which is included in Security and Usability.

I am delighted to report that Web Interface 4.5 has officially been published on MyCitrix this week, the fruit of 18 months of intense collaboration by a team extending more than halfway around the world, numbering well into the dozens. Another fruit of this effort is the first release of an officially supported WI portlet for IBM WebSphere, which follows the release of WI for Microsoft SharePoint almost a year ago. There were twists and turns aplenty throughout those 18 months, right up to the final hour before we pushed the "Go!" button, but in the end we had lift-off on schedule and WI is now safely in orbit - err, I mean you can download it.  (We had a brief problem with a couple of loose tiles, but hey it was a bumpy ride!)

It is more than 2 years since I started working on initial planning for this release, looking at how Citrix could deliver a single Suite-wide web UI that provided a consistent front-end for all the 'premise-based' products we were then offering (Presentation Server, Secure Access Manager and Password Manager).  Two of the original goals were to provide a consistent set of authentication methods for all web UIs, and the ability for individual product web UIs to be deployed together to form a single aggregate UI.

The second goal was realized with the release of WI 4.2 and Access Gateway Advanced Edition 4.2 last year, sporting an integration mode whereby WI renders the list of published applications in the AG 'NavUI' page, alongside the list of published web resources and file shares or documents.  We implemented a custom single sign-on mechanism to support this integration, capable of sharing end point scan information collected by AG so that application and session policies on CPS can be triggered by the same information.

The first goal spawned our Callisto project which has evolved over time to put the focus on advanced single sign-on capabilities, since authentication support across AG and WI is now largely consistent and less of an issue than it was 2 years ago.  ADFS and SAML have emerged as the key technologies and standards we are embracing for advanced SSO, and I know we will have more to say about this as our product capabilities increase and as the early adopters among our customers gain experience with the technology.

So, what's next?

For WI, our attention is now firmly focused on improving end user experience.  First up is tackling how to provide remote access to applications when web browsers are becoming increasingly locked down and security conscious - it can no longer be taken almost for granted that a web site can provide remote access to CPS applications.  The importance of this is being driven home by the release of Windows Vista last week, where some pretty major changes have been made to Internet Explorer affecting web sites with active content.  WI essentially by definition is all about running active content, so this is crucial to us.

On top of the technical limitations to what can be achieved, the general climate in the industry is tightening. Spyware and concerns over malware generally have become a regular feature on front page news.  Stringent guidelines have been published on how "goodware" (kindware?) should behave, to instill consumer and business confidence and protect both users and producers.  Legislation is increasingly being adopted to back this up, just in case software producers haven't got the message.

Reconciling Security and Usability

So security and usability concerns are at the heart of what we are wrestling with at the moment.  There is certainly tension between these concerns, but actually they are pulling the WI design in directions that are closer than you might suppose.  For WI, usability is about making things simple and obvious, about providing resource access with as few questions and steps as possible.  Security demands the user be informed about what is going on and in control so that things only happen with his consent.  But consent requires understanding, and understanding requires speaking the user's language and presenting only choices that make sense and are relevant to him - ie. keeping it simple and obvious.

The real challenge is to figure out which choices can be reasonably decided automatically, and when and how to present and explain the choices that the user really needs to decide for himself.

Calling all clients: you need software!

Let me give an example.  WI has three different software options to connect to CPS applications: the "native" ICA client (which can be used in two ways), the Java ICA client, and in some environments the Microsoft Remote Desktop Connection client.

These options mean nothing to most users.  Actually, they are worse than nothing because the options are completely baffling to most users.

We found out recently that just using the term 'client' to refer to the software needed to access applications can be confusing.  After all, in everyday life client refers to a customer receiving a service - lawyers and estate agents have clients.  If I'm not dying, divorcing or moving house why do I need to install 'client software'?!

It is no wonder that a fair few Citrix deployments disable WI's client selection UI.  (In 4.5 we made it easy to hide all the user preferences UI, including the Advanced Options on the login page.)

What we plan to do about client selection

What we are currently thinking would make more sense is the following.  (This is very much work in progress; feedback is welcome and we will update you as we work through this design.)

Using all reasonable tricks and established techniques, we will silently detect as much as we can about the browser environment's ability to use each type of client software.  This means checking for the ICA ActiveX control on Internet Explorer on Windows, checking if pop-up windows are allowed, if Java support appears to be enabled, and if an RDP ActiveX control appears to be available and the WI site is in a suitable IE security zone.  (Currently we think we can detect pretty much everything we need to know in an essentially silent fashion, though there is the possibility we will have to prepare the user if a necessary test could trigger a browser warning prompt of some kind.)

So far so good, but now things start to get tricky.

If we don't detect a native ICA client, but do discover that Java is working, what should we do?  Just because we didn't detect the native client doesn't mean it isn't installed - it might be that it is installed but our ActiveX check is blocked by IE security settings (which wouldn't necessarily stop us using the client for launches).  Should we offer the user the chance to install the native client software (or confirm that it is already installed) before proceeding?  But if it isn't installed and installation fails (or the user is unsure about installing it), how do we explain that there is another way to launch applications after all?

Our plan right now is to avoid this dilemma by making a reasonable decision without asking: if we can determine there is some way to launch apps, we will automatically use the best available method - in this case the Java client.

However, in doing this we've created another problem - the user experience with the Java client might be unsatisfactory or even broken in some way (say because drive mapping is disabled, or printing doesn't work well).  We now need to indicate to the user somehow that they might experience difficulties, depending on what they are doing with the applications, but they might yet be able to resolve the difficulties (we can't be sure yet) by trying to install extra software.

To deal with this, we plan to continue using the "install caption" portion of the message area to flag that the user might experience problems launching or running applications, but there is potentially something he can do about it.  The message will include a link to an explicit client detection and download wizard that will guide the user through the process of determining what options he has for accessing applications, including downloading and installing software and adjusting browser settings if appropriate.

There are many details of this wizard that we are working through right now; once we have some storyboards we are reasonably happy with, I'll post them here for comment.  In the mean time, I would love to hear suggestions on what would work better or what might not work so well.

Cheers,
AndrewI

I was fascinated by Jeff Muir's account of how the ICA web client came to be written, and also by the timing of when this happened (much earlier than I realized).  It brought home to me again the curious arc Web Interface is riding, from the early days of the Web when it was a novelty to be able to run applications from a web browser, to the point we are at now where it is getting increasingly difficult to run ICA applications from a web browser, at least with the technology we have today.  Making sure we are in a better place a few years from now concerns me, and makes me wonder if we need a step-change in technology.

We've known for some time that it is getting harder, and that people are running into more and more situations where Web Interface isn't working properly and they can't get access to their applications.  It isn't just executives using the kiosks in airports and hotels - though you can imagine how much visibility that gets when a company has just put in a shiny new Citrix system for remote access!  It also matters for customers wanting employees to be able to access critical applications from home, or from anywhere they might be stranded in a wide-scale emergency.

The problem is that security concerns have come to the fore, and browsers are increasingly trading off usability and convenience (or rather the apparent convenience you enjoy before your PC stops working for you and opts for a life making money for spammers) for better security.  Browsers themselves are including more security mechanisms like the IE Information Bar introduced by Windows XP SP2, pop-up blockers and the like have become de rigueur it seems in almost any product with an Internet focus, and security suites are hooking into almost everything that's happening on your PC to block bad behaviour.

This decline in usability unfortunately goes to the heart of the Citrix value message, that access is provided from any device over any connection anywhere.  Web Interface is the primary means we have of delivering on that promise, with the Internet and web browsers taken for granted as the ubiquitous baseline we can assume to exist (almost) everywhere.

So it's a big deal for us that WI is hitting more and more problems that undermine this essential role, and I am pleased to say we are now doing something about it.  We can still use your input and guidance though, to help ensure we are focused on the right aspects and make the right tradeoffs.

The approach we are taking is one that has been pioneered already; you can see a good example in action here.  In essence, the approach is this: accept that we cannot always accomplish what the user wants, or not always as easily or as well as the user would like.  Instead of pretending that we can always launch applications at the click of a button, and treating the small matter of ensuring the user's computer has the necessary client components and security settings as a kind of after-thought, lets make that process an essential part of the user experience.

And if we can't launch applications (for reasons beyond our control), lets be sure tell the user so clearly and promptly, so they don't waste any more time trying.  If we can say why, they also may have the chance to get something done about it; maybe convince kiosk owners to pre-install ICA clients for example.

I'm sure this is a topic that will get discussed a lot more, here and elsewhere, so for now I'll just whet your appetite with a screenshot from a prototype we've built recently which gives you a flavour of how we are intending to start following this approach in the near future. 
 
 
As I said in my initial post, this forum is an opportunity for you to give feedback directly to the Web Interface team, and there is a good chance that we will be able to act on your feedback and incorporate good ideas, if not in the next release then as soon as we can.  So, let us know what matters to you, and where you would like us to concentrate.
Cheers,
AndrewI

Hi, it's me again (Web Interface Guy).

Before I start going on and on with all my ideas about where WI should be heading (just the usual stuff: stopping hunger, imposing world peace, serving fries with every app launched), it will help to be clear about what WI is for; what it's role in life is and should be.  As you would expect, I have a fairly strong opinion on this, but I realize mine may be a rather blinkered view, coloured by the aspirations Citrix has and those I have myself - so please tell me if you think I'm being dumb about this.

Actually, it will help even more if I am clear about what Web Interface is first.  (Thought you knew did you?  Ah-ha!)

As far as I am concerned, WI comprises about a dozen things - in other words, this is what the WI engineering team actually builds and maintains:

• the normal WI web app (ASP.NET and JSP flavours)
• PNAgent Services (same two flavours)
• WI web parts and other bits for SharePoint
• WI portlets for Java-based portals (like WebSphere, SAP, etc)
• WI configuration manager (aka the central config service)
• WI extension to the AMC (our admin tool)
• WI installer and site manager tool (2nd stage installer)
• WI core resource access library
• WI SDK documentation
• CPS XML services (NFuse, Admin, Config, STA, RADE)
  

In fact, about the only component we don't build that logically should perhaps be treated as part of WI is the PNAgent client itself - it is essentially the non-browser UI version of WI.

I mention this list, because I want to use the term 'Web Interface' as a shorthand for all of it, not just the first item which is what everyone else thinks of as WI.  (BTW, I have tried to come up with a good term for this "WI in the large" notion but somehow all my acronyms seem a bit lame - WIITL anyone?)

So anyway, back to my point: what is the role of 'Web Interface', in this larger sense?

I think the answer is quite simple: WI's job is to provide users access to their resources.  The emphasis is on the word provide, for which I have a quite specific meaning in mind.

First let me digress a bit: Citrix started using the term Access Infrastructure a couple of years ago to try and explain the value our products offer, both individually and collectively.  That got me thinking, and I came up with this simple way to categorize our products and components as performing one or more of the following basic functions:

1. Provide access to resources
2. Deliver resources or access to resources
3. Enhance the delivery of resources
4. Control resource access and delivery
5. Manage (ie. measure or monitor) resource access and delivery
   

The ICA piece of Presentation Server of course delivers applications remotely, and enhances the delivery in many ways that I won't tire you with now.  Our SSL VPN products deliver remote network connectivity or access to specific resources (internal web sites, files, etc) and our NetScaler products enhance the delivery of web applications by providing security, compression, load balancing and so on.  Our latest product, WanScaler, does a similar job enhancing network connectivity to branch offices.

Presentation Server, Access Gateway Advanced Edition and NetScaler all support rich policies for controlling their respective resource access or delivery mechanisms, and we are already part way down the path of converging and combining these policy controls to work collectively.

The EdgeSight product line is focused squarely on the final function, of measuring and monitoring all of the above.  The Resource Manager, Report Center, and Dashboard components serve the same function for CPS specifically.

(Okay, you get the idea - there is a cogent strategy in action here.)

For me, the point is that WI is concerned only with the first function, and merely plays a supporting role to the products and components addressing the other functions.  This may seem a trite point, but actually it helps people in Citrix (me in particular!) to understand which of the many enhancement requests or neat suggestions we get for WI are sensible, and whether and how we should go about extending WI to support new features and capabilities in our products.

Right then, here is my definition of what it means for WI to provide users access to resources.  It is WI's job to

• Be aware of the existence, location and nature of resources
• Be aware of how resources can be accessed or used
• Be aware of users and access scenarios
• Make the existence of resources and possible actions known and available to users
• Arrange or orchestrate access to resources (or initiate actions) when requested
  

I like this definition for lots of reasons, but I'll highlight only a couple right now. 

#1 and most significant, WI is at the intersection of users, scenarios and resources. 

WI (usually) needs to know who the user is, but that can be a much richer concept than the traditional view of simply a user name or id - users can have multiple accounts or identities, and may take on different roles in their work at different times.  WI is a good place to help map between these identities and account for the richness that actually exists.  Authentication of course is important and needs to be flexible - but WI doesn't necessarily have to perform authentication itself.

WI then needs to take account of the scenario - 'where' is the user, how are they using the system, what are they trying to do, what are they expecting to happen?  In the WI team, we spend a lot of time thinking about this aspect - as I noted in my first post, for many users WI is the face of Citrix and although they may not be able to express very well what they want, they can certainly tell when it didn't happen!

WI needs to understand the resources; what are they, what are they for, what can you do with them, how do they work?  Note that this is more than just knowing how you "get" to the resource - different types of resources may be accessed with the same physical means (eg. ICA connections to published apps or virtual desktops), and the same resource might be accessed in quite different ways depending on the type of user interface.  For example, someone seeing a Word document link in SharePoint may expect Word to run when they click the link; the same person seeing the same resource listed on their BlackBerry might want a summary of the document emailed to them.

Finally we get the juxtaposition of these three aspects: WI has to figure out what can this user meaningfully do with this resource in thisscenario?  And how can that be made to happen?

#2, WI is an orchestrator and must therefore deal with all the complexities and idiosyncracies that come with the territory.  WI offers the user "X", the user says "do X", WI must make X happen!

In practice, for the resources WI understands today, that involves detecting the access client / device capabilities, downloading and installing appropriate client components if necessary (or giving instructions on how to do this manually), providing 'directions' (translating addresses as necessary based on the user's location relative to the resource, putting the right settings in launch.ica), obtaining security tickets and access tokens where needed, etc.

I think of WI as aiming to be a bit like the perfect travel agent; the user outlines what they want, the travel agent makes some assumptions and deductions, books everything, then hands over a tidy package with the itinery, tickets, foreign currency, emergency helpline numbers, sick bag, etc all neatly layed out.  (But they don't actually go on holiday with you.)

Well, that's the aim anyway!

Cheers,
AndrewI

Hi folks,

Every blogger has to start somewhere, so here goes...

I am the product architect for Citrix Web Interface, the main web user interface for Citrix Presentation Server. I guess that means if you don't like something about the way WI works, I'm one of the people you can now shout at - there is even a chance I could do something about it.  (Conversely, if you already like the way WI works, I am perfectly happy to accept accolades, awards, cool shades, that sort of thing - on behalf of the WI team of course.)

For many end users of Presentation Server, I'm told WI is the "face of Citrix", and increasingly responsible for providing that crucial first impression which can either make users love us or hate us - or more to the point, love or hate you as the person who put in this wonderful / *%$&£! 'Citrix' stuff!  (No pressure on anybody there then, that's nice.)

Given that, my aim is to use CitrixCommunity.com to talk about what we are doing and where we are going with Web Interface, how we (or at least I) would like it to evolve, and invite feedback and discussion on those thoughts.  I have an advantage not all product teams in Citrix enjoy, in that WI is not a component where we have deep intellectual property or add super-secret features, so I can talk fairly freely about most of the things we are working on or planning to do.

BTW we will probably create a separate area for WI in due course, but I wanted to start off in the Architects area because some of the ways WI could evolve have far-reaching ramifications on the architecture of Citrix products which go way beyond just the web UI layer people associate with Web Interface.  Even within Citrix, many people think of WI as just "a web page with icons" and are surprised to learn how much WI does and how many things it interacts with in some way.

But that's a topic best kept for another day.

However I can't finish without making reference to at least some of the many excellent resources already out there which are good places to learn about WI, where you will find tips on ways to customize it, and even pre-built packages that provide extra functionality which has obviously proved useful to many people.  I won't be trying to compete with any of these sites, I have to say!

(That reminds me: one of the things I want to talk more about is to explain our reasoning for why we do or don't include various kinds of functionality which clearly have enduring appeal.  But I'll save that for another day too; I'd like to get some rest before I'm roasted.)

From Citrix itself there is our official product support forum http://support.citrix.com/forums/cat.jspa?categoryID=3, and developer support forum http://support.citrix.com/forums/forum.jspa?forumID=106, plus our current very-good-but-then-I'm-biased SDK documentation http://support.citrix.com/article/CTX106665. Curiously, one of the best detail-packed documents on how WI interacts with other Citrix components - and a little-known one I suspect - is the troubleshooting guide for WI http://support.citrix.com/article/CTX106974.  There really is an extraordinary amount of information in there, so have a look if you haven't seen it.

From the wider community, there is www.brianmadden.com, www.thomaskoetzing.de, www.jaytomlin.com, www.jasonconger.com, and www.dabcc.com to name a few well-known sites; no doubt there are others I just don't know so well.

Cheers,
AndrewI