Ok, tell me if you've heard this one before? How big can my XenDesktop farm be? The response is "It depends. . . Blah, blah, blah"

I've had many people ask me this exact question. I don't like saying "it depends", but it really does.  But how can anyone design their XenDesktop environment with an "It Depends" answer?  Well, the answer to that is It Depends Enough joking around. Let's take a look at XenDesktop and understand what goes into approximating the size of the farm.

The one component that will have the greatest impact on the size of a XenDesktop farm is the XenDesktop controller. The Controller is used to:

1. Maintain proper level of idle desktops (in hosted VM-based model)
2. Monitor the state of virtual desktops (idle, online, offline, in use, etc) for hosted VM-based VDI and hosted Blade PCs.
3. Authenticate users
4. Enumerate virtual desktops for the user
5. Connect a user to their appropriate virtual desktop
   

Now that we know the determining factor is the controller, one would think that it would be easy to figure out the max size of the farm.  One thing we need to completely understand is that there is no number at which point the XenDesktop farm will simply stop functioning.  There is no defined limit.  The limit is defined based on the environment like:

1. XenDesktop Controller Architecture: Is the XenDesktop Controller implemented as a single server or are the functions split across multiple controllers?
2. Logon storm: How fast and long will users logon during the start of a shift or a workday. I discussed this in a previous blog.
3. Logon Latency Acceptance: How long will a user accept their long time being?  10 seconds? 20 seconds? 60 seconds?
   

Controller Architecture

Looking at different implementation examples, I know that one will get the best logon speeds and farm sizes by separating out functionality within the controller.  For the large XenDesktop implementations, we recommend 3 controllers:

1. Master: Responsible for idle desktops and connecting users to a desktop
2. Brokers (x2): responsible for authentication, enumeration and virtual desktop state monitoring
   

By separating out theses loads, I've seen farms scale over 5000 hosted VM-Based desktops. Read about this architecture in the Modular Reference Architecture for XenDesktop.

Logon Storm

Like I stated earlier, the logon storm will have an impact on the environment.  During a storm, users will authenticate, enumerate, and connect to their desktop. For each connection that is made, a new idle desktop must take the place of previously idle desktop.  As you can see, by separating the XenDesktop Controller functionality across multiple systems, the logon storm's impact is spread across multiple systems, thus helping to negate the impact. The impact of the storm is explained in the blog How User Patterns Impact a Desktop Virtualization Infrastructure

Logon Latency

How long are you willing to wait for a logon to complete?  As the number of users connecting during a logon storm increases, the logon latency will also slowly increase. At some point, the logon latency will become too great for users to accept.  At that time, it is often appropriate to start distributing your load across multiple XenDesktop farms.

OK, OK, Just give me the answer!!!

So how big can my XenDesktop farm be?  2,000-20,000 users. 

1. Smaller: If I don't separate out my controller functionality, and have thousands of users connecting within a short duration, and expect sub-10 second logon times, my farm size will be limited in size
2. Larger: If I separate out my controller functionality, have tens of thousands of users connecting over 1 hour,  and my users will accept 20-40 second logon times
   

When you are asked about how large can your XenDesktop farm be, you need to ask a few questions before you can give an educated guess:

1. Will we be able to separate out our controller functionality?
2. How many users do you expect to login within a 10 minute period?
3. How long will users accept their logon times becoming?
   

I've seen logon rates of 2,000 users in 10 minutes, with separated controller functionality and 20-30 second logon times occurring in XenDesktop farms of 5,000-6,000 users. 

I hope this helps shed some light on how big is too big for your virtual desktop infrastructure.

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect
Facebook Friends: Ask The Architect

This is popular advice: don't wait until you have to change, do it while you can choose how and when. I believe it's time to apply that to the front end architecture for XenApp and XenDesktop.

Has It Been 10 Years Already?

Well, nearly ten. Ten years since Web Interface was conceived, nearly ten since it was launched as NFuse 1.0 in March 2000. Back then it was pretty basic: a few Java objects handling communication with MetaFrame 1.8 using an XML protocol, and offering a simple template language for constructing web pages and ICA files dynamically. Oh, and some example web pages to illustrate how they could be used. Sort of an early Lego MindStorms, but without the Lego ...or the robotics ...or - okay, okay, not really Lego MindStorms at all: it was just a construction kit.
 
Seeing as perhaps it didn't have quite the same level of fun as Lego Mindstorms, I guess it's not surprising that people started to ask, politely, if there could be a working example with, let's say, a standard login page and list of apps you could launch. Point taken: NFuse 1.5 shipped in March 2001 as the first turnkey release.

So it started; the idea of accessing apps and desktops via the web caught on. It made sense, but it needed a little more: a way to give users the ICA client would be useful. A way to tell if they had an old version and should upgrade would be good. How about supporting stronger authentication for the Internet, like one time passwords - you can? Great! Credit for a lot of rapid innovation goes to a group of people, pretty much all in customer facing roles, who seized the opportunity to forge ahead. Jay Tomlin is still revered for Project Columbia; a rich collection of features rivalling what Web Interface offers today. It was still 2001.

How Old is 10 in Web Years?

Web Interface has changed a lot since then, even if it isn't always obvious. Web security became a big deal, thanks to hundreds of penetration tests and audits. The demise of Microsoft's Java VM resulted in a switch to J# and ASP.NET (WI3). The Java objects eventually gave way to a completely new SDK (WI4). A major UI redesign (WI5) finally swapped tables for stylesheets - and white for black (sorry about that). Versions for SharePoint, WebSphere and other portals appeared along the way, along with more features than I can remember. Over the years Web Interface became essential, used by nearly 90% of XenApp customers and 100% of XenDesktop customers. For 50% of customers, it is the only access method.

