NetScaler 9 is officially here. Well, actually, it's officially announced. It won't be officially available to download from mycitrix.com until November 27^th. Yes, I know that's Thanksgiving. However, Citrix is a global company, and what better way to prove it than to post the NetScaler 9 code on a major US holiday? And, there is a chance that it might show up a day or two before the 27^th.

NetScaler 9 is a pretty big release. Looking at the detailed feature tracker, it contains over 350 new features and feature enhancements. I'm not going to go through all of them in this post, because that's what release notes are for. However, I do want to highlight some of the major new features that folks seem to be most excited about, and point you to some additional resources on this site that go into a bit more detail on some of them.

I like to think that NetScaler acts as the bridge between the network and the applications that run on it, making each of them work better with the other. NetScaler 9 furthers this.  A lot of the new capabilities and features making NetScaler more application-saavy than it already is. This is not to say that there aren't any hardcore networking enhancements in NetScaler 9, because there are a lot of them. These include everything from end-to-end support for IPv6 to enhancements to our GSLB functionality to the ability to tunnel IP within IP.

But in the end our networks are there to run applications, and it's the new AppExpert features in NetScaler 9 that seem to be generating the most interest.

AppExpert Templates make a given application the "first class citizen" within NetScaler. They do this by encapsulating everything about a NetScaler configuration that is specific to a given application, including:

1. The different application components (e.g., pages, files, archives, Web Services) NetScaler is managing
2. The various NetScaler entities and settings (e.g., VServers/VIPs, load-balancing algorithms, health checks, persistence methods, SSL offload settings) defined for these application components
3. The specific NetScaler policies (e.g., caching, compression, application firewall, rewrite) used for the application

All of this is presented in a way that puts the application front and center, and configuration and policy changes can be made from there as well. So, while today understanding the entire NetScaler configuration for Microsoft SharePoint (for example) involves moving around between the various NetScaler GUI tabs, with AppExpert Templates everything is centralized in one place.

AppExpert Templates can be imported and exported as well, so they make it pretty easy to move app-specific configurations between different systems. More broadly, several folks have told us that this, and the general look and feel of AppExpert Templates, will help with knowledge transfer within their organizations. You can see an example of the Microsoft SharePoint template being imported and then applied here.

If you go here when NetScaler 9 becomes available in a couple of weeks, you'll be able to download AppExpert Templates we've already built. And, as you'll quickly notice, AppExpert Templates aren't static. The underlying infrastructure makes it really easy for you tweak a template to your own specific needs, or to improve the template by adding to it. Hopefully, you'll all post any improvements and modifications you make back to the community site so that others can benefit. And definitely look for additional AppExpert Templates to be made available by us, but Citrix partners, and hopefully by other NetScaler users.  

With AppExpert rate controls, we've integrated the concept of data rate into the core NetScaler policy infrastructure.  This allows building policies that are only triggered when a defined data rate is exceeded.  And since it's integrated with the core policy infrastructure, it can be used with the various NetScaler functional modules (e.g., content switching, responder), so you're not limited to just dropping traffic as an action.

There's a number of ways folks have told us they're going to use AppExpert rate controls. Of course straight-up rate limiting (e.g., DNS rate-limiting, limiting traffic originating from a single subnet) is one example. Ensuring a given resource (e.g., anything from a VServer to a specific URL) isn't overwhelmed by requests is another. Two specific examples are:

1. One customer allows some of its partners to scrape its website so the partners can republish content on their own sites. However, the customer wants to ensure that overly aggressive scraping by the partners doesn't overwhelm the website and degrade the site's performance. AppExpert rate controls can be used to limit how much scraping each partner can do. This same approach could be used to ensure that websites that publish APIs -- so that partners can do mashups, for example -- aren't overwhelmed by any particular partner's use of the API.
2. Another example is a customer that was having problems with a couple of users FTPing a few too many large files at the same time. By using AppExpert rate controls to build an expression around bandwidth consumed per sourceIP, they can drop any additional FTP requests coming from a sourceIP (aka a user) that already has too much FTP activity. A more generalized use could also do something along the lines of limiting the amount of concurrent file downloading for a given SharePoint site, to ensure that downloads don't drown out other SharePoint (or other application) activity.

AppExpert service callouts make NetScaler policies extensible, and will allow you to integrate logic or functionality available in other systems and applications into NetScaler policies. Specifically, using an AppExpert service callout, a policy can send (over HTTP or HTTPS) any part of an incoming request to an external service. The result returned by the external service is then used like any other policy evaluation result.

