As everyone is aware, in remote user situations or in installations where corporate branch offices may be located in remote facilities, WAN bandwidth is at a premium. And, in many cases IT departments struggle to make the most efficient use of the available bandwidth because of WAN latency. Citrix WANScaler and Branch Repeater are proven networking appliance solutions for compressing and accelerating traffic across the WAN, and has aided many customers in increasing the overall efficiency of their enterprise networks.

However, questions have always existed regarding ICA performance across the WAN. Although the ICA protocol is very efficient by design, it has been questioned whether ICA traffic could be accelerated or compressed even more by WANScaler, making even better use of limited bandwidth situations.

With help from customer input, Citrix has developed and implemented new technology which greatly improves performance of ICA over the WAN. With upcoming releases of XenApp (in conjunction with future firmware release for WANScaler and Branch Repeater) partners and customers will be able to deploy hosted XenApp applications over the WAN with more predictability and higher performance for end users. By taking advantage of the newly developed compression algorithms in WANScaler and Branch Repeater, designed specifically for ICA, XenApp traffic across the WAN will be greatly enhanced.

Recently, Citrix performed an in-house performance assessment in order to test the upcoming ICA compression enhancements. The purpose of this project was to conduct an assessment of XenApp performance (with and without WANScaler) in order to compile performance data reflecting the increased performance of the latest enhancements. This, in turn, would show the advantage and the increased performance of a network infrastructure that includes either a WANScaler or Branch Repeater in conjunction with a XenApp server farm.

The key findings from the assessment showed impressive ICA performance increases when using WANScaler in conjunction with XenApp servers. These findings include increases in overall amounts of data sent over a fixed-size WAN link, increases in compression rates of ICA traffic, and reduced wait times for the end-user. Ultimately, these results show improvements the overall end-user experience, and show availability for increased user traffic without increasing existing server & bandwidth infrastructure.

With the changes to WANScaler and Branch Repeater, XenApp users accessing hosted apps over the WAN will be more productive with Citrix ICA WAN acceleration. For example, some of the initial test data showed:

• Improved application startup time by up to 22-39% per user. 
• Improved file download capabilities via ICA client drive mapping by transferring data 2-6x faster while using an average of 2-20x less bandwidth.
• Streamlined ICA print jobs over UPD by reducing bandwidth utilization by 3-30x and thus saving bandwidth for higher priority interactive traffic even while improving the speed of remote print spooling.
  
  

Over the coming weeks, we'll be talking more about the upcoming enhancements to WANScaler and Branch Repeater.  We'll dive into more details concerning some of the specific assessment testing results, and what they might mean to end-users who already have a Citrix WAN device in place, or are considering the possibility of integrating a device into their existing Citrix infrastructure.

Stay tuned...

A pivotal part of Project Independence is the technology at its core.  An obvious choice for Citrix, and many other virtualization companies, is to select the Xen open-source technology as the basis for a bare-metal hypervisor.  The wonderful thing about having Xen at the core of the hypervisor is that Citrix,  undeniably the experts in Xen, has teamed with Intel, undeniably the experts in hardware virtualization, to build the core client hypervisor.  This is the best recipe for success that I've ever seen.

The Intel and Citrix collaboration, known as Thunder Lake, is  a joint program intended to bring many proven server based virtualization technologies to Intel vPro client desktops and laptops.  At the heart of the Citrix client hypervisor is open source Xen with its architecture that is uniquely designed to ensure strong isolation between VMs running on a single device.  Several key Intel technologies like VTx, VTd, TXT, and TPM will be leveraged by the Xen hypervisor such that Citrix products and technologies can bring features previously found only on server based solutions to the client platform with full local execution.  For example, since Xen is the most up to date technology using Intel's VTd hardware, it is well suited to pass through device control directly to the client in a way that doesn't impact security.  Hypervisor features like Xen's support for VTd will solve some very tough problems for client virtualization.

A key requirement for a client hypervisor is a seamless user experience.  This is one of the main differences from a server-based hypervisor.  To accomplish this, hardware devices like Graphics and USB perform just like they do today but now on a platform running multiple VMs - all this without compromising security.  On the Xen client hypervisor you will get full 3D graphics, including Vista Aero, all the while maintaining full isolation between VM's.  This ensures that the corporate applications and desktops are safe from vulnerabilities that could copy your display and keystrokes.      

Today, Xen offers excellent isolation between VMs.  With our new client hypervisor, security will be enhanced even beyond today's standards.  By incorporating encryption and support for Intel's TXT technologies the Citrix client hypervisor will check and measure the boot process.  Now data and OS are safe even if client platform has been compromised by removing the disk.

The exciting thing for us at Citrix is that Project Independence along with the Intel joint collaboration project will bring leading edge hardware and software technologies together for the distinct purpose of providing a better end user experience and better security.  For years it seems an improvement in security meant a decrease in user experience or performance.  More than ever most of us are PC users and soon we will be able to own and control our Desktop and therefore be in control of our experience and productivity.

 Matt

Software as a Service.  Sounds like it would be a pretty easy concept to understand.  But when we look under the hood we find that there are three differing perspectives. 

At a hundred thousand feet SaaS is a buzz word for Wall Street and investors to get excited over.  It is the intersection of off premise hardware managed by others at a location (either virtual or physical) with dedicated resources which may also be a part of the larger Internet Cloud which combines Web Hosting with shared applications.  Wow!  That's a mouthful.  No wonder so many tech savvy analysts are so excited about it.  There are enough "high hit" Google terms there to start a search engine frenzy.

The investment community represents the first of three perspectives for SaaS.  Trying to predict what the future will hold and which companies have the technology to capture more customer wallet share in the ever growing information age.  The view from this perspective is about the value of software.  Specifically will software continue to hold its value and thus hold up the value of those Independent Software Vendors (ISVs) who produce it?

The second perspective is that of the software industry itself.  The opportunity is with those software companies who are blessed with no legacy code and have built their product for a distribution that takes advantage of the open Internet.  From this perspective the sky is the limit and exposure or awareness of the product is the key to attracting revenues from the mass market.  On the other hand ISVs who have invested millions of dollars in their code base and it has evolved from dedicated operating systems are not so lucky.  From their perspective SaaS could be the next crushing blow that renders their code obsolete.

Lastly we have to look at the guy who pays the bill.  The end user and for the purpose of this article, I'm going to limit that to the small and medium business.  After all, if the SMB actually makes up 80% of the total number of end points in the world, one would think that this is the most important segment to address, right?  From their perspective, SaaS doesn't matter.  All they want to know is, "how am I going to get my software applications running without an IT staff or with limited IT capabilities".  In fact if Geek Squad could figure out a way to supply physical services to every small business in the universe and manage applications on-the-fly, this would be the definition an SMB would use for Software as a Service.

If we start from the guy who pays the bills, the world of SaaS looks something like this.  A simple, secure and cost effective way to access applications and data from any device in any location.  Some ISVs understand this definition and are becoming wildly successful, because they understand the first order of business is satisfying the end customer's needs.  After all, he is paying the bill.  In the world of communication and collaboration we see products such as GoToMeeting and Microsoft Live.  The hard truth is that these products sell the best by circumventing the current IT professionals.  They are completely end user focused, have a specific use and are easily accessed from any device in any location.  In the world of Customer Relationship Management, Salesforce.com is the 800 lb gorilla.  Once again, simple to use and accessible.

But what of the thousands of applications that were built specifically for the desktop or dedicated server Operating Systems?  Are these guys just out of luck?  Will the millions of users who currently use these products suddenly stop and go to their web application cousin created by these new and emerging software vendors?  Maybe.  Eventually.  But not tomorrow.  Not in a year and maybe not for the next 5-10 years.  There are a hundred reasons why this is true.  The most compelling is risk and reliability.  The mass market by definition is not a part of early adoption.  In fact, according to Geoffrey Moore, we have an entire chasm to cross before there is mass market adoption of something as disruptive as a web app only business model.  If this were not the case, Google would be the name on your phone bill today instead of AT&T, everyone would be driving a Prius and Cable TV would have been killed by IPTV.  But these things take time and what is needed is a way to bridge the gap.

