I get this question less often recently than I used to but it still shows up.  

• Can Application Streaming be ported to Apple Mac or Linux? 

The question is usually based on the idea of wanting to run XenApp published streamed applications in an isolation system on the foreign operating system.  That is, to bring streamed Windows applications to the other system. 

You can insert your favorite operating system on the above list, but the answer remains the same, no.

APPLICATION ISOLATION is about changing things and lying to applications so that they think they are doing one thing when they are really doing another.  Fundamentally though, the executed application is still a "native" application for the operating system.  The executed Windows based application is still a Windows based application and it will not run unless something exists below to satisfy the Windows APIs.  The application won't even load unless the Windows loader brings it into memory.

Can you use App Streaming on Mac?  SURE! 

Insert your favorite MACHINE virtualization system such as Parallels, install Windows into the virtual machine, install the streaming client (aka: offline plug-in) and then run all the applications streamed that you want.  This works fine! 

Is it "streaming" to the Mac?  No! 

I see people around Citrix doing this all the time.  They run streamed MS Outlook 2007 and happily check their email and do many things of their job, all day long with lots of apps.  Many of them spend most of their day inside the Windows environment of the Mac machine.

In this usage, I call the MAC the ...

• THE WORLD'S LARGEST WINDOWS LOADER!

For the non programmers in the room, the "loader" is the component of the operating system that is responsible for bringing the operating system to life.  The quick version goes something like this:

The machine powers up and and a whole bunch of things happen, but eventually the hardware kicks off the machine loader from ROM in "real mode" at address CS:IP FFFF:0000, this kicks starts the BIOS.  The BIOS h has the job of finding a 512 byte sector of disk, loading it into memory and "jumping" to it.  From the BIOS perspective, at this point the machine is "booted".  The 512 byte initial loader, brings in a bigger loader, which brings in a bit more, which brings in a primitive part of the operating system, which brings in some "boot" device drivers such as "disk" boot load device drivers, which brings in more of the operating system, which loads more device drivers, like NTFS, enables paging and does a bunch more stuff until you eventually get a machine, running and ready to do useful work.  You can make a career out of any of these activities.

In my mac example without machine isolation, the Mac must boot first and once it's done, it loads the virtual machine thingie which "powers on" the x86 box, which does a bunch of things, which then runs from "ROM", which is really "RAM" and jumpts to a "real mode" address FFFF:0000 and then boots the Windows machine.

This continues on until the Windows box is ready to do work => ergo, the Mac is the worlds largest Windows loader.  While boot sequences are fun, I am way off topic.  

Can you run App Streaming based apps on a non-Windows platform?

Answer the question with a question:

• Can you run WINDOWS based applications on a non-Windows platform?  Answer no.

Sometimes this answer receives a follow up: Have you considered adding this capability?

Now, a white-board is needed.  We use a white-board because nobody has chalk-boards anymore.  Frankly, I prefer the old style because they could be readily and reliably erased, but I'm digressing away from the topic.

How much slower does a streamed app run compared to a locally installed app?

Answer: They are the same!  CPU wise, it's the same.  A process is a process is a process and program code is program code.  The isolated app runs NATIVE on the machine.  It is loaded by Windows and the app uses Windows to do things that apps do with Windows. 

Eventually, the program may call a Windows API, such as RegOpenKeyEx or CreateFile.  When this happens, the program execution takes a brief side journey through the isolation system where the parameters to the API are "adjusted" to make the application run inside of an "isolated environment".  This is how the layers of glass are implemented.

The application is still an application and it is still dependent on the Windows machine for running the application.  Things do get a bit more complicated because even DOS apps running on the Windows machine can be isolated (link), but fundamentally, Application Isolation "adjusts" the execution of applications that are running native on the Windows machine.

Finally, the question can be answered: You can't run "isolated" Windows apps on a non-Windows machine, so there is no point is worrying about running App Streaming under MAC or Linux or others.

What about App Streaming to Windows XP Embedded?

Sure, that will work and this has been done. 

What about App Streaming to Linux under Wine?

Sounds like an interesting activity.  I'm quite sure it won't work, but there could be other neat things.

Enjoy!

Joe Nord

Citrix Product Architect - Application Streaming and User Profile Manager

We had some studio time available recently and took the opportunity to capture the alpha version of Citrix XenClient as you've never seen it...in HD. We thought it fitting given our ongoing dedication to HDX technology in both the Citrix XenClient and Citrix XenDesktop platforms.

Before we get to the videos, let me take just a few moments to review some basics about Citrix XenClient.

XenClient is a bare-metal local desktop virtualization platform based on the same technology that goes into Citrix XenServer including the open-source Xen hypervisor. Translation - XenClient allows you to run multiple virtual desktops locally on the same device, in complete isolation with kickass performance and graphics. Much of the credit for the performance can be given to the hardware-assisted virtualization in the Xen hypervisor combined with the work that Intel has done to give you the same great performance and user experience on your virtual desktops as you would expect on a physical laptop (or desktop).

Watch the XenClient Overview(1 minute)

There are many benefits to bare-metal desktop virtualization. One of the more obvious benefits is performance. We could go into all the ways a type-1 harware assisted hypervisor does that, but thought it might be easier to just show it.

Watch Citrix XenClient HDX Performance (2:30 minutes)

Pretty cool huh? Stay tuned for parts 2 and 3 where we will show off the use cases for XenClient as well as its ability to keep your computing environment secure.

Watch all four videos in the XenClient series or visit XenClient Central for more information on XenClient.

Hämta ner XenDesktop 4 och kom igång med den snabbaste och mest flexibla lösningen tillgänglig idag på marknaden för att få ut Windows 7 till alla användare.

XenDesktop 4 - Platinum Edition
Release Date: 11/16/2009

Ge användarna en bättre multimediaupplevelse med HDX™ technologi, leverera Windows 7 till både fysiska och virtuella klienter med FlexCast™ leveransteknologi.

Det enda du behöver för att komma igång är lite hårdvara, kolla quick guiden, den är användbar för att komma igång om du vill använda flexcast. Annars är det ganska rakt fram med övriga komponenter, det har aldrig varit enklare än såhär att komma igång med klientvirtualisering.

Om du är återförsäljare/Citrixpartner och loggar in med ditt konto finner du även riktigt bra quick guies och proof of concept checklistor, designtemplates osv

Today's the big day. November 16, 2009. XenDesktop 4 is here! The final XD4 software has been posted to the Downloads page on MyCitrix and both Evaluation and Retail licenses are now available. Likewise, final XD4 documentation has been published on our eDocs site. So I'd like to publicly congratulate our Engineering team for delivering a truly outstanding product release. 

The enhancements in XenDesktop 4, summarized in a previous blog post, have resulted in the most comprehensive desktop virtualization solution on the planet. With FlexCast, we deliver the best desktop for each user in the organization; a hosted shared desktop (Terminal Services / RDS), a hosted VM-based desktop (now including Windows 7), a blade PC or rack workstation based desktop, a local streamed desktop, or virtual apps on a physical laptop or desktop. And our HDX technologies ensure an optimized user experience for every access scenario. You can learn about HDX in my recent 18-minute video seminar with Sridhar Mullapudi on CitrixTV, which includes demos of many new HDX features.

So download an evaluation copy and check it out for yourself. Now is the time to rethink your desktops and join our desktop virtualization revolution!

Derek Thorslund
Citrix Product Strategist, HDX

Join Citrix and Microsoft for this upcoming webinar on November 19th, 2009 at 1:00 PM EST-

Event Date: 11/19/2009 01:00 PM Eastern Standard Time

Have you started planning to migrate to Windows 7? Struggling to continuously update and patch endpoint devices for new application releases and updates ? Data residing on end point devices creating potential security risks? Continuing to follow the decades-old PC refresh cycle and traditional distributed desktop model is a poor choice for IT departments that face reduced budgets and headcount. Join Citrix and Microsoft in this webinar to learn about the only industry leading desktop delivery solution that will enable you to:

• Radically simplify desktop management
• Increase business agility
• Reduce desktop and application management costs
• Right & wrong reasons to implement desktop virtualization
• Improve security
• Accelerate enterprise wide deployment of Windows 7
  
  http://event.on24.com/r.htm?e=175014&s=1&k=03BEDE18A207B107B57E59BBFB11A8B9
  
  
  
  Follow me on Twitter.