That's all deeply fascinating, I hear you say, but what's my point - is ten a magic number?

Well, perhaps it is. You see, I believe it's time for a change - no, more than a change, a regeneration. A Doctor Who moment of sorts. The feedback I get is that Web Interface is serving customers well, and yet increasingly I hear how you want more. People are moving well beyond simple app and desktop access via the web; your environments are more complex, there are more access scenarios, more types of devices, greater diversity of users - indeed, greater diversity of most things - and now user expectations are going through the roof as the digital generation goes to work. As architect, I see how much Web Interface is being stretched trying to satisfy more and more requirements, and I see the cracks getting wider.

We all want to take things to a higher level. My message is that we need a new foundation to do that. After all, how old is ten in web years?

Enter Delivery Web Services, Dazzle, Receiver, Merchandising Server, and more. Delivery Web Services is the new bedrock designed to support native clients and web apps alike. Receiver and Dazzle signify a componentized approach to clients, as well as an invigorated focus on user experience and design. Merchandising Server is the start of a tool set for holistic delivery of IT services (whether in-house or out-sourced) to disparate end points.

My focus is on the web services, client components, and other infrastructure behind the scenes in this picture; that's primarily what I'll be blogging about in the coming months.

How Fast Does the Future Get Here?

A new foundation is all well and good, but it raises some thorny questions. How do we minimize disruption and confusion as 200,000 customers migrate to a new platform, and how long will it take? The only way I can see to do it is scenario by scenario, with a clear roadmap of the steps along the way. Even that will be a challenge because 200,000 customers cover a lot of scenarios, no matter how you group them, and the adage applies to us as much as to Microsoft that everyone uses a different 20% of the product.

Often, with a new platform, there are some signficant changes in approach, and a rethinking of assumptions. That is certainly true here, and I and others will be blogging about these over the coming months, to test whether our assumptions are valid and if our design choices will hold up. Our aim is to be open about what we are planning to do and why, so you can point out where we are getting it wrong. I think it is clear by now that you can change what we do, but I also believe you'll like where we're heading.

 
So don't panic! It's clear that Web Interface is going to be in use for years to come, and I'm sure we'll be supporting it for a long time (though hopefully not another 10 years!). I expect it will be updated to cope with updates to the OS, browsers, clients etc; probably a few more features will sneak in too. But increasingly our development focus will be (I would argue, needs to be) on building out capabilities in the Delivery Web Services bedrock, extending Dazzle to more scenarios, and building a web version of Dazzle+Receiver - maybe even more than one.  That's the beauty of the new platform: we can afford to build more UIs, each a better fit for its intended use, rather than always packing yet more features into the sardine tin that is Web Interface.  But beauty aside, I believe, quite simply, that now is a good time to build a new foundation, while we can still discuss the details and adjust the roadmap. I hope you will understand, and guide us on the best way to proceed.

Andrew Innes
Citrix Architect for Web Interface, Dazzle, Delivery Web Services, and assorted clients

Recently, I have heard many talk about how to deliver better application experience over WAN to branch users with flat or shrinking IT budgets?

Is delivering a better IT experience to branch or mobile users truly "priceless"? Or do you really need to demonstrate ROI?

It usually takes a lot longer than a year for something to become a 'cliche'. But the current global economic recession has created one of the quickest 'cliches' - 'Flat is the new Growth!' - flat revenues, and flat IT budgets alike.

Faced with flat or shrinking IT budgets, many organizations are clearly and rigorously prioritizing the highest ROI projects, focusing on doing more with less. Increasingly, the following lexicon has taken on a new level of significance and has become part of the IT budgeting process - time-to-ROI, payback time, hard or direct ROI, soft or indirect ROI and so on.

WAN Optimization is one of the very few technologies where IT spend is actually growing while spend on many other technologies is shrinking. In earlier blogs, I blogged about how good the user experience can be with the right WAN optimization solution. But if you are an IT decision maker, you are looking for hard dollar ROI to justify those investments.

We recently published a web-based ROI calculator, designed to show our customers the great savings opportunities available with Citrix Branch Repeater for XenApp and XenDesktop customers. Why don't you try out the calculator and let us know your feedback? We are looking to updating this tool soon based on your feedback.

You may cut and paste the URL in your browser: http://www.citrix.com/English/ps2/products/feature.asp?contentID=1858204.

I look forward to your comments or feedback.

Happy ROI!,

Sai

I posted the first 3 videos for the Workflow Studio 2.0 video tutorial series on CitrixTV:

1. Getting Started with Workflow Studio 2.0
2. Workflow Studio 2.0 Architecture and Components
3. Installing and Configuring Workflow Studio 2.0

You can access the series and watch them all in a playlist format from here:
http://www.citrix.com/tv/series/109

I plan to add some more video tutorials to this series and also plan to do a series that explores the new features in 2.0 specifically. Let me know what you think and what other topics you want me to cover...

After my first blog, I received a few comments focused about user-installed applications and how there isn't much talk about them.  Faisal posted a comment that stated he was doing a pilot with XenDesktop.  Right now the biggest complaint is that users can't install their own "personal" applications  and this is one of the big questions regarding virtual desktops.  We had a few comments from others wanting to know the same thing (some really good posts). Well, here are my thoughts