Most people in the IT industry don't think of Citrix as a mass market product company.  And since SaaS is typically associated with the mass market, don't think of Citrix playing well in this space.  That's because we have spent the bulk of our sales expertise and adoption in the large enterprise market.  Why?  Because it has taken 20 years to cross the chasm of server based computing for the mass market.  But what most people don't realize is that Citrix started out by creating products designed for low bandwidth, high latency, and low power CPU environments.  These are the basic tenants of the mass market.  Our core product, XenApp has only been enhanced for these tenants over the past 20 years.  That's why we have deployments of up to 50,000 end points within our current customer base.  No one else in the world has this type of delivery system to match the needs of the end user in the mass market for the thousands of applications that are not web based.  So as ISVs continue to look at the mounting problem of servicing the end customer in the SMB segment, Citrix will provide a simple, elegant solution to the perspective of the guy who is paying the bill... A simple, secure and cost effective way to access applications and data from any device in any location.

I wouldn't be surprised if Citrix is seen in a new light over the next couple of years.  After all, we can bridge the gap that crosses the chasm.

Twitter

2008 ended with a resounding call for change. It became the slogan as we entered 2009 and continues to hold true across political, social, and technological themes.  

Over the past few months since my last post, I'm beginning to see more and more change occurring; customers adopting virtual desktop technology as they look to really drive down the cost of desktop ownership associated with users. 

But let's be honest, isn't the utopia for companies to deploy technologies that can reduce costs and still provide flexibility and business agility anyway? And, corporate desktop has overtime become the biggest culprit – expensive, slow, & rigid.

In September 2008, I posted "Virtual Desktops, Mobile VDI and Client Hypervisors - Oh My!".   As I reread that earlier post, I may have accidently over-polished my crystal ball back then.  This week saw us release two very strategic announcements that I'd like to share a few of my own personal thoughts – very similar to my predictions in September, don't you think?

Here's a link to the two announcements on Citrix.com in case you hadn't seen them: Citrix Collaborating with Intel to Deliver Xen-based Client Virtualization Solutions, Citrix Unveils Vision to Transform Desktop Computing with Project Independence.

I may not be the next Nostradamus, but in this post, I'll give my take on what I believe will change fundamentally in desktop computing - something that is over-due.  At Citrix, we are hard at work at enabling this change.  I believe that Citrix Delivery Center and now Project Independence will become the catalyst for this change.

Change #1 - Your company will no longer own your laptop.  

Finally, as a user I can buy the machine I want, not just assigned by corporate!   Whether it's a 12" mini or a gaming powerhouse, I get to pick and choose based on my personal tastes and needs. 

At Citrix we implemented a BYOC (Bring Your Own Computer) program and we are on track to have 20% of our laptop users on the program in the next 12 months.  Sure, as a user I'm happy but our CFO and CIO are ecstatic – instead of dealing with constant capital expenditure we can have predictable expense on our income statement just like any other service or employee benefit on a regular basis.  

We are marching forward with this but our goal is to broaden this with our leading customers.  The client hypervisor developed in collaboration with Intel will become the foundation of our solution.

Change #2 - Your company will spend more on coffee and office supplies than they do on desktop management.

Companies have been talking about reducing IT support and management costs since the days of the first networked PC.  Today's desktop management is like creating a house of cards and giving one to every employee everywhere. To make any change is like moving a wall in thousands of these houses of cards distributed everywhere.  Citrix's approach to enable IT to manage OS, apps and user data/settings separately and centrally changes the economics entirely.  

We've already seen customers reduce total cost of ownerships in early XenDesktop implementations for office-based workers, specifically around the areas of IT helpdesk costs, updates/refreshes, and administration.  

Project Independence gives IT the flexibility for mobile workers.  Add/move/remove become mundane, updates & rollbacks can be done by anyone centrally and packaging/compatibility testing can finally scale.  Not to forget many tasks such as data backup/recovery and PC inventory management are entirely eliminated.

In this independent world, cost of desktop management will be similar to any other expense that a company makes for serving an employee – such as coffee or office supplies.

Change # 3 - You will access your corporate desktop from whatever device is most convenient at the time.   

I truly enjoy the opportunity to travel around the world to meet customers and partners and talk about Citrix's vision around both application and desktop delivery.  During these trips, I get to test our technology from all locations, various connection bandwidths, and increasingly across multiple devices.  With hosted virtual desktops, I'm able to securely access my corporate desktop on any Internet connected device – whether it's my own laptop, an Internet kiosk, or a mobile device (click here to view iPhone demo.) 

Project Independence extends this so an employee can access their personalized desktop from any device, online or offline. And if their personal laptop is unavailable for any reason then they can use whatever PC/Mac/iPhone they may have access to and still get their personalized desktop deliver to them instantly.

Gone will be the days when we still think that we can get our personalized desktop from only one laptop that we were given from our company.

Change #4 - You will switch back-and-forth between work and personal desktops on the same device without thinking twice. 

I was just thinking about how only a few years ago, corporate and commercial users were waiting for an all in one device that delivered on email, phone, music, photos, etc with simplicity.  A device that enabled me to unify work and personal items together to make life easier. From Blackberry devices to the iPhone, manufacturers delivered. 

I see a similar convergence of my personal and corporate desktop as well.  If I'm buying my own PC for work and personal use, I would expect access to both desktops to be seamless and still deliver on computing flexibility and usability.  I have read that 75% of users use their corporate machine for personal use (OK, so we all have iTunes install and aren't comply with corporate policies... let's keep it our little secret).

The current environment is not just rigid but also hard to enforce and insecure. Project Independence will address this – you could be working on your own media gallery during the weekend and switch to quickly refer to their customer information excel worksheet with a single click to respond to a quick business call. 

Change #5 - You will never complain about your PC being too slow again. 

I can't remember the last time I had to call IT because my machine was running slow, since running on a virtual desktop – I love the smell of a fresh machine in the morning.   It's great to get a nice clean, fast image running knowing that I can't really get myself into trouble.

That's the experience any user should expect from any virtual desktop solution whether it's local or hosted. Project Independence will free those laptops with all the gunkware – all the mish-mash of OS, apps and personal data/downloads that makes the PCs slower within few months.

IT is under a lot of pressure – budgetary, user satisfaction and new technology adoption.  Virtualization has helped IT in the data center already – it is time to give IT some freedom for desktop computing.  Project Independence is not just about giving IT freedom to centrally manage desktops with a single instance, but it will liberate businesses from huge capital expenses on their balance sheets, and give employee the flexibility of picking the best devices possible.

I can't wait for the Independence Day – I know it is coming,  2H'09...

Cheers,

Gordon

According to Wikipedia a Cloud is "A visible mass of droplets or frozen crystals floating in the atmosphere above the surface of the Earth". It is amorphous and very loosely structured. A Cloud has no specific strength, organization or output. A hurricane on the other hand is "a storm system characterized by a low pressure center and numerous thunderstorms that produce strong winds and flooding rain". A hurricane is organized, has form, purpose and an outcome. The center or eye of the hurricane is where the system is the most powerful and at the same time the calmest portion of the system.

Cloud Computing is interestingly fraught with the same issues of its vapor filled synonym. It is amorphous and lacks specific direction from a business perspective. It promises a world of flexibility and responsiveness, but little is said about its' form, organization, power and ability to generate an outcome, namely productivity and efficiency for revenue generation. Cloud Computing has been given an inordinate amount of power through press and hype, as though it were in fact a hurricane and not just a formless blob of vapor. But if it is truly a hurricane, what form does it have, what direction is it going and where is its power center? Who will pay for the "Cloud"? What is the model that produces enough inertia to keep it going and make money with it? The answer is simple. Applications!

What most experts neglect to write about in the dawning of this new age called Cloud Computing is its distant and ugly cousin, Applications Services. Why? Because it is so painful to recall the disastrous outcomes of the ASPs of 1999-2000. But if we don't scrutinize and learn from the past, how will we succeed by simply changing the taxonomy. The revenue generating end of the Cloud is applications and Software as a Service is the platform by which these applications will be delivered.