As the Citrix Architect of Application Streaming AND Architect of Citrix Profile Manager, you might infer that I'm interested in leveraging one technology to help the other. 

Background on roaming profiles and Citrix Profile Manager

First, background on Windows "roaming profiles" and similar.  Consider that when a user logs onto a machine, the logon activity must "roam" or "copy" the network stored version of the user's profile onto the execution machine.  In the general sense, everything on disk beneath %USERPROFILE% or C:\Users\usename, will be copied onto the execution machine at logon and then copied back to central store at logoff. 

During logon, this is a "large" consumer of logon time where it consumes perhaps the largest portion of the overall logon clock.  With roaming profiles, this full copy happens every time, but with efficient systems such as Citrix Profile Manager, the "copy" is actually a "sync", so the copy happens really fast and the copy back is limited to only the files that changed.   While this also speeds logoff time, let's stick with the value of logon time because ... nobody cares how long it takes to logoff.

Where all of this stuff gets more interesting is when you consider a user logging on to XenApp hosted session or logging onto a hosted XenDesktop session where a common disk image is used for the base operating system.  Notice that in each of these hosted cases, the user's profile on the execution machine is initially "empty" and it will be initially "empty" on every logon.  This means that the glorious logon sync that the Citrix Profile Manager does at logon will actually be a "full copy" and here, it starts to behave with the same inefficiency as the base operating system profile solution because it will be a full copy at EVERY logon.  We like to do better than this.

For a more detailed introduction to Citrix Profile Manager, consult this Sepago white paper.  Recall that Citrix Profile Manager is based upon the Sepago Profile technology that Citrix acquired some time back.

Use "streaming" to solve profile population
Logical move: Instead of copying stuff onto the machine at logon, use isolation technology to LIE to the system to tell it everything is copied local when it is really still on the central store.  Eventually, when the system or an application references stuff in the user profile, go fetch it and make it present.  This is "just in time" population and it has the promise to greatly improve logon time in a hosted environment.

For JUST IN TIME population, the bet goes, some large portion of the user profile will never be referenced, so you save big on the logon speed and you save big on the runtime because much of what exists in the user profile will NEVER be copied to/from the central store.  This means that using a just in time profile solution will save LOTS of time for logon, and this is a great benefit!

Great - How much quicker?

The answer: LOTS QUICKER!

Yes, but do you have a number?

I'd like quote: Just in time Profile Manager speeds XenApp logon by 100%  

My gut says that the number is closer to 40% - 50%, but I don't have any hard evidence and thus the premise of this blog post...

Getting a "number" is harder because the answer is that "it depends".  Marketing people and customers prefer hard integers.  The integer number is hard to dream up because the answer depends on the size of the user's profile and the efficiency of network activity to/from the central profile store to the execution physical machine or virtual machine.  The BIGGER the profile, the more efficient.  If the profile is zero size, then JIT doesn't do anything and if the profile size if infinite the the JIT logon benefit is also without limit.

So, the answer for the logon value of just in time is is somewhere between a 100% benefit and 0%.  This doesn't help.

Let's go with an example:  The profile on my primary computer is 11GB, yes Gigabytes.   I could be a rare case.  This is pretty close to "infinite" so I will save plenty in an average logon.  

It turns out that 10 GB of my 11 GB profile is a TrueCrypt encrypted hard disk container.  I'm sure glad I'm not copying that down from a central store on each logon!  In a hosted VDI, I would be.  Technically, I'd store stuff differently, but in concept I'd be copying this down.  In a hosted XenApp execution with just in time, I would never copy down this file so Joe's benefit of just in time will be either 0% or 100% and nothing in the middle.  This still isn't helping me come up with a number.

For my normal machine, I am not connected to profile manager or roaming solution or even to a domain so my system may not be the perfect example.   As XenDesktop becomes more and more prevelant though, the strange things that users do to populate their user profile will make examples of users doing stupid things like placing 10GB files into the user profile more and more common.

If you are using the same profile for the primary hosted desktop as well as numerous XenApp server based app executions, you experience the victory!  Only ONE of them will be accessing that really big file.

In my case, the primary machine will access the really big file, but all the "vacation request" and similar applications that I run will run on another computer, where the really big file will never be referenced.  Using just in time population of the user profile, the majority of my logons and I'll say that ALL of my quick in/out sessions will have a HUGE benefit to not copying down that 10GB file!  This will make my logon time benefit near 100% on these other sesions and near 0% on the machine where I do access that single file that is 90% of my user profile!  

It is much better to quote percentages on something like this, so the time saved will be some percentage of the overall logon time and the LARGER the user profile, the HIGHER the savings!  Okay, we're getting closer.

Right - what's the number to quote?

Let's start with a formula:

• TimeSaved = TotalTimeWithouJIT - TotalTimeWithJIT;
• PercentFaster = (TimeSaved / TotalTimeWithoutJIT) * 100%;
  

How to calculate "TotalTime"?  This number will be the sum of the entire logon, nobody cares how much more efficient the roaming profile copy is, they want to know how many SECONDS this will save on logon time and how much of a percentage faster the logon time is. 

This requires breaking down the logon time of a "NORMAL" logon.  What is a "normal" logon?

Need to have: Computers that are representative of a "normal IT shop".  Need networks that are also representative of "normal world" and network servers and end user machiens that are "normal".  Must simulate some kind of load on these machines or just take it as a given that the load during the test will be similar to all the other stuff going on with the test network at the time of the measurement.

The key ingredients are:

1. Size of the user profile.
2. Speed of the network.
3. Overall logon time 
4. Logon time used to copy the full user profile

Given the above, we tigger the measurement to figure out how much time is profile population and poof!  Take the total logon time, subtract out the portion spent copying the user profile without JIT and ... We have a number!

What's that number again?

What is the SIZE of an "average" user profile?  What is the average file size?  How many files are "normal". 

Do normal users have giant files inside their user profile?  Yes, they do!  If you have have you ever copied a .MPG file or .MP3 onto your desktop, then you're as guilty as I am.  The PROFILE WILL GROW and will be large.

How large?

We need to exclude some files.  What about the files that will NEVER copy onto the execution machine even ignoring just in time.   Some stuff like "My Documents" will not be roamed, but will instead be accessed straight off the network via folder redirection.  This is "standard procedure" for setting up profile environments and here, "just in time" doesn't have any effect.

Let's get to statistcs.

Start with the initial 11GB and take out that 10GB file that is an anomaly and I'm left with 390MB.  The missing 610 MB is round off error.

Administrators usually redirect "My Documents".  Take out Joe's "My Documents" = 208,055,865 bytes and I'm left with 182,450,081 bytes.

Okay, I wonder what I have inside my USERPROFILE that could possibly constitute 182MB?   Dig deeper.  I have 24 MB of pictures!  While I am sure that they are lovely - I am also sure that I haven't looked at them in months.  If I were "server side" my admin would probably redirect "My Pictures" too.  Now I'm down to 158MB.

Keep looking....  BING BING BING BING BING!!  We have a winner.  I have 149MB of "Downloads".

First - before anyone starts, "Downloads" have ZERO relation to the 24 MB of pictures!

Something is wrong here because after you subtract all this out and I'm down to 9MB of stuff that wouldn't normally be "redirected" and I KNOW that NTUSER.DAT on my machine is 8.9 MB.  This leaves me with 100KB of stuff that is candidate for JIT value.  There's a number breakdown here someplace, but let's keep it going.

Pretty soon it's obvious that I don't have ANYTHING in the user profile that matters.  I store it all in that huge the container file and in "other places" on the hard disk.  In a hosted case, these "others places" would find their way into the user profile, so all my utilities would be a plus for the profile.  Go looking...

What are "other places".

Utilities.  I have lots of them and store them off the root.  In a hosted desktop model, they will be in the user profile.  Add in 137 MB.  I have 77 MB of sound .wav files left over from my days of writing audio device drivers.  These would almost never be accessed, but they would live in my user profile.  Batch files.  They are kept separate from executable utilities, so add in another 9 MB and utilities and 33 MB of Windows SYMBOL files for debugging stuff.  137 + 9 + 77 + 33 = 256 MB of additional stuff for the user profile.