As an example, one beta customer has an application that identifies and tracks IP addresses that are scraping its site's content. No, this is not the same customer that is interested in AppExpert rate controls. In earlier case, scraping is encouraged, they just needed to control it. In this case, the scraping of content amounts to theft, and the customer want to prevent as much of it as possible. Unfortunately, the IP addresses doing scraping change constantly (hence the reason they had to build an app), so statically defining them within the policy itself isn't practical. However, a service callout can query the application in real-time, and NetScaler then uses the response to either pass or drop the request.

Other use cases customers have mentioned include:

• Passing content to an external transformation engine
• Integration with UDDI or other directory services
• Geo-targeting or other token-based switching decisions, where the logic for the content switch is available in an external application  

NetScaler 9 has the first availability of the XML technology we acquired from QuickTree last year. New XML protections in the NetScaler Application Firewall module will now be able to inspect and protect XML as well as HTML traffic. In addition to protecting XML-based applications from attack, this can also be used to ensure that incoming XML traffic conforms to various standards (e.g., XML syntax, schema, WSDL validation). With XML, sometimes "bad" traffic isn't malicious but is just a mistake. Either way, the XML capabilities in the app firewall will catch it.

We've had the ability to rewrite payloads within the TCP header or payload since NetScaler 8.0. However, in NetScaler 9.0 we've added a URL transformation 'mini-module' to our generalized rewrite functionality specifically for rewriting HREFs. While this function is often thought of in the context of either SSL VPN or application firewall, it has uses beyond these as well. For example, onboarding apps acquired through M&A activity, simplifying change management or "Akamai-zing" graphics content.

Again, NetScaler 9.0 is big release. There is a lot more than the app-centric things mentioned above. There is a pretty comprehensive What's New in NetScaler 9 writeup here for those of you that want a more comprehensive overview.

Updated November 12, 2008:

I received a question via comments asking about Access Gateway Enterprise enhancements. As many of you know, Access Gateway Enterprise is in essence another module in NetScaler. So, all Access Gateway Enterprise functionality is included in NetScaler, which is why NetScaler is such a great solution for Citrix XenApp and XenDesktop. There are definitely enhancement to Access Gateway Enterprise in NetScaler 9. At a high level, they are:

• Support for IPv6 XenApp Client Connections
• Single sign-on to file shares, so your users won't get get as annoyed by as many authentication prompts (unless you want them to be)
• Full clientless access to Microsoft SharePoint 2003 and 2007 so users can access SharePoint sites from any browser
• Historical charting which allows you to see trend data on system activity

The views expressed here are mine alone and have not been authorized by, and do not necessarily reflect the views of, Citrix.

When implementing a "VDI" solution, most admins focus on the "Desktop".  What should the desktop look like, how many will be the same, who can access them, where do I run the desktop from and store my images.  Moving forward, the admins think about items like how they need to update the desktops with OS updates and or security patches.

I find that many times, applications are not thought about in the whole solutions from the admin point of view.  How are the applications going to be delivered to the end-user, how are the applications going to be managed.  Typically when this question arises, the answer is to install the applications on the desktop images just as they would be at the user's desk.  So let's look at the benefits of this so far........   Centralizing the desktop in the data center give you full control and security over of the desktops.  By installing the applications on the desktop images, you are also centralizing the application installs to the data center.  The downside to both of these would be when it comes to managing and maintaining the implementation(updating the desktop and the applications).

XenDesktop gives the admin a great way to reduce the headache and time associated with updating both the desktop and the applications.  XenDesktop can be fully integrated with Presentation Server.  This means that you can deliver a desktop from the data center to an end user, wherever they may be, and then deliver their applications to that desktop from Presentation Server in that same data center.  For companies currently running Presentation Server most application may already be setup and ready to be accessed from that centrally deliver desktop.   So now the applications are dynamically delivered to the desktop that is presented to the end user.  This allows the desktops images to be more flexible since the applications are not installed locally and no matter which desktop from a pool is presented to the user, the user can get the applications they have access to via Presentation Server and the ICA client residing on the delivered desktop.  These applications can be updated in the datacenter via a package that is being streamed to the Presentation Server or installed on the Presentation server.  Either way, the updates are done only on the package or the installed application on the Presentation Server.......not on every desktop image.

In addition to the applications, the desktop can be created as a single image or a few images based on your needs.  This image or images can then be streamed to the hypervisor on-demand when needed for a requesting user, via the Provisioning Server.  This way, you would only need to make updates to the "gold" image and then have it stream the updated desktop image to the user.  This method allows the admin to save space, time and pain of maintaining a desktop image for each user.

I hope that after reading this, you will have a good understanding of how much XenDesktop and Presentation Server can work together to provide an entire Desktop and Application Delivery system.  To allow users access to this system via a Secure Remote connection........ Implement Citrix Access Gateway Enterprise Edition.

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