So much has changed since the Application Services model first came on the scene 10 years ago. Bandwidth is cheaper, web applications have evolved (or have they?), security is much better, and the virtualization of data centers is becoming common place. Hosting providers have become much savvier and have carved niches out to produce revenues. How? Through the efficient delivery of applications or Software as a Service. The golden child in this space is Salesforce.com for CRM, but what about the 2,000+ hosting providers in North America alone who service the SMB? In many cases these hosting providers supply the same applications that failed so miserably in 2000. What's changed? A model that now allows flexibility of application delivery to the end point in a secure, efficient way AND a mass of customers willing to pay for it.

So if SaaS is a growing market (most analysts believe it is now $3-5 Billion for the SMB with a CAGR of 20 %+), where is all of this money coming from? In this current economy Small and Mid-sized companies are looking for every possible way to save a buck. They are using SaaS to minimize operating expenses that used to be a part of their every day processes. But even in the best of economic times, using SaaS provides a huge amount of flexibility and is great for cash flow. In one survey, over 70% of the SMB respondents reported SaaS is helping them to lower overall costs and increasing their speed of implementation and delivery of applications. These are two killer assets especially given the current economic situation. No wonder this is a growth market in a declining economy.

Citrix is addressing the entire spectrum of the Cloud. From Infrastructure as a Service (XenServer) to Desktop as a Service (XenDesktop) through application delivery providing Software as a Service (XenApp). This approach goes beyond theory to the basic elements of revenue generation. The very core technology of XenApp, for instance, is based on the concept that software should be 'delivered' as a service, not deployed. As the market continues to evolve, Citrix will emerge as a leader in this space because we had it in mind twenty years ago when we began to evolve server based computing.

The hurricane is where Citrix is focused, not just the Cloud and we already have the technology to power a significant revenue generating engine for which service providers will gain efficiency and bottom line cost savings. Citrix XenApp provides the infrastructure for Hosting Service Providers to more efficiently generate revenues from the delivery of applications... in the eye of the "Cloud" storm.

This is the first in a series of topics regarding Software as a Service and the growing need to develop virtual application delivery platforms to meet the demand of this quickly growing market place. Topics include 'SaaS - What is it really?', 'Is there room for Virtualization of applications in the Cloud', 'Are all Hosting/Managed Services Providers the same?', 'Web Apps - Are they universal?', 'Is SaaS for Hosted/Managed Services Providers or for ISVs?', 'What is the role of an SI in SaaS', 'Where are the Telcos?', 'What is Citrix doing in SaaS?'

Key contributors to this series will include Brad Pedersen (Chief Architect and Senior Fellow), Juliano Maldaner (Senior Architect), David Wagner (Principal Product Manager) and Kurt Moody (Senior Manager).

Twitter

Do you use XenApp? Thinking about it? Heard of it?  Want to make it better?  Are you alive?   If you answered Yes to any of those questions, then I highly encourage you to attend the XenApp Deep-Dive TechTalk series.  Each TechTalk focuses on one aspect of making your XenApp environments easier, better and more available.

Part 1: Simplifying the Migration to XenApp 5 with XenServer (Register)

The first TechTalk on February 2nd at 1PM Eastern Time is focused on a task I did not like doing when I was an XenApp admin (although it was called MetaFrame back then)... XenApp Migrations.  Each release of XenApp has some pretty cool features to help make the users more productive or make the environment easier to manage and XenApp 5 is no exception.  So the big question is why aren't you migrating?  Is it because it takes too much time? Is it because it is too difficult?  A few months ago I blogged about the possibility of simplifying XenApp migrations with the use of XenServer (here and here).  This TechTalk will tell you if it is indeed possible.    Who knows, I might speak for 1 minute and say it doesn't help at all, but I highly doubt that will happen .  If you want to find out if XenServer helps and how, you will just have to tune into the upcoming TechTalk to find out

Part 2: Simplifying Desktop Delivery with XenApp (Register)

A lot of talk lately is virtual desktop this and virtual desktop that.  Well, this TechTalk is also focused on the virtual desktop, but not in a way you would expect. Most people talk about virtual desktops as a new way of managing the desktop infrastructure and how XenDesktop is the best solution.  This TechTalk, on February 3rd at 1PM Eastern Time is focused on the XenApp portion of desktop delivery.  How can and should we use XenApp to make the virtual desktop solution easier?  What best practices are there for application delivery and integration into XenDesktop? Tune in to find out.

Part 3: High Availability for XenApp with XenServer and NetScaler (Register)

Is your XenApp environment delivering mission-critical applications?  What happens if a physical server fails, or a hard drive crashes, or a internet link dies or an entire data center goes offline?  As we all know, XenApp contains many different components and each one is critical to the proper operation of the environment.  This TechTalk, on February 4th at 1PM Eastern Time, will provide some of the best practices for providing fault tolerance and high-availability to XenApp environments.  Don't leave your XenApp users in the dark if the lights go out.

I'm sure everyone will learn something or at least come away with a new perspective or idea on how to use and improve their XenApp environments.  I know I'm looking forward to getting some of your comments on your environments and how they can be made better.  Hope to see many people there.

Daniel

Just about every customer I've ever talked with has a common challenge, "How do we plan for cyclical surges in user activity?"  Depending on your business area, this could be a critical area of planning. Take for example, the retail sector.  We just came out of the end-of-year holiday spending season where retail stores typically see more foot traffic  and Internet-based traffic.  The increase in web traffic is several multiples higher than during other times of years.  If these organizations don't plan the infrastructure appropriately, their sites will become unavailable and customers will go elsewhere. 

Also, ever hear of web sites going offline because the site couldn't support the unexpected surge of traffic because of a release of a new product, or the first day of concert ticket sale, or the first day of American Idol online voting?  What about your business? Aren't there certain times each month or year where usage rates significantly increase for some of your applications?  Month-end or year-end cyclical surges are huge design factors when determining the size/scope of an infrastructure.  Most organizations plan for the surges by adding more hardware and infrastructure, but is this really the right path?  You end up spending more money on systems you only need for 2-5% of the time.   Is there a better way of dealing with the surge? 

Of course there is... Cloudbursting.  The premise is to use the cloud in times when excess capacity is required so you only pay for what you use. Instead of spending tens of thousands of dollars on your own infrastructure that is rarely used, you spend hundreds of dollars for your usage time in the cloud.  The big challenge with Cloudbursting is enabling the cloud to deliver your applications just-in-time.  In order to have a successful cloudburst, the following needs to happen:

1. Determine when excess capacity is required
2. Quickly enable  enterprise applications in the cloud
3. Seamlessly distribute user requests between the enterprise and the cloud
4. Dynamically reduce capacity as the needs decrease
5. Execute the entire process automatically, seamlessly and efficiently
   

Does this sound too good to be true? Being able to implement a Cloudburst is completely possible with the Citrix Cloud Center (C3). 

1. First, Citrix NetScaler is used to dynamically route users to your enterprise applications.  Part of the decision making process of the NetScaler is to determine utilization of the enterprise application, either based on connections, bandwidth or even CPU utilization.  When a threshold is reached, NetScaler sends out a warning about the need for more capacity. 
2. Citrix Workflow Studio receives the request for more capacity and kicks off a series of automated workflows that does the following:
   1. Instruct a cloud-based Citrix XenServer to boot up.
   2. Instruct Citrix Provisioning Server to deliver the appropriate application workload as a new virtual machine on XenServer.
   3. Populate NetScaler with address information about the new cloud-based workload
3. At this point, extra capacity is available in the cloud. NetScaler will use the address information obtained from Workflow Studio to load balance requests between the cloud-based application and the enterprise-based application.  As the load balancing continues, NetScaler will continue to monitor the application capacity levels, which will start the entire process over again and potentially spin up a new virtual server.
   