I love it when numbers come out to a power of 2!

One number:  "Average" user profile size is 256MB!

Yes, I left the 10GB file out of this mix.  That quantity of storage just has to kind of go away from the calculation.   I hear numbers of 20-30 seconds of XenApp logon time being required for copying down user profile content?  If we can make this number be "zero", then there can be real value in just in time profile solutions.

Add in some stuff that would be moved from my container file onto the user profile and I propose that the real size could easily double. 

Joe's proposal: The Average size of user profile is 512MB!

If any of this math makes sense, then I have an example number set that can be used to construct a measurement.  Is 256MB the right number?  Is 512MB the right number?  How about 1GB?

Real world statistics are the elusive number.  If you happen to have a couple hundred profiles representing a years worth of regular hosted desktop usage and wouldn't mind sharing, please send me an email or comment below.  

THANKS.

Joe Nord
Product Architect of Application Streaming, Profile Manager and a few side projects
Citrix Systems - Fort Lauderdale, FL

PCoIP is VMware's latest attempt at delivering a decent user experience for a virtual desktop. After failed attempts with RDP, Sun Ray, RGS and TCX, VMware View 4 is betting that a software version of the PCoIP protocol will deliver the great user experience customers demand from a VDI solution.

I've been in the virtualization business for many years. Currently I lead the HDX technology for XenDesktop. In the past I've worked on tons of projects for the ICA protocol including CGP, Secure Gateway, and Thinwire. In recent years I've led the Apollo project which has created technologies now in XenDesktop 4 like HDX MediaStream for Flash, HDX 3D Pro Graphics, HDX RealTimeand HDX Broadcast. So I've watched with amusement as VMware attempts to position PCoIP as the next great remoting protocol. The three most amusing 'marketing' tactics about PCoIP are:

PCoIP bets on UDP as the foundational transport for graphics
One of the major design flaws in PCoIP is that it relies exclusively on UDP for deliver bitmaps. UDP is valid for some narrow use cases but PCoIP relies on it entirely. When you need a reliable transport, TCP is a much better option. The fact that PCoIP has application-layer packet reliability shows you need reliable delivery for desktop graphics. If all you are doing is playing a video, fine... but that's not what a virtual desktop is all about. You may not know this but many years ago, ICA supported a datagram-based protocol with application-layer reliability just like PCoIP. Since then, we have learned that TCP is the ideal transport for delivering desktop graphics over the network. It is also friendlier to firewall and network infrastructure. And it is cheaper to deploy as customers can leverage their existing network infrastructure.

PCoIP claims bitmap remoting is the best way to deliver graphics
Another interesting aspect of PCoIP is that the protocol is based on the idea of sending bitmaps. No wonder, since their hardware solution used as input the DVI port of the graphics card. It is interesting that VMware claim that sending bitmaps is better than sending graphic primitives. This is a half truth. While sending bitmaps make sense in some scenarios, sending graphic primitives is much more efficient in other scenarios. Think of this, what is more efficient when sending a 400x300 rectangle with black borders and white background? As a bitmap or sending a RECT command with both upper left and lower right coordinates? The key is to be smart about it and know when one scenario makes more sense than the other. That's what we call SmartRendering. Getting this right is very hard and it has taken us years of fine tuning. But a half truth is convenient because sending bitmaps is the easiest thing to do, after all, that's all most graphic remoting protocols can do.

PCoIP relies primarily on the server to do all the heavy lifting
PCoIP also focuses on the use of server resources to deliver the graphics. But you soon realize that does not get you far enough. I have spoken with countless customers asking us to solve their scalability issues with playing Flash multimedia. I'm sure VMware have shown some YouTube videos to get people excited but you have to look at the CPU and bandwidth consumption. The Flash player uses up lots of CPU, so if your only available solution is server-side rendering then you are going to need a lot of servers. Customers need solutions that scale, are cost effective and leverage their computing resources in the data center and also on the user device. PCoIP fails to do this because it is an incomplete protocol.

Delivering a complete solution takes time and it's hard, very hard. I see PCoIP making some of the same mistakes we made 15 years ago. I congratulate them for trying, but they have a long way to go.

To deliver a great user experience you not only need a robust protocol, you need all the components in the delivery infrastructure working together to optimize the delivery of virtual desktops and applications. This is what we are doing with HDX at Citrix.

Follow me on Twitter

Klientvirtualisering är ett hett ämne nu när alla ska ut med Windows 7. Att göra som vi alltid gjort är inte tillräcklgt, det tar alldeles för lång tid och är på tok för dyrt.

Som vi alltid gjort?! - alltså köpa nya servrar, uppgradera nät och köpa nya datorer.
Windows 7 fungerar utmärkt även på inte helt ny hårdvara vilket bara det ger oss möjligheter att låta klienterna stå kvar på skrivbordet och leverera ut operativet med nya metoder.

2008 åkte jag land och rike runt och pratade VDI, virtuell klienthantering. Ärligt talat måste jag medge att det var flopp, vissa gillade tekniken och testade omedelbart att lyfta in några klienter i serverrummet men då man ganska snabbt insåg att man då får en ytterligare klientinfrastruktur parallellt med sin traditionella kom svaret ganska snabbt att så länge man inte har en lösning för ALLA klienter eller scenario blir det ganska kostsamt att underhålla flera plattformar.

2009 pratar många fortfarande VDI trots det faktum att det är en brake/fix lösing. Jag träffar om inte dagligen men ändå ganska ofta företag och organisationer som laddat upp ett antal klienter i sin virtualiseringsplattform för att några veckor senare falla på antingen dubbel administration eller ökade kostnader.

Att virtualisera ett antal servrar var för några år sedan en utmaning men idag är det standard för de flesta och vi står någonstans motsvarande i utveckling på klientsidan. Det jag reflekterat över är att det ofta är servergruppen som nu även börjar ta över klienterna och ger sig på klientvirtualisering. Inget ont om serverkillar, de flesta jag träffat är extremt kompetenta men ärligt talat: - Det är rätt stor skillnad på klienter och servrar.

I min värld ska klienter skapas dynamiskt efter behov, man ska inte behöva scripta och mecka så mycket bara för att tillhandahålla några hundra datorer och självklart har alla användare inte samma behov. När vi skickar in alla klienter i serverrummet löser vi bara ett (1st) problem och därför är det så viktigt att se det här med klientvirtualisering utifrån ett helt annat perspektiv.

Vad är en klient?

• Hårdvara i någon form av pc, fysisk eller virtuell
• Operativsystem, Windows XP, Windows Vista eller Windows 7 i många fall
• Applikationer
• Personliga inställningar/konfiguration
• Åtkomst

Jag väljer att dela upp en klient i fem delar även om vi kan dela upp ex. hårdvara i flera olika delar som ex. nät, hårddisk som också bör beaktas när det gäller effektiv klienthantering. Men vi tar det lite längre fram. Om man inte bryter isär dessa komponenter kommer man aldrig att lyckas med sitt klientvirtualiseringsprojekt - hur kommer det sig?!

Jo, min tes är att klienter förändras betydligt mer ofta än servrar och om vi beaktar kombination av behov från ett användarperspektiv är det betydligt mer "spretigt" i jämförelse med serverhanteringen som ofta ska fylla en funktion och dessutom i server rummet. Vem märker om en server är virtuell eller fysksk? Man ska bara ansluta mot den och den ska fungera.
Då de flesta är bekanta med virtualisering i form av nät (ex. VPN och VLAN) samt servervirtualisering har jag valt att börja i den änden även när det gäller klientvirtualisering men här är det viktigt att inte blanda ihop hårdvaruvirtualisering med operativssystemsvirtualisering och operativsystemsleverans och operativsystem installation. Vad är då skillnaden?
Genom virtualisering av hårdvara kan vi möjliggöra flera saker men viktigast i klientvirtualiseringssammanhang är möjligheten att köra flera klienter på samma fysiska hårdvara. Det löser en sak, bättre nyttjandegrad eller densitet på fysisk hårdvara men om vi väljer ett spår som endast klarar virtualisering kommer vi aldrig att kunna tillgodose alla användares behov. Här kommer operativsystemsvirtualisering in i bilden. Alltså möjligheten att tillhandahålla ett operativsystem till både fysisk och virtuell hårdvara