With a physical desktop model, users could essentially do just about anything to their workstation.  How much of a good thing was this?  It makes the user happy, but what are the associated risks? 

1. Managing the endpoint became a nightmare. Hard to know what application conflicts will ensue with these unknown applications.
2. Introduction of viruses, malware, spyware, etc.  Many of the applications users install are freeware/shareware from untrustworthy sites.  If it is on the desktop, does it now have the freedom to inflict damage to the rest of the network?
3. Workstations became bloated and eventually slowed to a crawl resulting in IT having to completely rebuild the workstation.
   

Let's now move to the desktop virtualization model.  If we are using hosted virtual desktops, that typically means the desktop is now operating within the confines of the data center.  If you allow users to install applications onto their hosted virtual desktop, in my opinion, you might as well just open the doors to your data center and let anyone in because that is what you are doing if you let users install anything.  Doesn't that concern you?  If not, try telling this to a security person within the organization. After they recover from their stroke, they will tell you why this is not a good idea.

Now I'm not saying that we can't and shouldn't allow user-installed applications, I just want to make sure everyone understands the risks with doing such a thing.  With the 3rd party solutions that are out there (AppSense and Atlantis Computing were mentioned in the comments from a previous blog post), my question would be

1. How do we protect the data center from unknown apps.
2. How do we keep the virtual desktop optimized and supportable. I don't want manage more bloated desktops By the way, this makes a great case for a Bring Your Own Computer (BYOC or BYOPC) model.
   

I do just want to add one more point.  I've been using a hosted virtual desktop for about 2 months now with a shared disk, so any changes I make (application installs) go away after reboot.  Truthfully, I haven't had much of a problem.  I did need to download and install a few freeware tools to help me finish a project, but I only used those items for about 2 hrs.  The nice thing, in this instance, was after I rebooted, they were gone.  I don't plan on using them again. And if I do, I'll just re-install. Of course this isn't an application I need. 

So the final question is should we really allow user-installed applications to persist or should we have a process in place where IT can quickly virtualize and deliver these applications to the respective users through a standardized application delivery approach?   

Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
  

What's new in desktop virtualization?  Well, lots of announcements from different vendors trying to peddle their wares, but I haven't seen or read anything very thought provoking. 
<rant> (Man, I'm totally geeking out here)

I'm trying to keep abreast of the latest happenings in the desktop virtualization space from a design and architecture perpsective, but honestly, there isn't much.  There are tons of solutions out there, some better than others. There are many point solutions out there that solve 1 issue for desktop virtualization.  Heck, even Brian Madden commented about the one-hit wonders in a recent blog. 

I'm also on twitter (@djfeller) and I try to follow VDI/Desktop Virtualization, I have Google Reader alerts setup (You can follow my shared items but there isn't much I've found useful). What do I typically see? One post about a new feature, then I see it retweeted a zillion times (Ok, I'm exaggerating a little, but still).  I see articles about why companies aren't doing the VDI/Desktop Virtualization thing yet.  Why? It's not because there aren't solutions. There are. They might not solve every use case, but they can solve some for some users. So what's the holdup?   No one is showing them how to get it done. 

It's time for a REAL discussion. Let's start focusing on designing a desktop virtualization solution.

</rant>

I'm not going to lie to you and tell you desktop virtualization is easy. It won't be a walk in the park unless your park is full of mountains, rivers, mosquitoes, coyotes, wolfs and bears.  So, why would we attempt to do something like this? Because the alternative is even worse. With so many different user requirements you can quickly see how the current distributed desktop environment is a disaster waiting to happen (or already happened over and over again).

But let's not dwell on the ugliness of the current model. Let's instead focus on designing a better solution.  Let's start talking about design, and my oh my there is a lot to talk about, which is why I'm about to start a blog series on designing a desktop virtualization solution with XenDesktop.  I plan to focus on the main design decision areas and giving you my thoughts and recommendations based on what I've seen so far. I'm positive many of you have seen different things, which I encourage you to comment so we all can learn. 

This should be a great series and I can't wait to hear some of your comments.  (BTW, I got a lot of great comments for all of you during our Provisioning Services for XenApp blog series and hope to get the same level of feedback.)

Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
  

I've been talking to a number of people regarding their ideas with respect to delivering Desktop Virtualization and Application Virtualization from the cloud.

Yesterday Amazon announced Virtual Private Cloud (VPC) with support for Citrix C3. Check out Craig Ellrod's blog post

It's great to see people thinking about ways to extend the reach of the Citrix Delivery Infrastructure. Our very own Scott Swanburg has blogged about this for several months. Scott has some very interesting discussions on how to make money from the cloud and our Service Provider license program. The reality is there is a chasm between existing web apps to deliver SaaS and the tens of thousands of apps that are Windows based. There is a huge opportunity especially in the Small and Medium Business segment for these types of services.

It's also worth noting that some Service Providers are already taking advantage of the opportunity, U.K. based Nasstar, U.S. based nGenX, ClubDrive and Australia based Bluefire. These companies service hundreds of SMBs with thousands of end points.