The entire process can happen in a matter of seconds.  New capacity is online in the time it takes to boot a server.  We are able to successfully add more capacity in the cloud, but we are not done yet.  We are trying to save money so we also want to be able to reduce capacity in a timely manner.  Just like before, the Citrix Cloud Center is able to do this.

1. As capacity decreases, NetScaler will reach a low-level threshold and tell Workflow Studio to reduce capacity.
2. Workflow Studio will kick off a series of workflows that does the following:
   1. Instruct NetScaler to stop load balancing requests to a particular application server.
   2. NetScaler will update its load balancing tables to remove the identified server
   3. Workflow Studio will monitor the identified server and wait for all user sessions to complete. Once this happens, Workflow Studio will instruct the server to shut down.  If no more virtual machines are running on the particular XenServer, Workflow Studio will instruct the XenServer to shutdown.
      

So, what do we get with the Citrix Cloud Center and Cloudbursting?

1. NetScaler provides us with the ability to identify when excess capacity is required and also allows us to seamlessly distribute loads between the enterprise and the cloud without users knowing from where their applications originated.
2. XenServer (with Provisioning Server) allows us to deliver a new application workload in the time it takes for a server to boot. Only one workload image is maintained as the application workload used in the cloud is the exact same workload delivered within the enterprise.
3. Workflow Studio creates an automated solution that orchestrates the entire process from adding more capacity to reducing capacity. 
   

You tell me, is cloudbursting a viable alternative to building massive enterprise infrastructures that sit idle 95% of the time?  I think it is. 

Daniel

Welcome to the new year and my first blog of 2009.  Let's kick off '09 with a focus on simplification.

Let's focus on a topic that often brings chills to a XenApp administrators spine... upgrades.  Back in the day when I was a MetaFrame administrator, I remember the time, patience, and sometimes stress involved with trying to upgrade 100 servers to the latest version of MetaFrame.  Well, a lot has changed in the world of application delivery. MetaFrame went through numerous identity changes to become XenApp. With those new identities we have witnessed a maturing of the product to include more functions, features and abilities to deliver troublesome applications.  But one thing has remained fairly constant, XenApp upgrades are not as easy as flipping a switch. 

Take, for example, the following knowledge base article from one of my coworkers, Jo Harder.  Jo created a great article explaining the technical concepts for upgrading and migrating XenApp 4.5 to XenApp 5. It covers the process, what to do and which approach to take.  This document has only been out for 4 months and has been the most read article for each of the past 4 months.  By my estimation, the topic of XenApp migrations is very important to people. 

Back in September 2008 I blogged about a potential way to simplify the migration process by integrating XenServer with XenApp.  In this blog I identified 5 areas where I thought this tight integration could show benefit and I called this the HOMER Criteria.  Well, after more investigation, analysis, testing and validation, I'm here to let you know that we can indeed simplify XenApp migrations if we integrate XenServer and Provisioning Server into our architecture. 

How is that possible?  Most people have a standard practice for incorporating new XenApp versions into their environment. This process typically takes on the following sections:# Server validation: We have to make sure that our applications work with the new version

1. Server builds: We have to spend time updating all of our server build images/scripts
2. Implementation: Need to update all servers while not impacting the user environment and not incurring huge hardware expenses
3. Maintenance: Need to keep our new servers consistent and updated with the latest hot fixes and service packs and updates
4. Rollback: In the potential event that the upgrade causes major issues, we need to make sure we have a fast way of recovering our old environment.
   

These are each critical to a successful migration to the latest version of XenApp.  Each one of these areas can be improved through virtualization and workload provisioning and you can expect the following benefits: # Time Savings: The time spent building servers is removed due to Provisioning Server's integration with XenApp. Brand new servers can be brought online in less than 30 seconds.

1. Repeatability: The integrated process used to upgrade to XenApp 5 can also be used for future versions of XenApp, except that future upgrades will be faster as the infrastructure is already virtualized and the process is familiar.
2. Simplification: The process is able to ignore the complexity of different configurations and drivers, helping to reduce the time spent developing server builds and installation configurations.
3. Maintainability: The solution guarantees consistency within the XenApp farm. When an application update or an operating system patch is validated, the entire XenApp farm will utilize the new configuration.
   

Some of you might be intrigued and want to know how to do it.  Learn how by reading the following materials:

• Reference Architecture*:* Understand the architecture, the areas of concern and the potential benefits
• Getting Started Guide*:* Get a high-level overview of the integration process.  This guide gives an overview of each phase, whereas more detailed steps can be found in the implementation guide.
• Implementation Guide*:* This guide takes you through, step-by-step, on how to upgrade your XenApp environments to XenApp 5 on Windows 2008 through the use of XenServer and Provisioning Server.  As you follow these steps you will see how the three products integrated into a solid solution for application delivery.
• Design Considerations*:* Follow these considerations to make your virtual XenApp environment easier to setup, maintain and manage.

So remember, if you are not thrilled about doing a XenApp migration, then try a new approach... Virtual and Provision. 

Daniel

We have a lot of exciting plans for Geek Speak Live! in the coming year which I wanted to give you all a heads up on. For those of you who haven't heard of Geek Speak, it's a program of informal and unfiltered discussions on technical topics, usually led by a CTP or other industry thought leader. We kicked off at Synergy in Houston, followed up at Summit in Orlando, then held a virtual version in early December as part of the Turbocharge your Datacenter virtual event. As well, a local version of Geek Speak was held in Des Moines by Michael Keen.

Encouraged by the enthusiasm and support we've received since launching Geek Speak, we are amping up the program in 2009, with larger and more frequent Geek Speaks. The main event will still be at Synergy 09, but we will be also running many more local and virtual Geek Speaks both before and after Synergy. Over the next few weeks I'll be publishing a schedule of events.

One of the objectives of Geek Speak is to have the audience determine what topics should be covered in the Geek Speak sessions. As such, we will be looking to you to propose and vote on what topics should be covered in upcoming Geek Speaks. You can also propose yourself as a speaker if you feel confident enough to lead the discussion (and take the heat from the audience ). Those topics with the most votes will be included in the agenda.

To get the discussion going on topics for Geek Speak Live! in 09, I have started a thread in our forums. If you have no idea of what a Geek Speak sessions looks like, check out some recordings from earlier events here and here.

The Ideal XenApp User Experience - A few years back our usability and design teams started a comprehensive research project aimed at crafting the ideal user experience for XenApp. The results were not at all encouraging for Program Neighborhood. It turns out that the best thing we could do is to become invisible. Users want to get to their Apps so they can get work done. Our mission became to focus on a completely transparent user experience. Launching a XenApp delivered application should be like, or better then, launching a locally installed application. The new XenApp Plugin coupled with the Citrix Receiver and some core changes to XenApp around the way we launch applications are all under active development and are instrumental to helping us achieve this vision. Unfortunately there is no room, or need, for Program Neighborhood is this new model.

The XenApp Plugin - is designed to seamlessly integrate XenApp into the users environment. It does this by placing XenApp delivered shortcuts directly into the users StartMenu. These shortcuts are standard windows shortcuts and can be manipulated by the users in the same way. They can be copied on to the users desktop, or into their quicklaunch bar, etc ... (See my video demo of this) The important point is that there is no special training involved, no additional program to launch and, in fact, no need for the user to know that the App is any different than other apps they use. 
Some advanced answers to anticipated questions.

1: Are there additional requirements for the XA Plugin above and beyond what I need for Program Neighborhood?
    * Yes. The XA Plugin requires the XenApp Web Interface Service to provide the web services that drive the user experience. If you already have Web Interface in your XenApp farm it's simply a matter of creating an additional XenApp Services site on your WI Server.

2: When is this happening?
    * Program Neighborhood will not be one of the Plugins offered in the componentized client that we are planning to release in late 2009.

3: I use Program Neighborhood as a diagnostic tool to connect directly to a Server. Will I still have this ability in the new Plugin?
    * Probably. We are looking at options to provide similar functionality in the new client model. It may be a separate Plugin, a feature of the XenApp Plugin or something else.