I år när jag kört mina "seminarier" runt om i landet har jag kört "live" och jag tror det är vad som krävs nu i dessa virtualiseringsförvirringstider. Det är nästan helt omöjligt att berätta med ord hur det fungerar men att visa/-se live ger en helt annan förståelse för enkelheten/storheten .

Tips på Citrix TV filmer - www.citrix.com/tv

• How to: Design XenDesktop for the Small Business
• How To: Install Web Interface 5.2
• How To: Deploy Citrix Clients via Web Interface 5.2
• How To: Create a XenApp Site in Web Interface
• How To: Create a XenApp Services Site in Web Interface
• Citrix Ready Spotlight Video - AppSense
• Free!! XenDesktop4 Express Edition
• How To: Use Wild Cards with Dynamic Window Titles in Citrix Password Manager
• How To: Use the Agent Logging Facility in Citrix Password Manager
• How To: Use the Control Matching Feature of Citrix Password Manager
• How To: Deal with Drop Down lists in Citrix Password Manager
• How To: Create a Basic Application Definition in Citrix Password Manager
• How To: Configure the Networking Settings of a Citrix Merchandising Server
• How To: Schedule a Plugin-in Delivery in Citrix Merchandising Server
• How To: Download and Install a Plugin-in from Citrix Merchandising Server
How to: Design XenDesktop for the Small Business

Do we really want to allow our users to have the ability to self provision / install applications? Won't this just cause mayhem and anarchy? How will we ensure that we are licensed to install the applications that the users choses to install?

Simon Rust, VP of Technology at AppSense answers these questions in an article he posted over of the AppSense Community Blog - Please find the post below:

These are a small sample of some of the obvious and key issues that the IT administrator needs to seriously consider when thinking about allowing the user to install applications of their own choice.

Just this week, @HarryLabana asked the following question via Twitter - "Are user installed apps a compliance nightmare waiting to happen?". A very sensible question that effectively is asking, "WHY should we even consider allowing the user to install their own stuff?"