Last week I spoke to Kenji Obata CEO from Xenocode regarding delivering applications from the cloud. Kenji was kind enough to give me access to a streamed Citrix client what we call our Receiver and we helped Kenji configure it to connect to a desktop in the Amazon cloud. In this case the destkop is delivered via XenApp. If you're not familiar with streaming, think of it as downloading only the bits you need to start an application as opposed to an entire application. A little bit like playing a streaming radio station. In this case 4.2MB is streamed for startup vs. the 23.9MB package size. You'll need to install the Spoon plug-in in the top right of the box the first time for the browser integration to work . After that it should be just a click on the Green button to start your virtual desktop session in the Amazon Cloud. So far i've tested successfully from my XP and Vista machines as a non admin user and plan to try from my Windows 7 machine later today. Note that we only created one account in Amazon for this so you may be stealing sessions..... Anyway it's a fun demo so give it a try. Many of our existing customers do something similar with the XenApp Web Plugin today. Nonetheless it's alway personally interesting for me to see how other people understand the value of connecting to a secure managed hosted application infrastructure.

As these models continue to evolve, leveraging Citrix Dazzle and Merchandsing Server we could enable SAAS in so many new ways. It's fascinating that potentially combined with some of the concepts mentioned in Chris Flecks recent blog how so many possibilities could be opened up.

So I see lot's of creative thinking going on amongst thought leaders and real execution already happening. Certainly an area that I will be watching with keen interest. As always interested to hear from our customers and partners on how they would like to see this evolve.

So my wife drug me to the movies to see "Julie & Julia" this week and for some reason I seem to be thinking about everything in terms of cooking up a master piece.  I'll have to ask you to forgive me if this blog seems a bit "Julia Child-esh" but I can't seem to help myself...

Ingredients: 

(2) NetScalers

(2) Web Interface Farms

(2) XenApp/XenDesktop Farms

(30) XenServer VMs w/Essentials

(1) Provisioning Farm

(10) Storage Arrays

(2) High Speed Access Lines 

First, mix the ingredients in a data center and test to perfection.  

Next pick (3) market verticals for the highest expected IT spend in your area (hint: in 2009 that would be Finance, Gov't, and Services).  Find the local trade associations for each vertical and sign up (hint: In the U.S. Personal Finance Sector, American Association of Debt Management Organizations (AADMO), the nation's largest trade association for the credit counseling and debt management industry).

After hobnobbing with the trade association's board of directors, offer to provide a teaching seminar on "How to save up to 40% on your IT operating costs!" for all of the members of the association.

Create a presentation that the business owners of the association can identify with (hint: specific to the Debt Management business IT - remote access, call centers, etc). After filling an auditorium with Executives show them specifically how they can remove cost by taking them through the Citrix Service Provider TCO Calculator (that you've naturally branded with your company's identity). Make sure that you finish your presentation with the pièce de résistance (Disaster Recovery included in the service).