Since it's inception in 1996 with the first release of WinFrame the "ICA Client" has been on a continuous improvement cycle. As WinFrame grew and evolved into XenApp the client grew and evolved right along with it. As you can imagine the client portion of XenApp that runs on every users device has been a fertile ground for integration and feature enhancement. Over the past 13 years we have added support for all sorts of client facilities like the clipboard, local drives, serial and parallel ports, printers, multiple monitors, etc ... And we have rarely and reluctantly ever dropped or "deprecated" any features or support. E.g. We have only recently dropped support for "Windows NT 4.0 Workstation" years after Microsoft had ended their support. For the most part this strategy has been pivotal to the success of XenApp. Many of our customers have used XenApp to maximize their investment in desktop hardware by delaying the endless death march of the continuous and costly desktop refresh cycle. However, it's time for change. The latest release of the client has swelled to over 3 million lines of code (which is a lot, trust me) and the test matrix has grown to the point where we spend a great deal of effort every release just on maintenance and testing alone. This, of course, makes it very difficult to be as responsive as we would like to the needs of our customers and our business.

So what are we are doing about it?

1: We are introducing a new client strategy that revolves around what we are calling the "Citrix Receiver". The Receiver is all about simplifying and enhancing the user experience. The Receiver achieves this in many ways but most germane to this discussion is it's ability to hide complexity from the users and make the Administrators job of managing and updating the client easier.

2: We are modularizing the client. Breaking the client into smaller more manageable pieces allows us the ability to be more granular with our changes and enhancements and more flexible in our release schedules.

For example the "XenApp Plugin for Hosted Apps" will break down into three smaller Plugins:

• The Hosting Engine - Responsible for all of the heavy lifting associated with the delivery of Hosted Apps and Desktops.
• SingleSignOn - Responsible for passthrough authentication from a domain joined client.
• XenApp User Experience - Responsible for managing the integration of XenApp into the users environment.

* These Plugins will be on independent release schedules and are delivered by the Citrix Receiver as necessary.

What's the upside?

•  The Receiver is the last Citrix client you will ever need to install - The Receiver has a premise based Server component that will act as staging area and control facility for propagating Plugin updates out to the end users. The receiver will periodically check the Server for updates and, provided you allow it, will update with the newer Plugins as they become available.

•    More frequent release of enhancements - Plugins will be released independently and on their own schedules meaning we'll be able to bring enhancements to market when they are ready without having to wait for a periodic client release.

•    More granular control over what gets installed on the clients - Administrators will be able to control which users get which Plugins and when.

* Note: A standalone Plugins Pack will be made available for those who would like to continue to manage their client updates with existing methods.

What's the downside?

In order to make room for these changes we need to remove\deprecate some of our legacy features:

1: Thinwire 1 - Thinwire 1 is a low-level graphics virtual channel that was replaced by Thinwire 2 back in MetaFrame 1.8 FR1 (August 2000). Removing TW1 from the Windows client means that you won't be able to connect to a MetaFrame 1.8 Server with the newer client. See, I told you we were reluctant to remove anything.

2: Program Neighborhood --Program Neighborhood has been around since the early days of WinFrame. PN is a launch pad for XenApp Applications. When launched it connects with the XenApp Server and lists the Apps that are available for the user. PN was effectively replaced by PNAgent (Now the XenApp User Experience Plugin), which provides the same functionality with a far superior interface by integrating the XenApp delivered Apps transparently into the users Desktop. We removed PN from an active enhancement path several generations ago but we've been keeping it alive in maintenance mode to give our customers time to move on to the newer and better XenApp Plugin. There is more to the story but I think I'll post that as a separate Blog entry.

Some advanced answers to anticipated questions.

1: When is this all happening?
    * Citrix receiver will first become available in late Q109 with the componentization of the client available late in the year, probably somewhere in the middle of the second half.

2: Will there be separate Receivers for XenApp and XenDesktop?
    * No. There will be one "Citrix Receiver" that will deliver Apps and\or Desktops depending on which Plugins are installed and active.

3: Will I be able to control, which Plugins are installed?
    * Yes. The Citrix Receiver will provide Administrator control over which Plugins are installed on which machines.

4: How many Plugin Packs will there be?
    * Two. We are trying to keep this simple. There will be one pack with all of the Plugins and another one designed to be more lightweight for more streamlined deployments.

5: What if I want more granular control over the Plugins?
    * We strongly encourage customers requiring granular control to use the Receiver but the Packs will allow for context switches that will toggle the install of specific Plugins. I.e. "CitrixReceiverPluginPack.exe /No USB"

As the New Year quickly approaches, we're all thinking of our New Year's resolutions, and I'm sure that on the top of each of your lists is "Improve the Capabilities of my Corporate Citrix Farm".

OK, maybe it's not at the TOP of your list...

But improving the reliability, scalability, and ease of use of your Citrix installations is an issue that most administrators face constantly. And, as the New Year is upon us, it might be a good time to reflect on that "one thing" that you can do to make your farm more productive, more secure, more reliable, and more manageable.

Along those same lines, I think it's a good time for Citrix to ask... What new products or enhancements would you like to see from us? What can WE do to make your job easier? What can we do to make your farm more secure? What can we do to provide you with the tools you need to make your Citrix installation perform in ways you have not been able to achieve?

Feel free to reply with your #1 ITEM (just one, make it your biggest) that you would like Citrix to focus on in the upcoming year. If it's a direction that we're already working towards, and you'd like us to continue, let us know! If there's an area that you think we should look at, we'd like to know that as well! Although I can't personally promise that your suggestion will work it's way to the top of our list, I think that your feedback, as always, is an integral part of our corporate direction, and helps us to plan for the future as well.

So, let the 2009 wishes begin!...

You Can Still Creating a Secure Portal to Your Applications Using Citrix Secure Gateway!

In a perfect world, all the applications published on a XenApp farm would only need to be accessed internally, behind the firewall, using company equipment. But, unfortunately in today's world, that perfect environment rarely exists. In most instances, applications on the internal network need to be accessed by users outside the firewall. And, these users can range from trusted resources such as remote employees, to non-employee resources such as third-party vendors and outside contractors.

For many, the solution to this problem has been to allow secure access to the internal network via dedicated B-to-B lines or software VPN connections. Although these are solid solutions for allowing internal access, these are also drawbacks. Dedicated B-to-B VPN lines can be expensive, and unless the number of remote users is substantial, in many cases the costs are hard to justify. And for those have had to use software VPN clients, we all know that they are not always the most dependable or user-friendly pieces of software out there! And, unless properly configured, software VPN connections require users to deal with multiple logins.

In many cases, the Citrix Access Gateway (CAG) is the most viable solution to supplying SSL VPN connectivity to remote users. It provides the highest level of security by allowing complete customization, allows for high numbers of concurrent users (up to 10,000 users on a Series 10000 CAG), and provides increased flexibility for a broad range of end-user devices.

However, depending on the needed scalability level of your XenApp farm, the number of users, and other determining factors, you may not NEED all of the benefits that a CAG can offer. But, that does not mean that you need to fall back onto the "same old ways" of providing SSL VPN access to your remote users. With Citrix Secure Gateway (CSG) you can provide secure access to your internal applications for farms not requiring all the features available within CAG.

The Citrix Secure Gateway is an application that runs as a service on a server that is deployed in the DMZ. The server running the Secure Gateway represents a single point of access to the secure, enterprise network. The Secure Gateway acts as an intermediary for every connection request originating from the Internet to the enterprise network.

A CSG is installed in a network's demilitarized zone (DMZ) to form a secure perimeter around the Citrix components in your enterprise network. The CSG authenticates users connecting over the Internet and establishes a secure channel for data exchange between the client device and the Citrix Presentation Server.

The CSG eases firewall traversal and provides a secure Internet gateway between Citrix Presentation Server and client devices. All data traversing the Internet between a remote workstation and the Secure Gateway is encrypted using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol. The CSG transparently encrypts and authenticates all user connections to protect against eavesdropping and data tampering.