To labor on the need briefly, it is relatively simple as to why we need to cater for it (we don't need to agree with it, but we do have to accept it to a certain degree ). Bottom line is that for years, there has been a challenge with packaging all the applications required by a user to conduct their daily duties. This is a challenge that traditional desktop managers have had for years, and now with desktop virtualization it is perhaps getting more noise. Unfortunately it is not going away any time soon, in fact may be getting worse as time progresses and the number of applications increases. If we choose to not allow users to install their own stuff, then how do we ensure that the user does not fall foul downstream of an application not being available and hence their inability to conduct their work? An obvious example would be the corporate user who uses Microsoft Live Meeting to conduct online meetings, who has a meeting booked with an organization that uses Citrix GoToMeeting. The GoToMeeting client would not be installed, and hence the user would only find this out 5 to 10 minutes before the session, and hence would be unable to join

AppSense Product Manager Chris Oldroyd (Twitter - @coldroyd) wrote about the various user installed applications a month or so ago and is well worth a read - What is a User Installed Application? And why should we care?

So, now we have accepted that we need to cater in some form or another, we can move on to consider HOW. The key aspects to delivering users with the ability to install their own apps is CONTROL - it would be insane (most would argue) to allow ALL users with the ability to install their own stuff. Very quickly the enterprise would find themselves in a situation where literally 1000's of applications have found their way in, and are posing a serious legal issue. It is (mostly) true that a typical enterprise using laptop devices has this very issue today, since the majority of users of laptop devices are administrators of them. There is usually a solid business reason (from years gone by) as to why the user is an administrator, whether that reason being a requirement to install printer drivers (pre Vista) or something like that. Typically, once a user has admin rights, it is nigh impossible to get them back again

Arguably this is all part of something called "User Rights Management" as well as "Personalization". Both of these are clearly becoming markets in their own right with vendors appearing in it regularly, and many other vendors morphing their solutions to fit the model(s) also

In order to deliver against the need, but to do so in that all important controlled manner, we need to enable / allow for the following (there will be more - these are just the key areas);

• Only allow certain users to install apps (AD group based / end point device based)
• Only allow those users to install from certain (internal) network location(s) - that way the enterprise can control exactly WHAT a user who is authorized to install can install
• Only allow those users to install applications from certain vendors
• Full reporting is required to enable the administration team to be able to see what is out there in a quick snapshot
• Full administrative override to enable rapid removal of any applications as necessary

The overriding point here is simple - user installed applications is NOT for everyone, but it will be for a significant portion of the user population, so we need to provision for it in some way - simply saying no will not cut it.

Thanks
Gareth Kitson
AppSense

Twitter - @garethkitson

Yesterday, Citrix announced the new Citrix Ready Open Desktop Virtualization program. Today, I would like to provide you with more details. The program is designed to ensure that organizations deploying virtual desktops have confidence that their deployments will deliver a true, high definition (HDX), multi-device experience for the end users as well as satisfy the security and management requirements of the IT organization

As you probably saw from our XenDesktop 4 announcement, Citrix's view of desktop virtualization is much broader than running a user's desktop in a hosted virtual machine (VDI) and is emerging in mainstream deployment with customers such as Emory Healthcare and Collier County Schools.  Citrix's FlexCast delivery technology enables the delivery of every major desktop virtualization model via XenDesktop. As IT organizations pilot and architect their the desktop virtualization solutions it quickly becomes evident that desktop virtualization requires a robust ecosystem of partners to ensure that, amongst other things, the deployment is fully supported in the desktop value chain, end user's USB devices that are attached to their desktops continue to work, user personalization of their desktops remains persistent and that their desktop are available via multiple modes of access.

At the center of the program is the open architecture of XenDesktop 4. XenDesktop 4 is the only desktop virtualization solution on the market with an open architecture that is designed, certified and tested to work with the wide variety of products customers already have in production, including all popular applications, servers, storage and backup systems, client devices (BTW, check out our new HDX Ready designation that ensures a truly awesome user experience), printers and desktop peripherals, security and desktop management software and systems management products. The Citrix Ready Open Desktop Virtualization Program incorporates over 200 Citrix Ready partners and covers more than 10,000 devices. The products are verified using the full reach of the Citrix Ready program... Citrix product engineering organizations; Citrix Ready partner engineering organizations; our community of technology partners, customer and resellers; as well some via third party venders who verify a range of products (for example, USB devices).

The program covers product categories from the data center to the desktop; from choice of virtualization infrastructure to choice of end user device as shown below. For more detailed information check out the Citrix Ready Open Desktop Virtualization program at http://www.citrix.com/ODV.

I have heard some rumors of the production level App Streaming service (radesvc.exe) dying at runtime.  In the reported failure, the administrator has configured the service for automatic restart to work past the issue and I have suggested that this is only masking the problem, don't do that!  The streaming service, like most NT services, should never die and I'd much rather cure the root cause than work around the issue. 

The realities of "real users" and "production use" sometimes necessitate doing things that aren't ideal in a theoretical sense so this advice cannot always be followed, which brings us to this post where I will bring vision to the perils and values of configuring the streaming service for automatic restart.

Put your FSFD programmer hat on

You wear this hat when you're writing kernel mode code.  You write the file system filter code for the App Streaming isolation system and this code has two primary purposes; file system filtering and process monitor for sandbox management.

As a FSFD writer, you are never allowed to die or the entire machine will turn blue.  Today's post is not about kernel mode things dying, its about application level things dying.

Put your NT Service programmer hat on

You wear this hat, you think you're powerful because you run with "higher privilege"; higher than mere apps.  You may even be considered part of the "system", but from the perspective of the kernel code, you're a mere app too and as a class, all of you are untrustworthy. When a service dies, the machine does not turn blue, but it is still bad!

What does the service do?
Among other things, it is responsible for launching all isolation sandboxes and placing applications into the sandbox for execution.  Here's a chart that brings some color to this description.  What isn't drawn in the below is that the service talks to the FSFD to define sandboxes and launch applications into sandboxes.

What does the File System Filter Driver do

The FSFD hangs out and implements file system redirection - the layers of glass for the file system.  It is also responsible for managing which applications are in the isolation spaces; yes, that's plural on purpose. On a given machine, especially on a XenApp server, the FSFD can easily be tracking 500 isolation spaces.  Consider that there is state data for each of these.  It isn't large, but it exists and the code that keeps track of this actually does it in a balanced binary tree, which seems like overkill until you get large number of isolation spaces.

In the service, you also have state data for each sandbox.  Here though the state data is allocated per-thread.  Put differently, each sandbox gets a thread and this thread and only this thread is used for communication with the kernel mode code.  In this way, a few things are achieved.

1. The streaming service doesn't have to have complicated logic to manage its sandbox state
2. The kernel code can gate who it's willing to talk to based on the thread of the creator
3. When the FSFD has work for the service to do, the service "always" wakes up in the right state.

For computer science stuff, these are all positive actions. 

The negative actions

The service isn't supposed to die without a graceful shutdown and it should only close gracefully if it isn't managing any sandboxes.  In practice, "non scheduled" terminate happens all the time during development and recent reports show, it can also happen during production. 

The FSFD tolerates service death.  Why?  Primarily it does this because it doesn't have any other choice. 

If the service dies, the kernel code, being all powerful isn't surprised by this action - it "observes" that the service has died, but there isn't a whole bunch it can do about it.

Consider an example

You have isolated applications up.  Let's say you have 10 of them running, from 5 different profiles.  This means that you have 10 applications running in 5 different sandboxes.

The service dies...

The applications are still running, but they have lost their support network.

Let's say that the application now issues a DIRECTORY ENUMERATION on stuff in the isolated space.  Normally, the FSFD gathers information from the service to satisfy this request.  This is how the FSFD "LIES" to the application to tell it that things are present that aren't really present.   In this case though, the service is "gone", so what does the FSFD do?  Answer: It does the best it can and "falls back" to AIE style N layer directory merge.  The directory enumeration is satisfied, but the files that are there via a lie will not be included in the directory enumeration results?  What effect does this have on the application?  Don't know - depends on the app, but in general the results are bad.  

If the application issues a file open, you'll satisfy it based on the things you can answer without the help of the streaming service.  This means that if the file is really present in the cache, the file open will succeed and if it isn't, it won't, or execution will drop down to a lower layer in the layers of glass to answer the file operation.

Will this work for the application?  Maybe.  Ideally, you'd like to terminate the applications, but terminating applications when users have stuff running and haven't saved their work is considered bad form.

New sandboxes are launched

Recall that new sandboxes cannot be created without the help of the streaming service, so here it is a given that the service has been restarted.  When the service loads, it contacts the FSFD to register itself.  The kernel code says "nice to have you back" - but there isn't a dag gone thing it can do to help the orphaned sandboxes from the previous run of the service.  All the "app level" state data is "gone" and there's no way to put it back together again.

New launches though can be handled.  When created, the FSFD notes who the service is and will communicate with this "new" instance of the streaming service to manage the "new" sandboxes.

During development this is cool!

When developing the code, if you are the NT Service writer, this is really really cool because you can write code, debug it, terminate the debugger (which unloads the service), change the code, compile it again, run it (which loads the service) and the FSFD will just plain deal with all of this.  Very fast for development; no reboots needed and you can even do all this stuff from a visual development environment like MS Visual Studio.

During PRODUCTION this is not as cool!

Being willing to take on new sandboxes means that auto-restarting the service can seem like a good idea.  The thing this overlooks is that the orphaned sandboxes are, well they don't have their support network and without the streaming service, directory enumeration and file opens are not going to occur correctly unless the streaming cache is completely full.

Put your ADMINISTRATOR hat on

What should you do?  Answer: Treat death of the streaming service with caring detail.  It should be investigated and fixed.  The Citrix support team will love this - Joe said we should report service death rather than restarting the service.  My response, the service should not DIE unless you kill it!  I'm pretty sure service team already has the report, so I'm really writing for the next person and hopefully by the time you read this, we'll already have it fixed....

How to work around.

Above said, if you get in this situation, run one app from each profile with "-e" populated RadeRunSwitches.  This will fully populate the streaming cache and will minimize cases where the application will fail a file open or directory enumeration.  Next - Turn "-e" off as it will command a full extract on EVERY App Launch and you don't want that.  Next step - get the service fixed.  In the mean time, you can auto-restart the service to get new sandboxes created, but just be sure you aren't using the auto-restart to hide a problem that really needs to be investigated.

Before people ask, I already have feelers out to the people that have seen the service die.  Hate to have this happen with production code, but the correct answer is to research the problem and make the fix.  Hopefully readers of this post will appreciate the open nature to acknowledge a bug that isn't widely seen.

Joe Nord
Citrix Systems Product Architect - Application Streaming.

If you have paid any attention to any articles relating to desktop virtualization, you will quickly see claims like:

• Will Windows 7 fuel desktop virtualization adoption
• How desktop virtualization eases Windows 7 Migration
• Windows 7 Drives Desktop Virtualization
• Windows 7 and Desktop Virtualization: The New Tools
• Windows 7 - The Desktop Virtualization Catalyst 

 
I could go on, but you get the point. The major thought is that Windows 7 and desktop virtualization go hand-in-hand, but how do you get there?  You are not only migrating the OS but you are also migrating to a virtualized desktop operating environment.  Is this too much change for an organization?  
 
NO.  This is the perfect time to make the move.  Think about it this way, we have the opportunity to start with a clean slate.  We can define the new operating system that completely aligns with the organization's policies.  We can provide an environment that self heals and is optimized each and every time a user connects.  But in order to achieve these benefits, we have to design the environment correctly.  We need to focus on
•    What do we include in our base desktop image?
•    How do we deliver the operating system to our end point (which might be a physical or virtual desktop)?
•    How do we integrate applications into the mix?  
•    What are the recommendations for allowing users to personalize their environment without impacting the business?
•    What are the best practices for providing a great user experience for any user over any connection?
 
These are some of the topics being presenting in this week's Microsoft TechNet broadcast focusing on "Accelerating Windows 7 Migration with Citrix and Desktop Virtualization"
 
The show starts on Thursday, November 12th at 1PM Eastern time and you can register here

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Desktop virtualization information: Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

Citrix Support is focused on ensuring Customer and Partner satisfaction with the support of our products. One of our initiatives is to increase the ability of our Partners and Customers to leverage self-service avenues for finding answers and resolving problems. A key area that the Support teams focus on is development a series of How To videos covering the most common questions asked in support.

To date there are over 40 How To videos covering 11 products available from Citrix TV. Over the coming weeks and months lots more will be added.

If you have a How To video suggestion or feedback on the current videos, contact us via one of the following channels:

• email AskSupport@citrix.com
• Tweet us @citrixsupport and @citrixreadiness
• Leave a message on our Facebook page - http://www.facebook.com/CitrixSupport

Current video series available on Citrix TV are:

• Citrix XenServer - http://www.citrix.com/tv/#series/137
• Citrix XenApp - http://www.citrix.com/tv/#series/131
• Citrix XenDesktop - http://www.citrix.com/tv/#series/135
• Citrix NetScaler - http://www.citrix.com/tv/#series/133
• Citrix Provisioning Services - http://www.citrix.com/tv/#series/136
• Citrix Web Interface - http://www.citrix.com/tv/#series/129
• Citrix Merchandising Server - http://www.citrix.com/tv/#series/124
• Citrix Password Manager - http://www.citrix.com/tv/#series/126
• Citrix EdgeSight - http://www.citrix.com/tv/#series/132
• Citrix Workflow Studio - http://www.citrix.com/tv/#series/130
• Citrix Access Gateway Standard Edition - http://www.citrix.com/tv/#series/134

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

Ubuntu 9.10に対するCitrix Linux Clientインストールメモです。

1.  まずクライアントをダウンロードします
   • http://www.citrix.com/English/ss/downloads/details.asp?downloadId=3323&productId=186&c1=sot2755
2. 以下のようにディレクトリを作成します。
   • mkdir /tmp/citrix/
3. ダウンロードしたファイルを上記ディレクトリにコピーします。
4. ファイルを展開します。
   • gzip -d linuxx86-11.0.140395.tar.gz 
   • tar xvf linuxx86-11.0.140395.tar 
5. 以下のようにセットアップコマンドを起動します。
   • sudo ./setupwfc
6. 以下のようにインストーラーの指示に従います。

Citrix Receiver for Linux 11.0 セットアップを行います。

Copyright 1996-2009 Citrix Systems, Inc. All rights reserved.

Citrix、Independent Computing Architecture (ICA)、Program
Neighborhood、MetaFrame、および MetaFrame XP は米国およびその他の国
における Citrix Systems, Inc. の登録商標です。Citrix Receiver、
Citrix XenApp、XenDesktop、Presentation Server、Citrix Access Suite、
および SpeedScreen は、米国およびその他の国における Citrix Systems,
Inc. の商標です。
Microsoft、MS、MS-DOS、Outlook、Windows、Windows NT および BackOffice
は、米国およびその他の国における Microsoft Corporation の登録商標または
商標です。

その他のすべての商標および登録商標は、該当する各社の財産です。


セットアップ オプションを選択してください。:

 1. Citrix Receiver for Linux 11.0 のインストール
 2. Citrix Receiver for Linux 11.0 の削除
 3. Citrix Receiver for Linux 11.0 セットアップの終了

オプション番号を入力してください。 1-3 [1]: 1

Citrix Receiver for Linux をインストールするディレクトリを入力してください。
[デフォルト /usr/lib/ICAClient]
インストールを中止する場合は "quit" を入力してください。:

Citrix Receiver for Linux 11.0 のインストールを選択しました。 /usr/lib/ICAClient.

インストールを続行しますか？ [デフォルト n]: y

CITRIX(R) ライセンス契約書

本コンポーネントの使用については、本コンポーネントと共に使用いただく
Citrix 製品に適用される Citrix ライセンス契約の条件に従います。本コン
ポーネントは、当該使用製品と共に使用いただくためにのみライセンスを許
諾されるものです。

CTX_code EPEUC_T_A42236

オプション番号を選択してください。:

 1. 同意する
 2. 同意しない

オプション番号を入力してください。 1-2 [2]: 1
インストール中 ...

使用可能なディスク容量をチェックしています ...

    使用可能なディスク容量 4898092 K
    必要なディスク容量 6267 K


続行中 ...
ディレクトリの作成 /usr/lib/ICAClient
コア パッケージ ...
ファイル許可を設定中 ...

Web ブラウザと統合中...
Web ブラウザが見つかりました。

統合が完了しました。
Citrix Receiver を KDE および GNOME に統合しますか? [デフォルト y]: y
GStreamer でこのクライアントからのプラグインを使用しますか? [デフォルト y]: y

セットアップ オプションを選択してください。:

 1. Citrix Receiver for Linux 11.0 のインストール
 2. Citrix Receiver for Linux 11.0 の削除
 3. Citrix Receiver for Linux 11.0 セットアップの終了

オプション番号を入力してください。 1-3 [2]: 3
Citrix Receiver for Linux 11.0 のセットアップを終了します。
 

なお、自分のホームディレクトリでインストールファイルを実行しようとすると以下のようなエラーが出力されます。

No target hinst.msg found under /home/masao/ダウンロード for ja_JP.UTF-8
Trying English...
Could not find hinst.msg under /home/masao/ダウンロード for en

Since the last months Citrix and Novell worked closely together to provide a solution for customers with Novell eDirectory in place. For the Desktop Delivery Controller and the Virtual Desktop Agents Citrix announced an official support statement which could be found here: http://support.citrix.com/article/CTX123281

Costumers with a synched Active Directory / eDirectory only have to be aware of their GINA chaining. http://community.citrix.com/display/ocb/2009/05/07/XenDesktop+and+Novell+eDirectory

For environments where no Active Directory is in place Novell Open Enterprise Server with Domain Service for Windows (DSfW) http://tinyurl.com/yze7y65 have to be installed and configured before XenDesktop.
Due the fact, that DSfW only accepts Kerberos and no NTLM calls the XenDesktop Active Directory Wizard should not be used to prepare the OU.

You'll need to configure the DDC and VDA without using an OU:
http://support.citrix.com/article/CTX118976

I've developed a little cool tool to configure both components using a simple GUI.

On the Desktop Delivery Controller:
1.Set Desktop Delivery Controller without AD OU to enabled
2.Press Set DDC Config Button

On the Virtual Desktop Agents (WinXP,Vista, Win7)
1.Enter the FQDN of the DDC(s)
2.Press SET VDA Config Button

For those of you who would like to set the DDC configuration by using ZENworks or Group Policies I've added an ADM Template (FarmControllers.adm) into the Novell Integration Tool folder.

Download: Novell Integration Tool

Note: This tool is not supported by Citrix Support and if you have any issues try to configure the VDA manually using regedit or leave me a blog comment.

Recently several customers and integrators have asked me about the ports used by XenDesktop and whether or not Citrix recommends changing them. Since the ports used by Citrix products are well documented in CTX101810, I will leave that topic alone. However, in this blog I will provide some guidance around the ports you can change, where the change can be made, and whether it is a good idea to do so.  Like any good news story, the information is provided in order of relevance.

Due to the amount of content, I have decided to break this blog into multiple parts, starting with the core XenDesktop farm ports. I will tackle the supporting technologies like Provisioning Services and the XenDesktop Setup Wizard later.

Note:   To make the port number change obvious I have used 5555 in all the screen shots below. Clearly, bad things would happen if you set all the components to the same port value.

Virtual Desktop Agent (VDA)

The VDA communication is actually two one-way communications between the Citrix Desktop Delivery Controller Service running on the Desktop Delivery Controller (DDC) and the Citrix Desktop Service running on the desktop.  The significance of that statement is that the two ports can be set independently and do not have to be the same. To confuse this more, the default for both ports happens to be port 8080 which is the default for the Microsoft Windows Communication Foundation (WCF) services used by XenDesktop. Since port 8080 is used by other services, such as internet proxies or McAfee, I highly recommend changing this port on both sides of the communication.

Desktop Delivery Controller WCF Port

During the install of the DDC, the WCF port for the Citrix Desktop Delivery Controller Service is automatically set to 8080 and cannot be changed. To change the port, wait until after the installation is complete. Unfortunately, you cannot change this directly from the Add/Remove Programs Control Panel. Instead, you need to run the DDCServices.msi package from the installation media. Choose Modify, click Next, and then set the new port number. Click Next then Install to finish the wizard. I recommend rebooting the server after this change. The screen sequence is shown below.

Virtual Desktop Agent WCF Port

Changing the WCF port on the Virtual Desktop Agent side can be done either during the initial install or afterwards using the Add/Remove Programs control panel applet. To change it afterwards, open Add/Remove Programs, choose the "Change" option for the Citrix Virtual Desktop Agent, select Modify, click Next, click Next on the Custom Setup screen, enter the port number and then finish the wizard. The initial sequence looks similar to the DDC install and is shown below. 

Although in the examples above I have set the ports to be the same for both components, this is not a requirement.

Database

For security reasons, many institutions run SQL Server on a port other than 1433. If you are running the database on a different port, you can specify this information either during the setup by selecting the Client Configuration button on the ODBC setup screen and entering the new database port. Below are the screen shots for changing the ports during the installation for SQL Server.

Alternatively, you can directly edit the C:\Program Files\Citrix\Independent Management Architecture\MF20.DSN file that is used by the IMA service. For a SQL server, you would just add the line Address=servername,port to the file.  Restart the Citrix Independent Management Service for the change to take effect. Below is a sample MF20.DSN file where I have specified a different tcp port for the SQL server.

[ODBC]
DRIVER=SQL Server
UID=XDSQL
Trusted_Connection=Yes
DATABASE=XenDesktop
WSID=XDDDC4
APP=Citrix IMA
SERVER=SQLSVR1
Address=SQLSVR1,5555 

Session Reliability

Session reliability is another port that companies often modify to increase security for remote access. Unlike the ICA port number, this port can easily be changed by a setting in the Access Management Console. When session reliability is enabled, the ICA client tunnels its ICA traffic inside the Common Gateway Protocol (CGP) on the session reliability port. The XTE service will then unpack the ICA packets and forward them to the ICA listener port on the server.  If you change the session reliability port, you cannot just stop and restart the IMA and XTE services instead you will need to reboot the server. The session reliability port can be changed in the farm properties as shown in the screen shot below:

Virtualization Infrastructure

Changing the port of the API communications is not recommended.  However, if you have changed the inbound port for the API on VMWare Virtual Center or XenServer, you can configure XenDesktop by specifying the new port number on the location URL for the Access Management Console and the Setup Wizard as shown in the screen shot below.

IMA Ports

Changing the IMA ports (2512/2513) used by the farm for communication is not recommended. The primary reason I do not recommend changing the IMA port numbers is because the vast majority of quality assurance testing is done with the default port numbers. However, if you feel so inclined, you can use the IMAPORT.EXE utility to set the IMA ports for the IMA service and CMC to different values. After running this utility, you will need to restart all the Citrix services or just reboot the server.

XML Service

The XML Service port can be changed on the Desktop Delivery Controller. However, changing the XML service port is not recommended as there have been several reports of strange behaviors after changing it. If you must change the port number, you can use the CTXXMLSS.EXE command-line utility to do so and use the same XML service port for all DDCs in the farm.

That is all I have time for now. I hope to the have the next set of ports for the supporting technologies out by the end of the month. If you found this helpful and would like to be notified of future blogs postings, please follow me on twitter @pwilson98. 

I got an interesting item in my inbox from a friend who was speaking with VMware about their VDI solution.  He asked me if the information VMware was telling him was true. He was especially curious because he knew I wrote the Citrix XenDesktop Enterprise Designreference architecture that VMware was referencing to talk about how much better View was. VMWare's approach is laughable.  They are taking a detailed consulting design document  and trying to compare it to the VMware View reference architecture, which if you read it like I have (wasted 2 hours of my life), you will quickly see it is high-level and full of marketing spin and provides no insight.  I, on the other hand, was trying to provide all of you in the community with insight into how to design a large, and complex customer environment with XenDesktop.  Anyways, I told him the angle they were using and he thought it was ridiculous.  I was going to leave it at that, but I've been seeing and hearing more about it from others so I thought I would provide all of you with the same information.  Let's break it down: 

Scalability:

• Misconception: VMWare says that XenDesktop has poor hypervisor scalability. They say that on a 16 core server XenDesktop can only support 40 users (3 users per core). 
• Truth: The XenDesktop reference architecture for the hosted virtual desktops is 8 cores, not 16.  In the design phase, we estimated 40-50 VMs per server, which averages to 5-7 virtual desktops per core.  We were a little conservative as we were not sure how the unique applications would impact the system.  But you can look at Project Virtual Reality Check scalability white paper to get a good comparison of XenServer and ESX.  Although the design VMWare references was for XenServer, the same estimates would have been used if the hypervisor was running ESX.

Storage:

• Misconception: VMware likes to say that XenDesktop is a storage pig in that we need a lot of storage associated with each virtual desktop. 
• Truth: This particular design had a requirement to keep a few system items persistent across workstation reboots so we recommended the creation of a local, persistent disk of between 3-5GB to store items like event logs, performance metrics, antivirus definitions, etc.  This is not NAS/SAN storage; it is the storage on the physical XenServer.  Think about it. You buy an 8 core server, install XenServer, which is small, and the rest of the local storage is wasted.  We utilize that for the persistent store of the virtual desktops.  This means we cannot do XenMotion on the virtual desktops, but most customers I've spoken to do not have this requirement.  After looking at VMware's reference architecture I don't see any level of detail as to the amount of storage they require.  I wonder why not. 

Workloads:

• Misconception: VMware states that they can get more users on a hypervisor than we can.
• Truth: This is all around scalability tests, which I'm not a fan of.  I can easily find you 5 tests that show XenServer is better and another 5 that shows ESX is.  The VMware reference architecture had users connected for 14 straight hours, seems like a long workday to me. I have a question for VMWare: What company did you create this architecture for where users would work for 14 hours? Please tell me as I do not want to work there.  As we all know, the most typical system hit is during startup and logon. So by expanding the session time from a few hours to 14, the overall average utilization rates can be significantly lowered, thus providing an inaccurate estimate to the hardware
• Truth: The Citrix Reference Architecture made estimates based on the applications and expected real user workload, not simple apps and 14 hour workdays.  VMware's reference architecture was based on standard scalability samples shown below. If this was an actual user workload, I totally want to work for that company because that job looks so easy:
  • Microsoft Word - Open/minimize/close, write random words/numbers, save modifications.
  • Microsoft Excel - Open/minimize/close, write random numbers, insert/delete columns/rows, copy/paste formulas
  • Etc

RAM:

• Misconception: The amount of RAM that VMware recommends in their reference architecture is nuts.  They say they can get 96 users on a server with 96GB RAM.
• Truth: If you subtract the hypervisor overhead you are looking at "USABLE" RAM of about 800MB per virtual desktop.  I say usable because ESX has probably enabled memory ballooning.  It is true that XenServer does not have memory ballooning, but I would recommend customers disable this feature for virtual desktops.  On XenDesktop projects that use the ESX hypervisor, I also recommend disabling this feature.  Users and desktops are more dynamic than server workloads, meaning the RAM consumption is going to fluctuate greatly.  If RAM starts to decrease to the critical threshold, what happens to the hypervisor?  It must free up memory by paging this to disk.  Isn't this an intensive system process that consumes more resources at a time when resources are scarce?

End Points:

• Misconception: Vmware talks about the end points and only focus on thin clients and end points that we can repurpose with a Linux OS or locked down Windows OS. What about the newer end points that organizations have already spent money on? 

• Truth: With VMware View you still will connect to the VDI desktop and idle your local hardware. Seems like a lot of wasted desktop resources to me.  XenDesktop, on the other hand, allows you to re-use those desktops as a local streamed virtual desktop. Don't be fooled, there is more to desktop virtualization than VDI.

Provision:

• Truth: Closer to the end, the reference architecture talks about the time to provision X number of linked clone desktops.  I'm not sure if this is automated or if an admin has to do each desktop one-by-one. I'll give VMware the benefit of doubt here and say it is automated, but taking 161 minutes (2 1/2 hours) to provision 500 virtual desktops seems long to me.  I personally don't think this metric is important, even though XenDesktop is measured in seconds.  If it is automated, you do all of this in the build out phase and not in production. So the time it takes is irrelevant to me. Why did they choose to include it? No idea

So my advice to anyone who is still reading this blog... Take everything you get with a level of skepticism.  Do your own due diligence and look at the details to see if things were glossed over or if an in-depth analysis and design was completed.  That recommendation even includes the materials I post.  I try to be open and honest in my blogs, white papers, TechTalks and videos, but I am a little biased to Citrix because they pay my bills. 
If you want to discuss more, or have further questions, then Ask the Architect

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• For the latest desktop virtualization information visit the Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

I had the pleasure of attending Gartner's Symposium and IT Expo in Orlando in October. Other than talking to a lot of customers and partners, I took time off between booth hours to attend sessions and I was especially interested in anything labeled "Cloud".
Gartner defines Cloud computing as a style of computing, where elastically scalable IT services are delivered to customers using Internet technologies. This is one definition, and there are nuances between private cloud services (which corporate IT can build inside of companies to be more responsive to business needs) and public cloud services, which will enable companies to rid themselves of IT and consume services from providers - just like manufacturers stopped having their own on-premise power generators and are now consuming power from a utility. As a member of the Citrix Consulting organization, I was curious to see what the thoughts on a transition to the cloud would be. There is a lot of press and talk about the cloud itself at this time and it is not surprising that Gartner sees Cloud Computing on top of the Hype Curve with at least 2 yrs to wider spread adoption. Before that can happen though, we will have to move through the trough of disillusionment, but after we get over the mild hangover, we can talk shop.
Gartner looks primarily at three different types of cloud providers:

• Infrastructure. Think providers of server on storage capacity a la Amazon EC2 and S3.
• Middleware: Think providers of application developer platforms like Google Apps and force.com.
• Applications: Think providers of applications that often run on the Middleware layer, such as salesforce.com, web-based email etc.

The piece that I was missing in the Gartner discussion was the Desktop in the Cloud, or Desktops as a Service (DaaS). Given that the public cloud mantra is still a bit in the future, this is not surprising, but the thought raises some interesting questions.
Unlike moving a few apps playfully to a cloud provider in non-production environment, moving a desktop into a public cloud requires a bit more thought. For one thing, the desktop must deliver the business applications and those apps often times need to talk to databases and file shares to be useful. Companies may actually keep this portion on-premise for the time being, so long as the communication from the cloud back to the datacenter performs reasonably well and can be secured properly. Consulting hint: Test the end to end response time to assess if this is feasible for your specific scenario. Given multiple regulatory questions such as "Who owns the data in the cloud? Who ensures compliance?" I would expect a lot of the backend data to remain in the corporate datacenter initially, even as desktops move to the cloud. Over time, networks will continue to provide ever increasing capacity and reliability, so the application latency introduced by backend resources is probably not necessarily going to be a showstopper.
So, let me go out on a limb and predict the future for Desktop in the Cloud (hosted virtual desktops running on shared infrastructure, accessed by end-user over public networks, used as the primary means to do work):

• Desktop in the Cloud will first be adopted by small businesses or for desktops with a limited number of apps. Host a desktop with a web browser, office productivity software connected to a cloud-hosted web server (or entirely web-based email) and maybe include software such as Quickbooks and you have a repeatable, low cost desktop that can be used from the office or from home for a low monthly charge. Employees use their own personal PC or laptop to access this environment and gone are the days where everyone directs their PC troubles to the guy or gal in the office who happens play video games in the evenings.
• Gartner stated in one session that ISVs will have to become good service providers to prepare for cloud computing. I actually disagree with that statement - it reminds me of the days when software vendors aspired to be ASP's. ISV's will have to provide software and licensing that is conducive to a cloud model. The software licensing will have to change to allow for hosting in the cloud and a subscription-based pricing model. Software and data ownership will need to be figured out and the cloud provider with the most straight forward legal terms will have a leg up.
• Desktops delivering a few critical apps will be next. Think call centers or the healthcare vertical. Those are fairly simple desktop implementations without a lot of application complexity or a requirement to let traveling users connect or work offline.
• Enterprise Desktops (those delivering pretty much any app and connect to a myriad of complex application back-ends) will be the most challenging and probably take the longest to achieve widespread adoption in a cloud model. One can imagine the offline use case being solved by streaming an offline operating system to an endpoint, and some of the emerging file synchronization solutions in the cloud ensuring that all corporate data is properly synchronized between online and offline usage.

One of the items that the industry hasn't figured out yet is a service level agreement (SLA) standard for virtual desktops. We have SLA's for servers and applications, but not for desktops, whose users are a lot less forgiving for latency for basic desktop interactions or the inability to access them. To establish and enforce SLAs for the desktop, end-to-end monitoring solutions are key that allow both the provider and the customer to pull reports on response times and overall system performance.

I remember one additional line from the Gartner Symposium keynote. According to their surveys, some 60% of CEOs believe that IT is constraining their business. What that tells me is that business leaders will need to have more trust in their cloud provider than they have in their own IT. Therefore, I predict that the Desktop as a Service providers of tomorrow will be the large system integrators. They are already trusted by many corporations to run IT end to end and have the expertise and backend capability to deliver hosted services with strong SLAs and security.

Florian Becker
Director, Worldwide Consulting Solutions
Follow me on twitter: @florianbecker

Citrix Support is focused on ensuring Customer and Partner satisfaction with the support of our products. One of our initiatives is to increase the ability of our Partners and Customers to leverage self-service avenues for finding answers and resolving problems. A key area that the Support teams focus on is development of troubleshooting and health checking tools.

One of the most recent tools to come out of Citrix Support is the Citrix Printing Tool.

The Citrix Printing Tool helps configuring and troubleshooting the Citrix Printing subsystem on XenApp, XenApp Online Plugin, and XenDesktop products.

You can download the Citrix Printing Tool here.

Also find below a video by the tools developer Frederic Serriere, providing an overview and demo of the Citrix Printing Tool.

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

I wanted to take a moment and provide some thoughts around selecting the correct logoff behavior for your XenDesktop environment. When working with a pooled desktop environment, the administrator can choose between restarting the virtual desktop at logoff and doing nothing.  Below is a screen shot of the two settings I am referring to for a pooled desktop group:

When selecting a logoff behavior, administrators should consider the operating environment since selecting the wrong logoff behavior could have a negative impact on your user experience. In order to see how this could be the case, let's first look at the logoff process and then apply it to a simple customer scenario. Here are the steps executed when "Restart the virtual desktop" is selected for the desktop group and the user logs off:

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.
2. Desktop Delivery Controller initiates the shutdown and restart via the pool management service.
3. If the DDC contacted is not the farm master then the request is routed through IMA to the farm master and then executed.
4. The farm master sends a desktop shutdown command to the hosting infrastructure. 
5. If the idle pool count is not met the Desktop Delivery Controller then sends a startup command for the desktop to the hosting infrastructure.
6. The desktop boots up, and if streamed from provisioning services anywhere from 90MB (XP) to 220MB (Vista) of data will be sent over during the boot process for the desktop.

When the logoff behavior is set to "Do nothing" the following sequence is executed for each user logoff.

1. Virtual Desktop Agent notifies the Desktop Delivery Controller of the user logoff event.

Probably obvious now is that a significant amount of overhead is avoided by not restarting the desktop each time a user logs off. Now the question for administrators is "when does not restarting the desktop make sense?"  In most situations, restarting the desktop is the best answer. However, there are some situations where restarting the desktop after each logoff will impact the user experience. Consider the following basic XenDesktop configuration:

• 2 Desktop Delivery Controllers
• 500 virtual desktops hosted on 10 servers in a single resource pool
• 2 Provisioning Servers hosting a single Windows Vista vDisk used by all 500 desktops

If the 500 desktops in above example are supporting 1200 users across three shifts (400 desktops per shift) then during a shift change the amount of overhead caused by restarting the desktops could be significant and easily introduce user logon delay. When 400 users logoff in a relatively short time span, say 15-20 minutes, you would end up with 400 desktop boot processes occurring. If we pick the longer 20-minute interval, and assume even distribution (best case), that is 20 desktops per minute that will need to reboot (400 desktops/20 minutes).

If you are using Provisioning server to deliver Windows XP desktops, you have 90MB of data traversing the wire for each of those desktops and considerably more for later desktop operating systems. In addition, some hosting infrastructures have a limitation of how many desktops can be started within a given time period for a single resource pool or server. Furthermore, if the XenDesktop farm master is throttled (usually by a registry setting for performance reasons see the XD Best Practices Guide) and has a limited number of outstanding VM management commands then the 400 restart commands will get queued thus further slowing the end user's response time.

As the number of virtual desktops in the environment increases, the impact of a restart becomes more noticeable. For instance, if we were considering 5,000 desktops across 2 resource pools with the same 3 shifts and 80% utilization, the number of desktops being rebooted in a short time span becomes 4,000. Even splitting this across 2 resource pools would lead to 100 desktops per minute rebooting in each resource pool.

In contrast, setting the desktop group to "Do nothing" provides a much faster response for the users during shift changes and taxes the network and disk infrastructures less. In addition, if the user is routed back to a desktop they have been to before, the user profile update is faster since the entire user profile will not need to be created and loaded.

Of course, like any architecture decision, it has tradeoffs. By not rebooting the workstations at every user logoff, the write cache file for the provisioning services will grow larger than it would if the workstation was rebooted more often. How much larger, really depends on the environment. In addition, if the users are local administrators on the desktops, then user security is at risk because any files left by other users would then be visible to anyone logged on.

In this case, to mitigate the write cache file issue, I would leverage something like Workflow Studio to reboot the 20% of unused desktops in between shift changes. To prevent users from gaining access to left over files, you could not make users local administrators or employ a profile management solution in conjunction with redirected folders to keep the sensitive data stored on remote drives and/or remove the data at logoff.

So, now you have another perspective around designing a XenDesktop farm and something more to consider during your configuration. If you found this posting valuable and would like to be notified of future blogs, please follow me on twitter @pwilson98.