Offer (2) months of free service (hey, you've got to hook them you know?).

Sign 30 companies with 50 subscribers in each company with a service fee of $70 per subscriber per month.

...And voilà, you have a run rate of $105,000 per month (or $1.3 Million per year).

What if you could deliver online (published) apps through XenApp 6 times faster to your branch office workers? Or increase XenApp ICA print throughput by 38 times?

Well, now you can accelerate ICA with Branch Repeater and XenApp. Find out the benefits for yourselves by downloading Turbocharge applications to your branch offices CTX122321 whitepaper. 
Please share with us your experiences, results and thoughts.

Sai

Other relevant blogs: http://community.citrix.com/blogs/citrite/saia/

Are you a XenApp customer or partner wondering how to further accelerate the delivery of XenApp to branch office workers? And yet not upgrade your WAN bandwidth? And save a ton on OPEX for WAN services? Well, you can now check out the success story about how Neogen used Branch Repeater to:

• Accelerate XenApp ICA performance by 400 percent at branch offices
• Reduce IT help desk calls by 15 percent
• Raise throughput on existing bandwidth by six times
• Achieve 35 percent savings in operational expenses for WAN services

Happy accelerating!

Sai

Okay, I'm the first to admit it's been quite a while since I updated my Facebook status, so I never thought I'd say this ... but I'm tweeting. And yes, I said "tweet"...it only took me about a week to stop saying "twit".

But the good news is that there's a lot to talk say about our relationship with SAP and I'm not doing this alone. Joining me will be the rest of the Citrix/SAP alliance team and together we'll be updating our fellow followers on the latest and greatest happenings within the relationship.

There's some really exciting stuff coming down the road...don't you want to be one of the first to hear (or read) about it? 

Come on! Get in with the in crowd. Follow us on Twitter! 

Also, don't forget to check out the Citrix Community page for SAP. On this page we've consolidated all related blogs, news, videos, etc... from Citrix, SAP and third-party sites in our feeds section to provide a one-stop-shop for all things on the alliance.

We want to know how you're using Oracle in your Citrix environments. Let us know in the Community Verified area within the Citrix Community page for Oracle.

It's easy to use and takes only seconds of your time. On the right side of this page you'll see the following section:

All you have to do is select the "Vote" button next to the response that most closely represents your Citrix experience. From there you'll see a listing of all of the Oracle apps other community members have posted...paving the way for you to add your input...or if you can't find the app you're looking for, take the road less travelled and submit a new product! Simply identify the Oracle application and Citrix product and you're done!

You should be finished in less than a minute and in the end you'll have shared your experiences with the rest of the Citrix Community. Your input and implementation validation may help other members take a step in the right direction by selecting Citrix solutions to work alongside Oracle apps. Not bad for a minute's work, right?

So what are you waiting for? Enquiring minds want to know. Visit the Citrix Community page for Oracle and share your compatibility knowledge.

...and one more thing, don't forget to follow us on Twitter!

By now, you've probably been hearing or reading a lot about Citrix's relationship with Intel...or at least we're hoping that's the case!

Most of the recent news has been focused on our joint collaboration in the development of Citrix XenClient. XenClient is one of the most exciting projects in Citrix's history and we can't wait to see how the project changes the definition of desktop virtualization. With that said, there are optimization activities currently underway with our Citrix Deliver Center products, such as Citrix XenServer and Citrix XenDesktop that are worth talking about too!

Intel and Citrix have a long history of working together to deliver end-to-end solutions for the enterprise. From how Citrix XenServer works with Intel Xeon processors to how Citrix XenApp and Citrix XenDesktop work alongside Intel vPro technology to our joint development of Citrix XenClient, there is a great story in this partnership.

At Citrix Synergy 2009, Tom James, Business Development Manager, Digital Office Platform Division from Intel presented how solutions and technologies from Intel work with Citrix Delivery Center. For those of you who weren't able to attend Synergy or those who could but didn't have a chance to check out this session, it's available here for your viewing pleasure.

In this webinar you will learn:

• About recent server consolidation testing conducted in the Citrix Lab with Citrix XenApp, Citrix XenServer and Intel Xeon 5500 Series processors
• About the upcoming local desktop virtualization platform - XenClient - Citrix is developing in conjunction with Intel and how we see it changing the client landscape moving forward
• About the other collaboration areas from a technical perspective and how they add customer value
  

Check out the webinar!

The Citrix Application Streaming client and profiler version 5.2 are available in Beta form.  Here is a link.    MyCitrix credentials required to download.  The Streaming Client is "Offline Plug-in version 5.2". The Streaming Profiler is "Streaming Profiler version 5.2".  

These are not production, but they are pretty close to what will ship with the next XenApp release.  I note that the Streaming Client/Profiler 5.2 can be used with everything from Presentation Server 4.5 to XenApp next release.

Please give it a whirl.  The normal tech support forums should be used to share your positive experiences.

The 5.2 client will "consume" profiles created by all previous streaming profilers and the performance improvements noted below will be seen with no need to reprofile.  That said, there has been a years worth of changes in the profiler, so there can be other reasons to move up.

Things you will see:

• Second time application performance vastly improved.  Feature: "Sandbox reuse".  In the past, launching two applications from a single profile actually created two sandboxes even though those sandboxes could be considered one as they both had the same definition of isolation scope.  Starting a sandbox is a long activity, that is now skipped for second application launches, making second app launch very similar in time to locally installed.  This change was the focus of the release and should produce very happy users. 
• Sandboxes are left alive for 5 minutes after the last application terminates, improving odds for 2nd time launch compared to first.  Registry configurable period, in minutes.  Might change this to Ms.
• Integration with the Citrix Receiver to operate as a plug-in, or as a separately installed program.  This function first shipped in 1.3 which was a streaming client shipped asynchronous to XenApp releases.
• AIE* environment variables are now visible from pre-launch/post-exit scripts run outside of isolation.  This enables things like purging the per-user isolation space before/after application usage, without using RadeRunSwitches.  Some other issues with scripts were also fixed.
• A years worth of App Compatibility improvements.

The version number will be 5.2.  If you've seen my posts before, you know that I never intended to move away from 1.x, including shipping major new function in point release, like Inter-Isolation Communication at release 1.2.  Long story as to why, but the bottom line is that the streaming client after 1.3 will be 5.2.

Enjoy, 

Joe Nord

Product Architect - Application Streaming

Citrix Systems

• Listen to archived episodes:
  • Episode 4: HDX MediaStream for Flash with Juan Rivera
  • Episode 3: An Overview of HDX with Derek Thorslund
  • Episode 2: Profile Management with David Wagner
  • Episode 1: Power Management with Sridhar Mullapudi

Follow XenApp on | | |

Download XenApp technology previews

If you are providing IT services to your customers in the form of hosted solutions, growing revenues depends on your ability to market your offering in a very focused way.  It's just not enough to put a data center together, hang a shingle on the street and wait.  That's a recipe for disaster and why should you fail with so much opportunity at hand.  Follow these simple steps and I promise your results will be much more predictable.

Step 1 - Know Thy Product and Value

The question most of your customers will ask is "What would I do if I didn't use this service?"  If there is an alternate solution then customers will usually seek the lowest cost, easiest implementation.  So you must clearly articulate the value of your product and services.  As an example, if you are offering a hosted desktop (using XenApp) with Microsoft Office as the key service offering, then your customer has a choice to load the applications locally and manage them locally or use a hosting service.  A great tag line for this type of implementation might be "Lower total cost of ownership for Microsoft Office by 50% using our hosted desktop solution!"  If your value is lowering cost, state it right up front.  If your value is flexibility, then state it.  Remember that the customer always has other options so you'll want to clearly articulate why your solution is better.

Step 2 - Know Thy Customer

Who is it that you're selling to?  Is it the Small Office Home Office (SOHO)?  Is it the CEO of a 100 employee firm?  Is it specific to a market segment such as Finance, Legal, Manufacturing.  Messaging to the decision maker who owns a manufacturing firm with task workers is much different than messaging to a Law firm.  If the problem you are solving in a manufacturing firm is product line efficiency then you'll want to hit hard on the "up time" of the factory floor because your service offers higher reliability than on-premise solutions.  If on the other hand you are allowing attorneys to better focus on their workloads (vs. focusing on constantly rebooting their local machines) then you should put the highlighter on higher revenues through increased billable hours.  Focus on just a few of these types of customers and then show case examples of how their business will grow as a result of using your service(s).

Step 3 - Know Thy Marketing Approach

The ability to pick the right Content, Collateral and Context will mean the difference between success and failure.  What do you want to say?  What format do you want to say it in and what is the context in which a customer will hear it?  The content should be succinct and to the point.  Don't color your message too much or it just sounds like marketing jargon.  Put it in a form that is most easily understood.  If your customers are more likely to read a trade publication than the Wall Street Journal then call the editor and see if they will do a feature story on your services.  Don't talk in generality if the context calls for specifics.  For instance if you are an ISV who has developed software for the insurance business, don't talk about IT infrastructure savings.  In that case, the context demands you explicitly point out the benefits of using your specific software features to complete tasks or simplify the work.  If you have $10,000 of marketing budget make sure you've got the right mix of message and messaging.  In other words, if you can't measure with certainty the return on your investment (qualified sales leads) from your marketing, DON'T DO IT!  Even awareness can be measured in terms of the Average Sales Price of your service.  If you command a higher price than your competition for similar service types, this can be a measurement of your brand. 

Step 4 - Know Thy Support Plan

If you market your product or services but don't adequately support your customer then your brand will turn on you.  Further, your marketing content will be diminished by your reputation or lack thereof.  A perfect example of this was the Ford Motor Company "Quality is Job One" campaign run in the 70's, 80's and early 90's.  Wildly popular and producing great results at first, over time, the slogan began to wane in street cred as Ford's light trucks began to flip over on the highway. While Consumer Reports was slamming Ford products (such as the Explorer) as being substandard and losing quality to Japanese manufacturers, Ford continued to run advertisements to the contrary. The savvy consumer was not only put off by the ads but began to show distain for the product every time they had to take their car in for repairs while their neighbors had no significant problems with their Japanese equivalents.  Your products/service need to be supported when launched, during use and when upgrades are needed.  Using support tools like GoToAssist will aid you.

Follow this formula, and you'll find that customers will not only understand your value and purchase your product/services, but will also provide word of mouth advertising that is priceless in this business.

Desktop Virtualization is about user experience and agility, Server Virtualization is about consolidation and cost savings. It's amazing to me how so many people still confuse and believe Desktop Virtualization is just a straight forward extension of Server Virtualization that will just naturally evolve from their existing Server Virtualization infrastructure, without realizing that these are two very different use cases requiring a different approach.

In my second month as CTO of our XenApp business at Citrix, I have been able to talk to a range of people about their desktop and application virtualization strategies. Some are brand new Citrix customers, some are not even aware that Citrix is so much more than thin client remote access and some are real thought leaders who challenge my thinking everyday. Having been a customer at numerous top tier Wall Street firms and implementing Citrix technologies for many use cases including Desktop Virtualization at scale. I've lived through the pain that this sort of thinking causes in the real world and feel it's time to share some experiences and to help my twitter followers decipher some of my cryptic Desktop Virtualization!=Server Virtualization tweets.

In the physical world, do your server administrators manage your desktop infrastructure?
Let's start with a basic question. If you are a very small shop, perhaps a single administrator does it all. However as you scale up, different teams start to form to address specialized use cases acquiring specialized skill sets along the way. Even at the smaller firms I've worked at, the backend operations folks very quickly separate themselves from the front office folks. The workflows and mindsets of these people are quite different. Let's diverge for a second and think about how security teams function in an enterprise vs. let's say the server team. Does the server team care about security? Sure. Would the server team let the security team design their server infrastructure? Of course not! Why? I'd hazard a guess that a super secure inflexible system would be developed by these folks that would be too slow to react to dynamic business needs. In other words overkill, despite the best intentions of a security focused person. This why desktop teams design desktop experiences........

The management workflow for desktops is different.
It has been my observation that even in large enterprises that have invested in server virtualization, they don't reboot thousands of servers at the same time. They usually schedule these events in small clusters during maintenance windows to avoid impacting many users who share servers. Desktops however are a different animal. After every patch Tuesday, I'd want to reboot all of my machines in large batches, just like I do today in the physical world as they impact only single/limited users. This type of reboot scale quickly puts a demand on the virtualization infrastructure that it is usually not designed for in a server world. In other words the Hypervisor workloads are very different and you have to worry more about many VM's performing the same operation at around the same time (e.g. OS/anti-virus updates).

Desktops require a different security model.
Taking the same example, desktops require a lot more flexibility with reboots. A lot more ad-hoc user driven reboots happen. This usually breaks the often rigid administrative and security permission model in the server virtualization world, which serves a different purpose. I recall many a debate as to why reboot permissions on the virtualization infrastructure needed to be allocated to the helpdesk to support Desktop Virtualization users. Something that was a struggle for Server Virtualization teams to accept as they were of a mind set that servers were highly controlled environments. Brut force did the trick in the end

Desktop scale means rethinking your virtualization infrastructure.
Think about the number of desktops you have in your organization vs. the number of servers. If you have 2000 server VMs one would most likely say that's a lot of servers, but would not say that for 2000 desktops. If you had 10,000 desktops that's a decent amount that is not uncommon at many customer sites. However 10,000 servers would be considered to be a very large server site. Therefore if you want to invest in Desktop Virtualization at scale, it's a totally different ball game when it comes to managing and scaling the virtual infrastructure. Regardless of Hypervisor choice, I found I had to split away from the core server team design and develop an infrastructure that would support a desktop experience at scale.

Optimize virtual infrastructure for user experience.
Delivering a desktop user experience requires you to focus on minimizing response time instead of maximizing throughput like server virtualization. There is also a greater burden to support virtual peripherals, and VM Management is far more critical. In my experience this was like talking alien to the server guys, and they just couldn't get their head around it or just couldn't be bothered accommodating this desktop thing in their server virtualization design, I still haven't figured that part out...........

Desktops management is different and does not require the high end features of Server Virtualization that add to cost.
As I was writing this I came across Brian Madden's blog today that touches upon this point. Based on what I have seen I agree most of the bells and whistles that people get excited about with server virtualization, just don't apply to Desktop Virtualization and add to costs and complexity. For example live migration on a desktop is such an edge case that I just don't buy the investment justifies the gain. To me this is a desktop use case. I remember many debates arguing how best to implement Desktop Virtualization. The best piece of advise I got from one of my mentors was to think of this as 'it's a desktop'. Be very clear this is a desktop, and understand that is what you are trying to implement. Don't overcomplicate things that you wouldn't normally do for a desktop. If you get your organization to understand this and behave accordingly I believe it will resolve many debates about how best to implement. Simply put your questions and actions in the context of it's a desktop.

So I hope many of you will now begin to develop an appreciation for why Desktop Virtualization is not Server Virtualization. You can't force a round peg into a square hole. They have different drivers. Desktop Virtualization is about user experience and agility. Server Virtualization is about consolidation and cost savings. With these very different goals in mind it will be no surprise to me that trying to implement Desktop Virtualization with a Server Virtualization mindset is highly likely to result in frustration. Desktop teams know what it takes to deliver a desktop experience. While it's true that there is overlap with traditional server roles, this is just an organizational evolution that will happen over time IMO. Desktops guys after so many years playing PC jockey are relevant again and will need to become empowered to create successful Desktop Virtualization implementations that are designed from the ground up to deliver a desktop experience. Don't forget it's a desktop!

I have previously written about how the Application Streaming client prunes the file system cache.  What was not discussed is how the streaming system manages the REGISTRY portion of the execution content.   This post brings attention to that need and provides a reference to a source code application that can assist with pruning the registry portion of the execution cache.

When the streaming system executes an application, it can run more than one version of the application at the same time.  New versions of the app can be used by user B when user A is still using the old version.  This way, the admin can update an application "hot" and when users closes and restart the application, they get the new version.  This covered in some details in the discussion of RADE.

What is not obvious is that while the streaming system file system cache has a high water/low water algorithm for managing the cache, it has no such algorithm for the REGISTRY content.  Peek into HKLM at the RadeCache space and you can potentially see registry content supporting MANY versions of old applications.   

Here's the execution space on the machine I am using to write this post.
Notice in my case, I'm on version "5" of the execution Target 1b3... which happens to be Microsoft Office 2007, the Vista/Win 7 execution target as published in the internal "showcase" at Citrix.  Also notice that there is no "4" because I have a strange habbit of formatting my primary development box once a month whether it needs it or not and the admin hasn't updated the profile since my last reload.  I also know that our showcase admin occasionally does admin magic to delete these old spaces, but that is getting away from the purpose of this post.

Real customers

Heard from the field a couple months ago of a customer who had taken RADE to true heart; updating applications almost daily and then streaming them to server.  After a few months, they were in the hundreds in the versioning, and while this worked fine, the registry had become polluted with all the old versions.  Notice that the file system was fine, the old versions had aged themselves out of the cache and been erased, but the registry was littered with stuff that should not be there.

Utopia

One can effectively and easily argue that the Streaming Service should observe application updates and when nobody remains using the old versions, it could happily perform house cleaning to purge out the not needed information from the installation image registry.  This would be a very good argument and I'd stand up and say, you are right, which is what happened with this customer.  Things like Rollback to earlier versions makes this more complicated, but in the general sense, managing this registry space should be no different than managing file system space.  It is more difficult though because for file system, there's an advantage that anything you erase by mistake, will automatically be put back if it is needed.   For registry, it's populated once and left alone.

To "solve" the problem, I coded a little utility to prune the registry cache.  It runs outside the confines of the streaming service and defaults to "keep 2", to enable rollback.  The SOURCE code for this utility has been posted to the Citrix Developer Network, MyCitrix account required to get in.

One can imagine a day where this function is part of the streaming service.  I imagine that day too.  Until utopia arrives, if you need to programatically prune the registry cache, this utiltiy can help.  Set it up to run once a day/week and it will keep your registry space clean.  The UI is pretty primitive, it shows to stdout a before and after record of all of the space in the RadeCache along with indicator of stuff that it erased.

What it doesn't do

The utility scans the registry content, observes all of the cache space and then recursively deletes the "old" entries.  What it doesn't do is know which GUIDs are orphans, supporting applications that are no longer published.  Interestingly, the streaming service also doesn't know which entries are no longer used.  It would be a worthy addition to also reference the "last access time" information and purge items that are over a limit.  Here, shelling to the RadeCache utility to perform the erase would be the correct action so that the official tool could be used to purge our the execution cache, both file system and registry.

Enjoy, 

Joe Nord

Product Architect - Application Streaming

Citrix Systems

Citrix Application Streaming runs the majority of the isolation system as a service.   Being good security citizens, the service (radesvc.exe) is run on a named user account (Ctx_StreamingSvc) rather than LOCAL_SYSTEM.  There's some fancy security name for this but what it comes down to is using the least privilege you can to help limit the potential damage you can cause should you go astray. 

The user Ctx_StreamingSvc can write to only a few locations on the machine.  As a user account, it automatically cannot write to \Windows or \Program files and cannot write to HKLM, or even HKCU for any user other than itself.  This is good.  There are some things however that just demand a service, such as populating a SINGLE application installation image no matter how many users will be logged onto the machine.

At installation, the streaming service user account is given full control of a few locations:

• \Program files\Citrix\RadeCache
• \Program files\Citrix\Deploy
• HKLM\Software\Citrix\RadeCache

These relate to the "middle layer" of the "layers of glass".  They are the SINGLE space that support multiple application executions across many apps and many users.  The ability to write to these spaces is needed to runtime populate the execution content, so this is pretty much a "must have" for the streaming service to do it's job.

Where it gets neat is is that real USER accounts have to "see" stuff in the cache so that they can layer in the isolated content, so that the layers of glass can support read-only opens to the stuff in the installation image.  In the normal Windows installation, users, read: not admins, can "see" anything beneath \Program files, so in theory, there's no action needed to pull this off. 

Being security paranoid folks, the Citrix isolation system restricts users from seeing execution content unless they are actively running the application.  The DACLs are runtime added and removed.  Here is a file system view of the DACLs applied to the RadeCache execution space, first for the service account and then for a user account.

RadeCache directory

. NT AUTHORITY\SYSTEM:(F)
  NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
  BUILTIN\Administrators:(F)
  BUILTIN\Administrators:(OI)(CI)(IO)(F)
  BUILTIN\Administrators:(F)
  CREATOR OWNER:(OI)(CI)(IO)(F)
  machinename\Ctx_StreamingSvc:(F)
  machinename\Ctx_StreamingSvc:(OI)(CI)(IO)(F)

That part not too interesting.  

The GUID_v directory that holds the application content is below the RadeCache.  The below taken from my Windows Server 2003 test machine while running an application as user "U1". 

. machineordomain\U1:(RX)
  machineordomain\U1:(OI)(CI)(IO)(GR,GE)
  NT AUTHORITY\SYSTEM:(I)(F)
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
  BUILTIN\Administrators:(I)(F)
  BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
  CREATOR OWNER:(I)(OI)(CI)(IO)(F)
  machinename\Ctx_StreamingSvc:(I)(F)
  machinename\Ctx_StreamingSvc:(I)(OI)(CI)(IO)(F)

The thing to observe is that the user rights for the directory space are runtime added when the application is launched, and runtime removed when the application terminates.   Even while the application runs, the user cannot see the RadeCache directory itself.

Here's how the user sees it.

C:\Program Files\Citrix>dir radecache

Directory of C:\Program Files\Citrix\radecache

File Not Found

Same user, this time "look deeper" to see the directory space that supports the execution of the application that they are currently running.   You have to "know" the GUID to have this work because you can't directory scan the RadeCache.

C:\Program Files\Citrix>dir radecache\0561beac-e4b8-47d8-8a71-fe5752f330f9_3

Directory of C:\Program Files\Citrix\radecache\0561beac-e4b8-47d8-8a71-fe5752f330f9_3

08/07/2009  10:31 AM    <DIR>          .
08/07/2009  10:31 AM    <DIR>          ..
08/07/2009  10:30 AM    <DIR>          Device
05/06/2009  06:23 PM                 2 FontData.dat
08/07/2009  10:43 AM            24,340 Hashes.txt
05/06/2009  06:23 PM         1,295,137 InstallRoot.tab
05/06/2009  06:23 PM                 2 Preextract.txt
05/06/2009  06:23 PM            28,265 SandboxData.xml
08/07/2009  10:31 AM    <DIR>          Scripts
08/07/2009  10:43 AM            35,565 TempSandboxData_2b264684-41d7-40eb-9c69-b
cb32beba720.xml
               6 File(s)      1,383,311 bytes
               4 Dir(s)     662,564,864 bytes free

In the words of Bill Cosby, "That's kinda cool!". (1:54).  The user cannot see the RadeCache directory, but they CAN see the subdirectory.  This gets more fun when you change dir into the GUID_v directory, which succeeds, and then "cd .." to get to the parent, which fails.

Why bother?

1) Citrix Security people are paranoid and just want dev folks to write extra code

2) Prevents users from even seeing applications that are not published to them.

The answer is "2".

XenApp Server side execution

All this DACL stuff happens whether stream to client or stream to server, but the dacl benefit is important mostly for the server side case.  If there are 50 users on a XenApp server and only 10 of them have access to "very secret application", then only that specific set of 10 people will be able to even SEE the executable, much less run it.  Compare this to locally installing the "very secret application", where users can see the program files space for the application even if it isn't published to them.  In the streaming case, they can't see it in program files, and they cannot see it in the RadeCache. 

What about the file server?

The Application Hub holds the executable content and making things secret means that users must be restricted from seeing things on the Application Hub in addition to the execution machine.  Admins I have queried on this have replied "simple, I use the same groups to publish applications as I do for granting read access to the sub-directories on the Application Hub". 

This is why the profiles are all stored as sub-directories off of the root of the "profiles".  Everything related to a given profile is in a single directory.  This creates an extra step to find the .profile in the streaming profiler file open dialog, but it really helps to simplify the DACL management.  This is also why the Streaming Profiler doesn't let you enter the full path to the "save to" location.  The use of "profilename\profilename.profile" is required for this to work, so the streaming profiler prevents you from using other forms when saving.

Joe Nord

Product Architect - Application Streaming