The Secure Gateway has features for enhanced security, certificate management, deployment, scalability, logging and instrumentation, and support for networking protocols.

For more information on Citrix Secure Gateway, configuration options, and proposed farm implementations, you can refer to the following Citrix documents:

Citrix Secure Gateway Administrator's Guide

Detailed Description of the Secure Gateway Connection Process (CTX117728) 

Are you interested in joining a Citrix User Group? Do you want to start a Citrix User Group up in your area? Are you already running a Citrix User Group and want to let people know about it?

We're planning to launch a tool soon on citrix.com that will allow you to find a user group, start a new user group or promote your own existing user group. It would contain forums for each group, newsletters and a place to announce upcoming events. I have already been talking to some User Group administrators who have been giving me ideas for what tools are needed, and I'm interested in any other ideas you would have. This would be a truly community effort, with Citrix just providing the tools to enable each group to recruit, promote and communicate. If a User Group already has their own web site, they could link of this one if they wish.

In the interim, I will create a page that will list details of any User Groups I am made aware of, so at least there is one central list. So,  if you run or a part of an existing Citrix User Group, let me know about it by posting a comment or emailing me directly at james.rabey@citrix.com. I'll get the directory published in the next few days, adding to it as I find out additional groups.

Many people know that an early codename for Application Streaming was "Project Tarpon".  What they often don't know is that the original codename was "RADE", which stood for "Rapid Application DElivery".  The design goal was to provide the administrator an ability to rapidly update applications, to an entire farm of XenApp servers without having to kick users off of the server, or even kick them off the application.  The foundations of RADE are still present in Application Streaming though elegant concepts have been added including "offline" and "streaming".   The centralized publishing here is also key because a streamed application never has to be "installed" onto a server.  You just tell the Access Management Console, which servers should get the streamed application and you're done.

The reason this is important is that the stream to server case for rapid application update remains one of the most important use-cases for Application Streaming.  This post describes the "RadeCache" directories and attempts to provide a clear description of what "stuff" goes in what place and how this all leads to a world where user settings can follow a user from machine to machine as "payload" of a user profile system such as Roaming Profiles or Citrix User Profile Manager.

History

Citrix AIE technology in Presentation Server 4.0 provided the foundation of isolated application execution, but it did not provide a mechanism for updating an "in use" application.  While the 3 layers of isolation still existed, the ability to replace the execution image at runtime was still impossible because there may still be users on that server, using the application binaries that you are trying to replace.

With RADE (aka Application Streaming), the execution image for an application is versioned.  Rather than a single directory holding the execution image, each version of the application image gets its own directory.  By updating the application, the administrator tells the isolation system that for new launches, use the new version of the application.  All presently running instances of the application continue to use the already running image, but new launches get the new version of the applications.  Awesome stuff and it is very RAPID!   Notice that the administrator updated the application in one place, on the Application Hub.  It then automatically gets distributed to all of the servers in the farm!  Update once, deliver the application to all the servers!

Here's a picture of the layers of isolation showing the versioning.  Noting that execution images (Targets) are identified by a GUID, pay attention to the underbar and integer that follow the GUID.
 
Notice above that the execution space (the part that holds the image of the "installed application") is versioned.  The first version of a Target gets "_1", and from there, the right hand part bumps by 1 forever.  When an update is applied to the profile, the new image is immediately available.  Every time the streaming client launches an application, it checks the Application Hub to see if the administrator has updated the application.   Usually, the answer is no, but occasionally, the answer is yes and if "yes" happens, the streaming system builds a new RadeCache directory to support the new version of the application.   Notice that this behavior is 100% exactly the same whether the operation is stream to desktop or stream to server.  The streaming client is the same and does the same actions in both cases.
Just with the above, the application can be updated rapidly!  

Here's a picture of the RadeCache, middle layer of isolation for the computer I'm using to write this post.

Yes, there are a bunch of GUIDs in there.  I'm not even sure what they all are though I do know that the top one is MS Office 2007.   Seems the internal farm is up to the 6th version of profiling MS Office and my administrator has happily done some network magic to erase the preceeding 5 versions.  Nice of them.  That the streaming client should manage this itself is a topic I will save for a future post. 

To observe in the above, the GUID's have a number after them.  That number is the versioning.

Per-user cache

About once a month, I get asked what happens to per-user application settings on a Target upgrade.  Answer: They are maintained.  A corolary to the same question is "how do the per-user application settings get referenced for use on a next execution machine?"  Answer: The streaming content is "payload" for the user profile solution.

Here's a picture of the per-user space (files) for the machine I'm typing this on.

Notice these also have a GUID per-Target, but that they do not have versioning.  In the early days, we actually considered versioning this space as well, but ultimately concluded that handling old user data in new versions of applications is something that applications just have to be able to handle, with or without isolation.  Decided not to version it and a few years in the field says that we made the correct choice.

Since the per-user RadeCache is located somewhere beneath %USERPROFILE%, well is supposed to be.  See here for details.  Stick with me on the concept.  Since the per-user RadeCache is in user profile space, the user profile solution will copy it from execution machine (XenApp Server included) to a future execution machine where the streaming system will find it for use in running the application.  The end result is that the user settings stick with them. 

There are some limitations such as replacing a profile with a fresh profile generating fresh GUIDs and this makes the per-user space empty on first execution.   For this, the administrator should "upgrade" profiles rather than replacing them.  Upgraded execution targets retain their GUID, while new execution targets get fresh GUIDs. 

Joe Nord

Product Architect - Application Streaming and User Profile Manager

Citrix Systems, Fort Lauderdale, FL

I got an interesting question the other day regarding Provisioning Server and XenApp.  As you might be aware, I've published many articles on the benefits of integrating XenServer, Provisioning Server and XenApp.  This question sparked an interesting discussion.

Scenario:

Let's say you have 50 XenApp servers total.  Most of the time you have carved out 20 of those servers to deliver Office 2007-type applications and the other 30 servers host another application like SAP.  Then comes month-end when we need more capacity, roughly 10 server, for the SAP.  What is the best approach to dynamically changing your XenApp environment to support these cyclical surges for certain applications?  Two words... Provisioning Server

Within Provisioning Server, we create three device collections:

1. XenApp 5 - Office Applications Servers: contains 10 servers dedicated to delivering Office-Based applications
2. XenApp 5 - SAP Servers: contains 30 servers dedicated to delivery SAP
3. XenApp 5 - Swing Servers: contains 10 servers whose applications can change based on the needs of the business

Within our Provisioning Server vDisk Pool, we have two different vDisks defined (remember a vDisk is just a complete image with Windows 2008, XenApp 5 and the corresponding applications):

1. XenApp 5 - Office Applications
2. XenApp 5 - SAP Application
   

Whenever we reach the month-end timeframe and require more SAP servers, we simply drag-drop the XenApp 5 - SAP Application vDisk onto the XenApp 5 - Swing Servers collection and those swing servers will boot up SAP during the next reboot,

So, this solves the issue of adding/changing XenApp workloads quickly, but that isn't the end of the story. Think about what is going to happen. A swing server, which we will call Smithers1, is set with the Office vDisk.  The XenApp administrator will publish the Office applications for the server Smiters1.  Later, we will assign the SAP vDisk to Smithers1 in Provisioning Server.  When that server starts up, the XenApp Data Store still believes that Smithers1 is delivering Office, but Smithers1 doesn't have Office installed, it has SAP.  We must un-publish office and publish SAP.  As you keep changing the swing server's vDisk, we have to continue this process or else users might experience issues (like being load balanced to Smithers1, trying to start SAP, but the path is invalid). But there is a solution...

Within the SAP vDisk, we create a script that does the following:

• List all applications published on this server
• Un-publish all applications from this server
• Publish the SAP application for this server

When a server starts with the SAP vDisk, it will be automatically publish the SAP application.  Then on the Office vDisk, we create a script that looks like the following:

• List all applications published on this server
• Un-publish all applications from this server
• Publish the Office applications for this server
  

If we build these scripts into our vDisk, we don't have to worry about publishing, un-publishing, re-publishing applications manually, it will be automatic giving us the truly dynamic XenApp swing server.

Daniel (Sr. Architect)

I've been looking at the breakdown of a desktop in a series of blogs.   In the first blog, I talked about how every desktop starts with a base operating system.  The second blog talked about application delivery and integration into the OS. The third layer of a desktop is personalization.  Many people think that personalization is simply a user's profile.  Well, personalization goes well beyond that. 

Think, for a moment, about what you do to your laptop or desktop to personalize it for yourself. Ignore the whole concept of virtual desktops at this point.   I've done the following to my own Citrix laptop:

Settings: I've changed the default settings for, well, just about everything, operating system and applications.

• Desktop background is Homer Simpson.
• My computer icon is Homer and the Recycle Bin is Lisa (because Lisa is the environmental Simpson). 
• I've configured my delivered applications with Citrix Visio stencils, Outlook with my personal signature, Office custom dictionary with terms like  XenApp, XenDesktop, XenServer, NetScaler and WANScaler. 
• I've added numerous favorites into my browser

Local Applications: Even though I receive most of my applications from Citrix IT, I've also installed a few applications on my own.  

• Video recording software: I continue to post video blogs and record configuration videos for Citrix solutions. I need a video recording solution not delivered by the IT department.
• Video Player: I've had to install numerous codecs/video players for different Citrix Videos I've created
• Instant Messenger: I've installed different IM programs so I can talk to coworkers
• Browser: Not everyone uses Internet Explorer.  With Firefox, Chrome, and others different people want to use different browsers. 

Information (Data): The data category is very important for personalization. You want to make sure your data is available where you would normally place it.  When you do a Save in Microsoft Word, the application defaults to Documents. 

Attachments:  What attachments do you use on your desktop? I've connected different digital cameras, webcams, MP3 players, mobile phone and printers.  Although many might not be Corporate Approved, they have been needed from time-to-time. 

By modifying application and system settings, adding your own local applications, attaching different peripherals and creating, storing and access data, you have turned an otherwise standard desktop into your very own, personal desktop.   That was the easy part.  The hard part is how do we virtualize the personalization layer so it can be applied during logon and change an otherwise standard corporate desktop, to one that is completely inline with what the user requires?  I could spend an entire blog on each of these four items, which I might do in the future, but for now I'll summarize.

A major part of the personalization strategy is focused on Profiles.  Most people cringe when they hear profiles because of issues they've encountered with Terminal Services and XenApp.  However, think about why we had profile issues in a XenApp world? Users would log on to many XenApp servers at a time, resulting in their roaming profile being pushed to numerous servers. Then when you logged out, that profile was uploaded, resulting in 1 profile overwriting another profile.  With XenDesktop, how many virtual desktops will most people use at a time? One.  Because of this design consideration, many of the challenges for profiles would be non-existent. 

However, we still must setup profile correctly.  We need to make sure the profile are optimized so they load faster (which is possible with the help of the Citrix User Profile Manager).  Also, we need to make sure the profiles are configured in such a way that the special folders (Desktop, Favorites, etc) are redirected off of the virtual desktop and onto persistent storage (File server). I'm briefly talking about profiles because in order to do it correctly, you need to have a solid profile strategy, something too long to discuss in this blog posting.  Right now, we can't do everything we need in profiles.

For Attachments we have to rely on virtual channels between the user's endpoint and the virtual desktop.  Whenever a USB device is plugged into the endpoint, it should appear on the virtual desktop.  With XenDesktop, this is a work in progress. Some things work and some do not.  But now is a good time to generate your list of what devices are required so you are ready to test with subsequent versions of XenDesktop.

The final item, applications, is an interesting topic.  Applications  are a layer in the desktop but it is also part of personalization because users add their own apps to personalize the desktop.  Before we go to potential solutions, we need to determine if this is needed.  Do you want users to be installing untested, untrusted, nonstandard applications into your protected data center? Or should you require the users to install these types of applications on their own end point device, outside of the data center? This is the first decision. As part of the virtual desktop analysis, you will hopefully identify the non-IT applications. If certain applications are used by a number of employees, maybe IT needs to add these into the application layer and start delivering them as a corporate resource.  If not, users will install the applications on their own. If using pooled desktops in XenDesktop, those changes will be destroyed upon logout. This will cause frustration and disapproval of the solution.  You can either

1. Grant certain users assigned virtual desktops instead of pooled.  With assigned virtual desktops, the desktop is never destroyed and only belongs to a single user, but this brings about a whole slew of issues around maintenance and management
2. Train users to install the applications on their local end point device
3. Use a some other solution that is not released yet that virtualizes any installed application and delivers to the user on future virtual desktops. I haven't seen anything like this yet.  Who knows what the future will hold.

Hopefully, this blog has shed some light onto the complexities of personalization.  I wish I could say Citrix has all of the solutions in XenDesktop right now, but I doubt many of you would believe me.  I can tell you that Citrix is working on this as this is the personalization discussion is a major piece of the virtual desktop puzzle. BTW, if you want to remember the the four areas of Virtual Desktop Personalization, just remember the LISA Areas for Personalization: Local applications, Information (data), Settings, and Attachments.  This goes hand-in-hand with the BART Principles of application integration for virtual desktops.

Daniel

In Citrix Application Streaming, the "Application Hub" is the place where streaming profiles are stored.  The streaming profiler writes content to the Application Hub and the streaming client pulls content from the Application Hub at runtime.  Here's a picture of App Streaming high level infrastructure.  Focus on the box titled "File Server" circled in red, this is the "Application Hub".  It could also be a web server.

Calling the place where streaming profiles are stored the "Application Hub" is great, it describes the concept and makes it clear that this is the place where streaming content is stored, in the hub!  Marketing folks LOVE IT.  Programmer folks are underwealmed, its a file server.

What gets obscured by the fancy title is that there is ZERO Citrix code running on that server.  This was a design goal from the beginning and we have worked hard to keep that pronciple in place - no Citrix code on the server!   This done both to reduce the number of places we install stuff, but also to follow the model of "keeping it simple".  Customers already have servers, don't ask them to put yet another protocol on their network.

The Application Hub stores your applications, but it is YOUR hub.  Any vanilla file server will do or web server.  It doesn't matter if its SMB, CIFS, Samba, Novell or HTTP, HTTPS, Apache or IIS.  The streaming client will access the content either via UNC based file opens or via a HTTP/HTTPS "get".  That it.  No extra magic.

Now - you can use your Application Hub (server) to control access to content.  Profiles are on-purpose stored in directories of their own.  Notice that you have a top level directory that holds all your profiles and that you have subdirectories for applications (profiles) below that space.  The streaming profiler absolutely insists that this structure be maintained when profiles are stored.  Why?  So you can DACL protect the entire profile with rights assigned to a single directory.  Its low budget, but it works and administrators are already good at controlling things like this.  Relying on the network/web infrastructure that is already in place makes it easy for the Application Hub to implement things like controlled access, again with the Citrix dev team not having to write any code.  This makes my life happy and I hope this description of the Application Hub takes away the mystery.  Remember though, it is the very grand and glorious "Application Hub" that provides the content for Application Streaming!

Joe Nord

Product Architect - Application Streaming and User Profile Manager

Citrix Systems, Fort Lauderdale, FL

At BriForum in June 2008, I received a nice compliment from Shawn Bass for keeping the Streaming Client version numbers small.  The idea was that with the release of significant new function in Inter-Isolation Communication, the streaming client version number was changing from 1.1 to 1.2 and he thought that was a pretty cool thing to go out the door in a point release.  I thought so too, but we didn't "go point" just because it was cool, I have history that has shaped my opinion of software versioning and taught me to NEVER change anything that isn't an integer.  Version data should be a single field, and should only get "bigger".

Streaming Client 1.2 is the 4th release of the XenApp application isolation systems.  Here's a rundown.

AIE - Presentation Server 4.0
Server side only. 
Profiling via AIESetup, execution via AIERun. or
Execution of a locally installed application, under isolation

Streaming Client 1.0 - Shipped with Presentation Server 4.5
Embrace desktops for execution platform as well as server side
Includes "offline" support.
Streaming Profiler GUI for capturing installation activity.
Extensive profiling activity compared to AIE - example: automatic virtual reboot.
COM isolation rewritten and registry hooking also redone.
AIE depreciated, but still around.  File system components shared.

Streaming Client 1.1 - Presentation Server 4.5 HRP1
Unified licensing with Citrix Presentation server
Vista support
Improved performance and application compatibility

Streaming Client 1.2 - XenApp 5.0
Inter-Isolation Communication (big ticket item)
HTTP supported as a streaming protocol in addition to SMB/CIFS UNC based copies
WANScaler (Branch Repeater) - Efficient CAB distribution; bonus, faster first time launch
AIE removed.

Streaming Client 1.3 - XenApp 5.0
Not released yet
 

Like the XenApp Plugin for Hosted Apps (PNAgent), the Streaming Client can release independent from its XenApp mothership.  Technically speaking, this hasn't happened, but it could and I'll go out on a limb and say that it will and we'll likely call that client 1.3.
Someday, a next release with something significant and new will come out. 

Will it be "1.4"? 

I'm actually leaning to 3.0.  This acknowledges that IIC should have been important enough to get a major release bump and that the next signficiant release will again bump the major version number.  Doing these will be "right" so the software doesn't appear as a 1.x even though it will be on its 6th release.  

Still, I do favor only updating one field of a version.  Do it this way, and upgrade checking software can't possibly mess up. 

The Citrix updates key off of the build major release number and the integer build number.  You can see these in the version data attached to any file built for XenApp.  In XenApp 5.0, they all start with "5" and the release build was 5357.2 or ".3" depending on when you called it done.  How we get .3 into an integer field is a bit interesting.   This means that the descriptive version number (the marketing name of "5.0" or "1.2") is just "text" and since its just text, it doesn't do much important to trigger updates.  

There SHOULD be no harm in bumping the major version number and resetting the minor to zero and my paranoia can go to rest - or at least changed to worry what happens when the major build number goes to 6 and the build goes out the door with a build number less than the build number of XenApp 5.0.

I'll send a virtual cup of coffee to the first person that can spot the bug on XenApp 5.0 and the Streaming Client binaries as related to this blog post.  Harmless, but still a bug.

Joe Nord
Product Architect - Application Streaming
Citrix Systems, Fort Lauderdale, FL

This has come up a few times now, most often on Brian's blog (for instance here and here): XenDesktop uses ICA to deliver virtual desktops to endpoint devices, so why doesn't it have the same capabilities as XenApp?

Before I go into details on the differences in capabilities of XenApp and XenDesktop, just a few words on the technical background: "ICA" is a rather wide-ranging concept. If you look at the details, it includes of a fairly low level "core" that deals with concepts such as capability negotation and security of the data stream. Most of the "interesting stuff", such as graphics, drive mapping, etc is handled through virtual channels built on top of this core protocol. You can envisage a virtual channel as a direct connection between a piece of software on the client and on the server, and the data sent between these components is tunneled through the ICA connection. So ICA both provides a backbone, and on top of that many of the "ICA" features are in fact fairly independent pieces that use the core ICA protocol as a communication pipe.

What does this mean for XenDesktop? Well, of course the ICA stack in XenDesktop inherits heavily from XenApp (Jeff has blogged on this extensively, and Brian has a more detailed analysis too). But the underlying infrastructure is very different: XenApp builds on top of Terminal Services, while XenDesktop uses basic OS APIs. This means that some XenApp features that are intricately linked to the Terminal Services platform, like shadowing, are by no means a straight: "just recompile this for Windows Vista and it'll work". Instead, we had to re-code some features from scratch in a way that's different from, but compatible with XenApp. All this takes time, and that's the main reason we had to prioritize which features were shipped in the first version of XenDesktop. In addition, since we were re-working some aspects, it also meant that we had the opportunity to incorporate some innovations and enhancements, such as extended support for multiple monitors and - coming soon - support for USB devices.

Now looking through the limitations listed in the technical FAQ, here is a bit more background:

• Kerberos SSPI: For this feature to be really useful you will typically have to mark the computer that your end users connect to as "trusted for delegation". While that may be ok for a relatively small number of well managed XenApp server, it's less clear that you'd want to do this for thousands of virtual desktops, where your users may have full admin rights. Moreover, Windows XP doesn't support constrained delegation, which makes this a less attractive solution. Lastly, from a technical point of view this feature integrates deeply with the logon process, and this is one area where XenApp and XenDesktop differ considerably. As a result of all of these reasons, we did not prioritize this for the initial release.
• SmartCards: this is a very important feature for a relatively small, but vocal target market. Again, from a technical point of view it is far from a straight port from XenApp. There are some unique considerations for virtual desktops, the applications that reside on them, and the apps that might be hosted on XenApp. Having said that, it is a very high priority item and we are working on delivering it as soon as possible.
• SpeedScreen: SpeedScreen is a term that refers to a large array of technologies that optimize the end user experience. The first version of XenDesktop shipped with support for the majority of SS features, including SS Browser Acceleration, SS Image Acceleration, SS Progressive Display. Now for the features that didn't make the cut: SS Multimedia Acceleration and the ability to change the quality of Flash based on bandwidth were unfortunately too late to make it into the first release, but we are well under way with it now. The situation is less clear with SS Zero Latency - XenDesktop already supports mouse click feedback, but keyboard type-ahead is a technology that is not terribly easy to set up, and can be tricky to get working with more recent applications that you would typically find on a virtual desktop; furthermore the bulk of the other SpeedScreen features already provide a highly optimized end user experience in high-latency environments. As a result, for now we are assessing how we can best make additional functionality available on XenDesktop.
• PDA Sync and Twain: again, these are fairly tied to the Terminal Services infrastructure on XenApp and we made the decision to take a little more time to do handle these devices (and others beside them) in a more compatible and user-friendly manner through our upcoming USB remoting technology in XenDesktop - look for this soon. This is one of those areas where it just didn't make sense to simply replicate what we had done in the past, and instead make an overall improvement.
• Shadowing: as I mentioned before, on XenApp this is based off Terminal Services capabilities that just aren't available to us in XenDesktop. Subscription advantage for XenDesktop Platinum comes with Citrix GotoAssist, which is a more complete replacement for shadowing, or you can also use the built-in Remote Assistance feature built into Windows for a premise-based solution. We also have plans to support shadowing functionality in future, but with the available alternatives, customers are still able to achieve the same capability.
• SmartAuditor: SmartAuditor is used by a relatively small customer segment, and thus wasn't among the highest priority items for a first XenDesktop release. There has been quite a lot of prep work for this already, and I am confident that we'll include this in one of the future XenDesktop releases.
• Audio on Vista: this is a rather complex area technically - Vista's audio architecture differs fundamentally from that used in Windows XP, and we need to completely re-implement the audio framework in PortICA to support Vista. This effort is nearing completion now. The good news is that we will be able to take advantage of this rework to integrate much better audio codecs in future and improve user experience with audio significantly.
• Perfmon Counters and User Experience Metrics: again lack of support for these metrics was due to resource constraints, and there are only minor technical difficulties to make them available on XenDesktop.

I hope this post has helped to give you an idea of the differences between XenDesktop and XenApp - and that we're not standing still here, but working as fast as we can to deliver an ICA stack that has full parity - and in some cases additional improvements - when compared with XenApp. Keep in mind that it took many, many years to add all these capabilities on top of the core ICA protocol, and we've accomplished quite a bit already and are closing in on several more. Most importantly, hopefully this dispels the myth that there is anything  fundamental that would prohibit us from making it the equal of XenApp ICA.

(Note: I updated this post to clarify and extend on a few of these items and to highlight where XenDesktop's ICA capabilities exceed that of XenApp, including support for higher multi-monitor resolutions. And as was pointed out: perhaps this article should instead be titled "Why ICA is ICA after all ".)