When we started writing Application Streaming, I figured isolating Microsoft Internet Explorer would be the "killer app".  It hasn't happened and I don't fully understand why.  Don't get me wrong, people are isolating the execution of Internet Explorer, it just hasn't been a driving force like I expected it would be.  They are using it to run with specific addons for specific websites and to allow execution of conflicting addons.  These are nice silo leveling ideas, but they are nowhere near as interesting as some of the other uses.

Some customers I have spoken with note that they 

1. Didn't know it was possible or
2. Are running server side and users are really users, so it isn't as important.

Back up a step - why would I want to stream and isolate a locally installed application like Internet Explorer?

Quick answer: To keep web evil-doers from writing executable or other content to the true machine.   Notice that this means that in "2" above, some of the benefit is lost if users are really users rather than users being adminstrators.  I mean, if they are really users, then they are comparitively safe anyway; there's no need to protect writes to \windows\system32 if the user lacks rights to write there anyway.  A side note: I do all my web browsing on user privilege accounts...

Disclaimer: I have been well schooled by security experts.  Application Streaming should not be confused with a security product, like anti-virus. Okay - fair enough.  But if evil software writes to \windows\system32\importantfile.dll, wouldn't it be nice if it didn't really write to the "real" location?  I mean, just because I visisted a couple of illicit websites, by accident mind you!, why should my system get corrupted?  Wouldn't an extra line of defense help?  I say extra defenses are good.

To be fair, the virus problems of a few years ago are much improved today and this provides less incentive to move to an isolated execution of a web browser, but it's so easy.  It's so easy, its local execution and it protects you from bad things.

Another use case: Stealth browsing

Combine isolated execution of Internet Explorer with automated scripts to blow away the "per-user" storage when you're done and you've gone a good ways toward hiding the stuff you browsed to.  It turns out that due to some bugs in script processing, writing this blast-it-all script is harder than it should be.  Still, stick with me on the concept.

How do I "stream" Internet Explorer?

Good question: Answer, you don't.  Well, you do a little bit.  Internet Explorer is run locally, so think AIE.  Any plug-ins or similar added to the profile are streamed in as needed, but the foundation of IE is run from the local machine (iexplore.exe), under isolation.    The trick is how to define a profile to provide Internet Explorer as a publishable application.  Some folks don't know you can do this and its easy.  In the Streaming Profiler, at the wizard page where you can pick "quick install" or "advanced install", go "advanced", then click the box to run internet explorer as the "installer".  This gives you the chance to run internet explorer under the profiler and when you're done, you get a profile stored on a network server (application hub) that defines local machine Internet Explorer as a "publishable application".

Here's what it looks like:
 
 On the next screen, tell the profiler to define local machine Internet Explorer as a "streamed" application.

Finally, you can control what happens to downloaded executable content.  That is, if the user downloads an "addon", you can control whether that addon will be usable from inside the isolated sandbox.  This panel shown early in the profiling process controls this function.

 
When "enhanced security" is selected, the streaming client treats executable content inside the per-user isolation space as evil.  Consider that the user session (application) wrote a DLL to the isolated \windows\system32 space, or any other isolated space.  For all inquires from application land, the content will exist.
 
If you do a directory, it is there.  If you type it, it is there. If the Windows loader tries to run it, "file not found". 
 
This can be a real kick to mess with using an isolated command prompt, but the end result is that application attempts to update themselves, or application attempts to install evil addons can be administratively made to fail.  The operating system loader gets "file not found", everyone else gets the real content.

 
Security disclaimer again
Just because downloaded and isolated executable content can be made to disappear for purposes of execution, does not mean that it will necessarily be un-runnable.  Should the the user download evil.exe and place it on their Desktop, it will really go to the desktop.  Then, user double clicks on the icon on the desktop, it will really run, it will run outside of isolation and it will pressumably, really do evil things!  Other "non-isolated" places include %TMP% and there is always an assuption that evil code will spy the isolated execution and then do evil things to get past it.  So, it's not a security product...
 
It is also worth noting that with the default isolation rules, "everything" that the user can see is open to "read". It would be useful to define rules for the execution target to mask access to data areas of the machine to prevent leakage and this can be done using the Streaming Profiler.   Security thoughts again, good evil software would get past this.  Worse for the good fun of this technology discussion, IE7 and Vista implementation of integrity levels have made most of this no longer relevant.   This last sentence intended as a high compliment to the Microsoft IE team.  A struggle they must have with this users are admins thing.

 
Back to this post: Streaming of IE does provide an interesting set of tools.  I'd be curious to see IE implemented to discard all content after execution or other nice uses.  Keep in mind that adding the Desktop to the isolated space (set rules in Streaming Profiler) would be a good idea and it could even be a good idea to isolate the temp space.  You're going to delete it anyway, so it doesn't hurt to put it down a few levels.
 
If you get it going, do shoot me a line.
 
Joe Nord
Product Architect - Application Streaming and User Profile Manager
Citrix Systems, Fort Lauderdale, FL.

First the thanks!

As we roll into the Thanksgiving week in the US, I thought I would give a quick shout out of thanks to all of you that have participated in the Citrix Ready Community Verified site. Verifications are coming in faster than we can keep up with them (which was, after all, the whole idea in the first place). As of this morning, we have well over 1,000 applications and products verified by customers and partners as "Citrix Ready", backed by more than 7,000 verifications... more than 500 were added this week alone, and it's only Wednesday!

I'm assuming that you have all seen the Citrix Ready Community Verified site and you know it rocks... not because of anything we've done, but because it's created, owned and maintained by YOU; if not don't just take my word on it, check out Chris' blog, or Rene Vester's two blogs, here and here, or even Brian Madden's review, ...or of course, the site itself!

By many standards, the site has proven to be an overwhelming success. We launched it at Citrix Summit on October 25 this year with 600 Applications and 500 Community Verifications. In the month since launch, these numbers have gone through the roof with no end in sight. In fact, I am already hearing of cases where the Citrix Ready Community Verified site has encouraged customers to virtualize more apps, helped channel partners answer customer & prospect questions more quickly and technology partners who have submitted apps (theirs as well as from other vendors).

Citrix IT has even taken up the challenge by starting to validate all the products and applications we use internally in our IT environment. I challenge all of you reading this to verify via the "voting" function all apps and other products you are using via XenApp, XenDesktop, XenServer and NetScaler!

May I have another? Or more appropriately, may we give you another?

The Citrix Ready Community Verified site is a great example of how a community can share small bits of information that doesn't impose a tax on the submitter (the apps are already deployed, submitters are just telling us they have already completed the work)... taking full advantage of the network effect to drive overall benefit.

So the question that I have for all of you, is what can we do next? The Citrix Ready Community Verified site is addressing a common question around product verification with Citrix products that has been around literally since the first release of WinFrame. Are there other longstanding questions, issues, etc that seem difficult to solve as an individual customer, SE, channel partner, technology partner or Citrix employee, that we as a community can attack?

My team and I are very interested in your feedback and would welcome the opportunity to help.

Please feel free to comment on this blog, or send an email to me at john.fanelli@citrix.com

This post is for programmers and admins who want to peek inside an Application Streaming profile to see the disk and registry content that the profile/target represents without having to actually RUN the application.  

First, some background.  A streaming profile can hold multiple execution images.  The streaming client deals primarily with the execution target and it is the target that holds the execution content.  While the ".profile" is the highest level file, once the streaming client figures out which GUID_ver.cab to open, it doesn't need the profile anymore. 

These words are confusing - an example is easier to follow.

 
The .profile is the primary file of the profile.  The streaming client though is more interested in the execution target.  For convenience, everything that is represented by the "target" is contained inside a single .CAB container file and this includes the isolated files and isolated registry.

How to view the files

The files are easy to see.  Double click on the .CAB file and all of the files that were "installed" are here.  Sort by "path" and at the root, you will see the files that the streaming profiler adds to the target which support the execution. 

Where's the isolated registry?

The isolated registry is stored inside the file InstallRoot.tab.  Don't be mislead though - this is not a 0x09 formatted file!  Seeing the captured registry requires a bit more work.  This post describes how to do it.

Wait - Doesn't the streaming profiler have a "regedit" launcher to view the isoalted registry?   Yes.  But, that will show you the result of an MERGED registry.  That is, regedit will "see" what the application will see at execution and sometimes you want to see just the layer that was captured during profiling.  How to do that?

Method #1:

When running a streamed application, the streaming client populates isolation layers to present a merged view of the local machine.  While the file content is streamed on demand, the registry content is populated all at once.   You can see it easily after running a streamed application by browsing to

• HKLM\Software\Citrix\RadeCache\GUID_v where "v" is a number for the version of the execution target.

On the first launch, the space will actually be slightly different as a volitale hive is used to speed execution.  You will see these with a v in the start of the name.  The volitale hives go away after the first reboot after the application is run.  The streaming client background populates the long term space after the application is up.  With the registry space populated, use REG.exe or similar tool to dump the registry space to a .REG file, done.  Yes, that is combersome.

Method #2:

Edit the profile using the streaming profiler.  Point at the execution target with left mouse, then right-mouse-button, update target.  This will put the target into "edit state" which is a fancy way of saying that the execution target will be brought down from the network server (Application Hub) and populated into the file and registry on the profiling machine.  So, it's local.  Where? 

Answer: HKLM\Software\Citrix\AIE\GUID

Notice no _v during profiling and yes, that's "AIE"!  While editing the target in the streaming profiler, you can peek all you want at the InstallRoot.tab contents and can dump this space to a .REG file if you like for easier viewing.    When you close the profile in the streaming profiler, or when you quit the profiler application, the registry and disk content populated to assist editing the target are recursively obliterated.  So, it will be "gone" when the profile is closed.  This by the way is "secret sause" on how the profiler works, so don't get too dependent on it - but you can get to the reg content without loading the application onto an execution machine.

Method #3:

If you need a programatic method, then the Streaming Profiler SDK is your ticket.  Open the profile, open the target, put the target into edit state and then see "2".  

I have received inquires that a program should be written/released that automates this.  Such things are good things, but until they happen, here's a way to get the information you may be chasing.

Joe Nord 

Product Architect - Application Streaming

Citrix Systems - Fort Lauderdale, FL

The Streaming Client installer goes out of its way to prevent installation on the "home" editions of Windows XP and Vista. Technically, the streaming client does not really care about which edition of the operating system it is; its just a test coverage statement.  This post describes how to convince the streaming client to install on the "home" editions and has some fun debating the dev-test checks and balances that exist in all large software organizations.

Consider this scenario

• Streaming client was written without any particular dependence on "Professional" version of the operating system
• Streaming client installer was written to prevent installation on non-professional versions (meeting requirements).
• Customer feedback during XenApp 5.0 / Streaming 1.2 Beta described this restriction as undesirable. 
• Now - You want to fix it....

The Streaming Client supports many platforms.  In streaming client 1.2, we dropped Windows 2000 Professional, but it still supports a large list including

• XP Professional
• Vista Professional
• Windows 2003 Server
• Windows 2008 Server 
• XP Professional 64-bit
• Vista Professional 64-bit
• Windows 2003 Server 64-bit
• Windows 2008 Server 64-bit

The above list may not be the correct list, but stick with me on the concept.  That's 8 platforms that the test team has to "certify".  Add in XP and Vista "home" and you have 2 more.  If it takes N days to decide that an operating system version definately works, then that's 2 * N more work to do and this has to be repeated numerous times throughout a development cycle.

Back to the "bug" - Streaming Client refuses to install on "XP Home".

Development point of view: The Streaming Client doesn't care about home vs. professional.  It will work.

Test point of view: I haven't SEEN IT WORK - therefore, it doesn't work.

The solution taken for Streaming Client 1.2 was to publish an installation transform which would FORCE the streaming client to install even if it doesn't like what it sees with regard to the operating system version at installation.  This transform was officially included on the XenApp 5.0 installation media, allowing the "home" editions to remain officially unsupported, yet letting them un-officially really work.

The Citrix Support team has a knowledge base article written on this: ctx118086

What it comes down to is

1) You need the installation transform.  It is on the XenApp 5.0 installation media (DVD) in the "Support\AppStreaming " folder.
2) You need to tell the installer to use the transform.  XenAppStreaming.exe is the streaming client installer.
XenAppStreaming.exe /C:"setup TRANSFORMS=<LocationOfTransform>"

There's one more thing.  The KB references how to do this using the MSI installer.  You'll notice that there is no MSI installer for the streaming client included on the installation media.  I don't recall the reason, but we removed it and I'm sure it was a good reason.  The EXE version extracts the MSI and runs it.  The point: the KB references two methods to run the transform - use the one for the EXE installer.

I extend my thanks to our CEO, Mark Templeton for purchasing a machine with XP Home pre-loaded and expecting to be able to stream to it.  This motivating me to "spread the knowledge" so other folks might work around the same thing without great headaches.   We will do well to remove the "home" limitation in future releases.

A question to solict comments: If we remove the installation check for "home", from a customer point of view, is it necessary to actually test "home"?  Notice that this means that we assume "home" will work given that "professional" does, and let conflicting views arrive during beta feedback.  I note that we already do this for "Media Center" and "Ultimate" editions.

Joe Nord

Product Architect - Application Streaming

Citrix Systems, Fort Lauderdale, FL, USA

Am I the only one who has trouble understanding Cloud Computing?  Is Instant Messenger considered cloud computing? Is my company's enterprise deployment of XenApp on XenServer considered Cloud Computing? Is the iTunes store considered Cloud Computing?  Why is Cloud Computing so hard to figure out?  Well, look at it from a different perspective.

Have you ever laid down on the grass and looked at the sky and tried to figure out what a cloud looked like?  You might think one cloud looks like a puppy and another looks like an airplane while someone else thinks your puppy looks like Homer and the airplane looks like a TV.  Trying to find shapes in the clouds is all based on your perception, just like if you try to get a definition of cloud computing from 5 different people, you will most likely get 5 different ideas. 

Of the many discussions I've had on this topic, I always hear some very similar comments. 

• Isn't Cloud Computing just a new name for the ASP model that Citrix was involved with years ago?
• Is Cloud Computing just the new term for SaaS? 
• Is the Cloud just a new name for the Internet?
  

Well, let's take a very brief look back before we get into the cloud...

ASP

I think one of the problems with understanding cloud computing is many people have been involved with Citrix for a long time. If you have been involved, you will remember the ASP model. In the ASP model, a 3rd party would host your applications for you, typically providing remote access with MetaFrame.  So instead of you having to hire people to manage your set of MetaFrame servers hosting Office 97, you would pay a 3rd party to do it for you.  You would access your applications using a secure connection (Citrix Secure Gateway) over the Internet.   You wouldn't have to worry about managing the servers or providing the data center space/power.  Instead of paying these large up-front costs, you would get a static, recurring bill based on the number of servers hosted.

SaaS

After the ASP model faded into memory, we got into the SaaS (Software as a Service) model.  In this model, a software vendor will host their proprietary applications to their subscribing customers.  When you hear SaaS, you always hear about SalesForce.com.  Well, Citrix Online is SaaS as well.  Citrix Online hosts the GoToMeeting/GoToWebinar/GoToMyPC/GoToAssist services and users access these services across the Internet.  Users are charged a recurring bill, and do not have to worry about maintaining and supporting the underlying infrastructure.  The SaaS model has been very successful because one would expect the people who know the best way to deliver an application are the ones who developed the application to begin with. 

Cloud Computing

Now we get into Cloud Computing.  Cloud computing can take on many different shapes, just like the clouds in the sky.  But one thing is common, all delivered services occur over the Internet, which is THE CLOUD. Cloud computing is essentially granting the ability to allow any user, on any device, from any location to get access to their applications and data. 

As I see it, Cloud Computing is a big white board waiting for organizations to make their requirements known.  Do you want a Test/QA environment to do whatever? This is cloud computing. Do you want someone to deliver office productivity applications for you? That is cloud computing. Do you want to have all of your MP3s stored on an Internet storage repository so you can get to it from any device?  That is also cloud computing.

I think the big thing with Cloud Computing, which helps differentiate it from the ASP model, is that the environment is dynamic, meaning that a server is not a SAP server or an Exchange server or a SharePoint server. A server is instead anything you want it to be with server virtualization and server provisioning.  So instead of a SAP server or a SharePoint server, we now have SAP and SharePoint workloads than can be moved and provisioned to any infrastructure available. It can be scaled up or down based on changing needs and defined rules.   With Cloud Computing, making these changes does not require rebuilding systems, it happens automatically and only involves resetting parameters.

If these are core requirements for any cloud provider, Citrix Cloud Center(C3) is able to help deliver the cloud-based solution. 

• With Citrix XenServer Cloud Edition, we can help provide the dynamic workload provisioning
• With Citrix NetScaler, we can provide the optimized, compressed and secured connections required for Cloud-based connections
• With Citrix WANScaler, we can provide the efficient link between the cloud and the enterprise infrastructure
• With Workflow Studio, we can create and implement automated workflows that will manage and maintain the environment for us
  

So, the next time you talk about Cloud Computing, remember it is very similar to the dynamic clouds in the sky, Cloud Computing can be pretty much anything. One thing is common though, you need an underlying infrastructure that is dynamic, optimized, secured and automated. 

Daniel

Part I of the Deep Dive into XenDesktop series reviewed the architecture. Part II covered the install and management tools. Part III reviewed an example XenDesktop Pilot Architecture. Part IV reviewed the Virtual Desktop Delivery of Dan Feller's "XenDesktop Pilot Implementation Guide". Part V reviewed the integration with XenApp for application delivery to the virtual desktops. Part VI covers User Personalization with Citrix User Profile Manager. This is the third section from Dan's Pilot Implementation Guide.

This embedded presentation covers the "Personalization" section of the Pilot Implementation Guide.

Click here to view the presentation in full screen at Slide Share.

This presentation does have several slide notes that provide additional detail. You can view the slide notes here.



Frank Anderson on the XenDesktop team has created a few screencasts covering the features of XenDesktop. You can watch his short screencast covering the provisioning and lifecycle management features of XenDesktop here. Frank's screencast on user experience is available here.

Download the free XenDesktop Express Edition here

Part I of the Deep Dive into XenDesktop series reviewed the architecture. Part II covered the install and management tools. Part III reviewed an example XenDesktop Pilot Architecture. Part IV reviewed the Virtual Desktop Delivery of Dan Feller's "XenDesktop Pilot Implementation Guide". Now in Part V we review the integration with XenApp for application delivery to the virtual desktops. This is the second section from Dan's Pilot Implementation Guide.

This embedded presentation covers the "Application Delivery" section of the Pilot Implementation Guide.

Click here to view the presentation in full screen at Slide Share.

This presentation does have several slide notes that provide additional detail. You can view the slide notes here.



Frank Anderson on the XenDesktop team has created a few screencasts covering the features of XenDesktop. You can watch his short screencast covering the provisioning and lifecycle management features of XenDesktop here. Frank's screencast on user experience is available here.

Download the free XenDesktop Express Edition here

I have been having this ongoing conversation with my fellow citrites on provisioning and virutualization. The big question is whether to provision the hypervisor, or to virualize the provisioning server. Each has its pluses and minuses, but they are both equally valid solutions.

If we look at provisioning the hypervisor, the advantages are that we could re-provision bare metal servers to be anything, but we would also have to worry about where write cache for the hypervisor would be located, and then there is the whole cloning of a hypervisor thing.

If we look at virtualizing the provisioning server, the advantages are that we could move the provisioning server to other hosts, which would be a major added benefit to the already robust HA features of Provisioning Server. The negative would be that we would have to allocate more virtual resources for more provisioning servers or use fewer guests per host to achieve the same thing.

I gave a presentation at PubForum 2008 Dublin earlier this year, where I took a similar approach to something wonderful. I used provisioning server to stream to a target device and OS that was itself a provisioning server, and that in turn was used to stream to a target device a client OS. The purpose of the demo was to show you how one could use provisioning and virtualization to truly build a dynamic environment, whether it is a lab, or a production environment. But the main goal was, if I had a rack of servers, that had nothing on them, zip, nada, zilch, and from that I wanted to hit the big green go button, and turn them into whatever, you should be able to do so.

At present we can provision Windows Server 2008 with Hyper-V, but not XeServer. I'm not trying to get into a this product, that product debate, but I want to try and flush out what you think about the pluses and minuses of either of these scenarios.

Part I of the Deep Dive into XenDesktop series reviewed the architecture. Part II covered the install and management tools. Part III reviewed an example XenDesktop Pilot Architecture. Part IV reviews the first section of Dan Feller's "XenDesktop Pilot Implementation Guide". Dan goes through each step of configuring a pilot from start to finish.

This first embedded presentation covers the "Virtual Desktop Delivery" section of the Pilot Implementation Guide.

Click here to view the presentation in full screen at Slide Share.

This presentation does have several slide notes that provide additional detail. You can view the slide notes here.



Frank Anderson on the XenDesktop team has created a few screencasts covering the features of XenDesktop. You can watch his short screencast covering the provisioning and lifecycle management features of XenDesktop here. Frank's screencast on user experience is available here.

Download the free XenDesktop Express Edition here

On Wednesday, October 1st, I attended the Rocket Science 2008 and 2008 Application Virtualization Group (AVG) Engineering Expo. A few of the demos covered super top-secret innovations to improve the Engineering/Test process*, others were examples of demos for Summit and then there were four stations that really peaked my interest. That's not to say that everything else wasn't ubercool or that everyone that presented doesn't deserve MAJOR kudos for all the work they've done above and beyond their regular duties, but if you're attending Summit you can and should see those demos for yourself, and I think these particular entries deserve some notice.

Automating VM provisioning

Andy Zhu presented work for a virtualization initiative. The large-farm/scalability test team is employing XenServer in order to use virtual servers instead of physical servers for every test. The XenServer PowerShell Kit allows the team to quickly and easily deploy predefined templates to XenServer in a large scale. Using more virtual servers means no more brown-outs when System II powers up that 1001st server!

Cloning XenApp just got easier

Shannon Ma demonstrated the latest version of XenAppPrep, a tool that helps clone XenApp servers. In Shannon's words, it's basically the equivalent of sysprep for Windows, except it's for XenApp. Since I had just finished a round of virtualizing XenApp Server on XenServer Platinum utilizing the current tool and in the past I've helped create documentation about cloning XenApp Server, I know the manual process can be tedious so I really wanted to see "What's next?" XenAppPrep should be available on the web October 26th, and you're going to want it.

UPDATE: XenAppPrep is now available for download - http://community.citrix.com/display/xa/XenAppPrep+Tool

XenPool On-Demand Data Center

Kailas Jawadekar presented his latest work created for the internal XenPool initiative. Configured similarly to the public MyCitrixLab used by the Citrix Ready Program (more info on MyCitrixLab here and here,) the Citrix AVG XenPool is a project to demonstrate the benefits of pooling hardware resources in a lab environment and offering a set of dynamically configurable VMs to a broader set of customers. Kailas demonstrated a working model of a customer self-service frontend where someone that needs access to a VM can go to a webpage, choose from a selection of available templates and request a VM. When the VM is ready, the user gets an email to notify them. To ensure people aren't taking up resources they're not really using, the VMs come with a timed lease so a user receives prompts when the VM is about to expire and when the VM has reached it's expiration date so a user can elect to extend the lease time if they are still utilizing the VM.

Eating your own dog food can make you rich and thin

This last demo was the one that really put the cherry on top for me and reminded me just how much Citrix products can rock. Steve Dillon and the AVG Build team used our own technology to provide themselves High-Availability, Business Continuity, Disaster Recovery, reduced power consumption, reduced hardware and improved turn-around times. By incorporating XenServer Platinum Edition into their infrastructure, AVG Build went from 40 single CPU 32-bit servers to 2 16-core x64 servers running XenServer (4 quad-core CPUs per server.) By virtualizing on multi-processor machines and switching to x64-bit compatible software they were able to:

• Reduce hardware ($aves space, reduces cooling costs, electricity, money . . .)
• Speed the build machine provisioning process (what took hours now takes minutes)
• Created a cost-effective DR solution instigated by Hurricane Wilma - there's now XenServers in the UK with Provisioning Server disk images ready to deploy and continue Build if local Build servers become unavailable.

Way to go, Citrites!

Finally, one last "Congratulations!" to everyone that participated this year - I can't wait to see what turns up next year - and "Thank you!" to David Pope, Gagan Singh and everyone that helped them put this event together for us.

* OK they're not all super top-secret, but thanks for reading down this far!

The concept of desktop virtualization is easy, "I take the desktop and virtualize it with XenServer, Hyper-V or ESX and place it in a data center."  So, what's the big deal?  Quite a bit actually, that is if you want to create an environment that can scale as well as simplify the management, maintenance and storage of the virtual desktops.  If you look at a typical user's desktop, it comprises of three main things:

• Operating System
• Applications
• Personalization Settings

The combination of all three makes the user's desktop their own personal desktop.  For me, I want my desktop to be Vista, with all of my apps (including the DVD Player so I can watch the just released Season 11 DVD of The Simpsons), and my desktop settings configured so I have a Homer Simpson background.  While another user might want XP, their set of apps (which could include financial planning apps) and a background of David Hasselhoff (Don't Hassle the Hoff).   Then we got another user who wants Vista, with their applications (could be HR-based applications) and regional settings setup for their current location.  As you try to gather the requirements for all of your users, you start to see the complexities and challenges with trying to change the way desktops are delivered. 

So, how do we go from a 1:1 ratio of user to desktop to a Many:1 ratio where many users are able to use the same underlying desktop but still have a unique set of applications and personalization settings?  Would you believe virtualization?  But this kind of virtualization is different than server or desktop virtualization, it is application and personalization virtualization.  By virtualizing each component of the desktop, you can mix and match them up however you see fit to meet the needs of your users.  Let's focus on the Operating System as that is the foundation for the rest.

If you look at multiple user's desktops, do you see any commonalities?  Of course, but they probably don't appear to be significant.  Look again but this time ignore applications and any personalization settings. What are you left with? An Operating System (Vista of XP).  From a collection of thousands of desktops, we only have 2 base operating systems.  That simplifies things. Now, imagine for a moment that for maintenance of the operating system, all you have to maintain are 2 desktops.  To me, that seems much easier than trying to maintain thousands of operating systems. It is and can be done with XenDesktop, but if you want to deliver the operating system correctly, what do you include in your base OS image?  

The bare minimum.  Of course there is no single answer that works for everyone because one size does not fit all and every organization has different requirements. But there are some items that must be included in a XenDesktop base image and some other items that "might" be included. It's up to you and your current use case. Here are some of my recommendations...

Must Have

• XenServer Tools: These are the XenServer optimized drivers for the operating system.  If you are going to use a different hypervisor, you need those tools installed in place of XenTools.  But seriously, why go with anything but XenServer ?
• Provisioning Server Agent: This agent maintains the connection to the base OS image. It is responsible for the OS stream.
• Virtual Desktop Agent: This agent is responsible for maintaining a connection with the XenDesktop farm informing the farm controller of its status.
• XenApp Plugin for Hosted Apps: This will allow the user of the desktop to get to a published application on XenApp
• XenApp Plugin for Streamed Apps: This will allow the user to receive applications into the desktop that are streamed from XenApp
• User Profile Manager Agent: If you want to include personalization virtualization then you will need to include the Citrix User Profile Manager Agent (Tech Preview).  You could also forego this agent and use mandatory or roaming profiles, although they won't give you the stability, flexibility or control that the User Profile Manager solution brings.
• Antivirus/Malware/Spyware:  Just because the desktop is virtual doesn't mean we can forget about antivirus/Malware/Spyware solutions.  Sure, XenDesktop virtual desktops are destroyed after each use, essentially wiping out any local nastys, but these programs have plenty of time to do damage when the user is online. 
  

Might Need

• Browser Plugins: Flash, ActiveX, or any other common plugin needed to see all relevant content when using a web browser like Internet Explorer. These could be installed or streamed. You will hear more in an upcoming blog on application integration
• Applications: Install, stream or host?  What to do? If you install the applications, then they are part of the base OS?  Should you do this?  This is a large question and will be a topic for a future blog on application integration. 
• Corporate Settings: Are there corporate settings that must be included in the base image? Do they have to be in the image or can they be applied with an Active Directory Group Policy?
  

Did I miss anything?  What other things do you think must be or might be part of the Base OS?

Daniel

Part I of the Deep Dive into XenDesktop series reviewed the architecture. Part II covered the install and management tools. Part III reviews an example XenDesktop Pilot Architecture. This presentation is based on the "XenDesktop Pilot Reference Architecture" document by Dan Feller. Here is the the introduction to Dan's white paper -

Dan put together a list of requirements for this Pilot Reference Architecture -

I have broken the great content of the pdf into smaller, bite size chunks to make it more digestible within a slide format (especially the step by step tables). Before each step in the tables, I added in the reference diagram with a big arrow that points to the step within the diagram. There are a lot of slides, but the amount of content on each slide is much easier to swallow in this format IMO.

Click here to view the presentation in full screen at Slide Share.

This presentation does have several slide notes that provide additional detail. You can view the slide notes here.

Frank Anderson on the XenDesktop team has created a few screencasts covering the features of XenDesktop. You can watch his short screencast covering the provisioning and lifecycle management features of XenDesktop here. Frank's screencast on user experience is available here.

Download the free XenDesktop Express Edition here

Thanks to Dan Feller for putting together an excellent whitepaper and allowing me to convert that content into this format. I hope you find this useful.

In the first Deep Dive into XenDesktop post, the embedded presentation covered the architecture of XenDesktop. This next presentation reviews the install of the the Desktop Delivery Controller and the Virtual Desktop Agent, then reviews the Management Console, Desktop Groups, and the Citrix Desktop Toolbar.

Click here to view the presentation in full screen at Slide Share.

This presentation does have several slide notes that provide additional detail. You can view the slide notes here.

Frank Anderson on the XenDesktop team has created a few screencasts covering the features of XenDesktop. You can watch his short screencast covering the provisioning and lifecycle management features of XenDesktop here. Frank's screencast on user experience is available here

Download the free XenDesktop Express Edition here

Thanks to Richard Nash on the SE team for providing much of the source material for this slide presentation.

When doing Application Streaming "Profiler" demonstrations, I often get a warm reception when people figure out that the Streaming Profiler can do a "Virtual Restart" or "Virtual Reboot", even without rebooting the machine!  A screen shot of the GUI to control this is below and this is what usually gets the warm reception started. 

I call it the "check box" that does nothing!  Look at the circled box at the lower left of the panel.

Why is this GUI checkbox there if it does nothing?  I'm not sure.  Back in the beginning, I was "deep" into the Streaming Profiler backend (read: not the GUI) and had a fair involvement in the App Streaming implementation of virtual reboot. 

GUI perspective: Admin selects the above checkbox.  When the "installer" completes, the GUI will send a command to the streaming backend code to tell it to do a virtual reboot.  The reply from the back end is "super!  I was going to do it anyway".

My point in this blog post is that if you are profiling an application installation and you KNOW that this installer needs a virtual reboot to be successful and if you think you may have forgotten to check that box, no worries, the virutal restart stuff was done anyway.  The GUI box that "does nothing" is more of a feel good button than a button to tell the profiler to do some work.

Another way to look at this is that if you are in the profiler and you are running an installer and you're not sure if a virtual restart is needed, you don't need to worry about it.  The profiler backend is going to figure this out anway, so ignore the question.

Details

The profiler back end does a bunch of things when the application installer has terminated.  Among those is interrogating the RUNONCE and similar items that get set up by installers to do work on the reboot.  *IF* the installer has populated any of this "do work on next boot" stuff, then the profiler back end already knows there is more work to do and doesn't need the admin or GUI to tell it about it.  Humans tend to be unreliable for such information anyway and the profiler can "see" directly what the installer wanted to do to the machine, so it doesn't really need the GUI help to know if the virtual restart should be simulated.

It is a nice GUI checkbox and it does make it clear that the App Streaming Profiler can handle applications that need the system restarted to complete their installs.  The profiler though runs the installer under isolation, so it can do the "reboot" stuff without really rebooting the machine.  A good capability, a pretty GUI and ... one you don't need to worry about checking when running the Streaming Profiler.

Joe Nord

A perplexing question: If you recently shipped the product and you now know something is broken, do you tell anyone about it? 

I was in the lab yesterday working with two nice folks on the Citrix test team developing some App Streaming scripts for show and tell at the upcoming Citrix Sales Summit.  We encountered some things in scripts that did not work the way they should.  Technically, they did not work the way that I expected them to work and conveniently, I'm architect of this gig, so I get to call that busted.  This blog describes the situation so you won't be surprised when you encounter the problem.  It also provides workarounds and then debates the merit of "full and public disclosure".

Background on scripts

Scripts come in 4 forms, a result of a 2 by 2 matrix of these capabilities.

• Pre-Launch vs Post-Exit and
• Inside isolation vs Outside isolation

Pre-Launch scripts run before the FIRST application of an execution image (sandbox) is run and post-exit scripts run AFTER the final application of a sandbox terminates.   Inside and outside of isolation is pretty self explanatory.  Scripts are further elaborated upon because there can be PROFILE level scripts, and there can be TARGET level scripts and targets can choose whether they want to use the profile scripts at execution or the target scripts and there can be an unlimited number of scripts of any of these types. 

The configuration data in the Target tells the isolation system whether to run the profile level scripts or the target level scripts.  Both profile and target level scripts can exist, but even if the target has scripts, that doesn't mean that they will be used.  The profile/target setting tells the client which set of scripts to run. 

Scripts are BINARY.  They might be .BAT files or they might also be .EXE; the Streaming Client treats them all as binary.  There is no concept of editing scripts because they are assumed to be executable content or perhaps DLLs.   To edit scripts, you are forced to delete them from the profile, edit them some place else and then add then back to the profile.  That's a hassle, but it is not what this post is about.

What's the bug?

"Stale scripts" - If as an administrator, you update the scripts, you expect the streaming client to use the updated scripts when the user later runs the applications from that profile.  This is broken for profile level scripts.  Read on...

Target level scripts are global to the target, or more precisely, to the particular revision of the target.  Let's assume you are using Target level scripts - all is good.  The scripts themselves are stored with the .CAB file that provides the execution content for the target and this is hard to mess up because the CAB filename is versioned and the expanded contents of the CAB in the RadeCache are also versioned via the naming of the RadeCache subdirectory.  Target level scrips here are not the bug.  To notice, you cannot update the scripts for a Target without bumping the revision on the Target, so all is good.  Part of this is a positive fallout of all of the target contents being stored in a CAB file for easy transport.

Profile level scripts are SUPPOSED to be global to the profile. Well, they are global to the profile.  In theory, profile level scripts are global and they have effect over all execution Targets.  This provides a SINGLE POINT OF MAINTENANCE for scripts no matter how many execution targets your profile may have. For example, if you need to NET USE a network drive before running an application and if you have 4 execution targets, you will want to use profile level scripts because this is a single set of files to maintain.  Then, if the server location changes for the "net use", you have to update only the profile level scripts and all is good for ALL of the Targets.  This is how it is supposed to work.

My experience yesterday says that this is not how it is working (Streaming Client 1.2 == XenApp 5.0).  Step 1: Ask the testers to write a CPR.  Step 2: Get the development team to fix it.  Step 3: Wait 6 months to a year to get it out the door.  Hum.  That last step sucks. 

The delima

If I keep quiet, maybe nobody will notice!  Hey, scripts are kinda rare anyway and this will only come up if the admin is using profile level scripts and will only show itself if they UPDATE their profile level scripts without also reving the Targets, so let it be.  My scruples can't do it.  If I were getting hit by some bazaar bug, I'd like to hit google and find out that someone else has see the issue before and knows how to work around it. This situation is different only because the person hitting the strange behavior is the one who has self-motivation to make things appear bug free and polished as possible.  They are polished!  Trust me - but I'm still telling you about this odd behavior.

Details on the bug

When the Streaming Client decides to run scripts, for Target level scripts, it extracts ALL of the scripts from the execution CAB on the network server and places them into the streaming execution cache on the execution machine.  These land in RadeCache\GUID_version\Scripts.  They all land in a single directory and we don't guarantee where that directory will be, but we do insist that all of the scripts be PRESENT in the single directory before ANY of the scripts are run.  This makes it possible to have DLLs or data files as "scripts" by defining them in the streaming profiler, but marking them disabled.  I digress - back to the bug.

When the Streaming Client decides to run Profile level scripts, in concept it simply runs the scripts from the network server and calls it good.  The scripts are already all in the same directory and the network server is accessible so local copy isn't needed.  Run it from the server, done.   I expect where things "changed" in 1.2 client is that HTTP is now a delivery method for Scripts which means that the scripts must be copied to local machine before they can be executed.

In this case, there is no extract because the scripts are merely files located on the network server in the "Scripts" subdirectory beneath where the profile top directory is located.  Side note - just placing files in this directory will not convince the streaming client to treat the files as scripts.  It will only execute scripts that were defined in the Streaming Profiler and will only copy for execution Scripts that it believes are scripts.  This was done on-purpose for complicated reasons primarily centered around digital signatures.  If it ain't signed, don't run it.  That's good stuff - if only people had Crypto infrastructures in place.  More digression.

The Streaming Client is SUPPOSED to copy the contents of the server side Scripts directory to the client, somewhere, and execute the scripts from there.  Where on the client machine?  I don't care!  But don't put it into the execution Target!

The bug

The Streaming Client is copying the contents of the profile level scripts into the scripts directory for the Target inside the RadeCache.  This is bad.

Consider this sequence:

1. Admin creates a Profile with single Target and a single pre-launch script defined at the profile level.
2. User runs the application.
3. Streaming Client copies profile level script to the Target RadeCache\guid_v\Scripts directory.
4. Script runs.  Client machines goes about its merry business and eventually user closes the application.
5. Admin UPDATES the profile level script.  Admin does not update the execution target.
6. User runs the application.
7. Streaming client says "WOW!  I already have the script, there is no need to copy it from server" (bug).
8. Streaming Client has now run a "stale" version of the pre-launch script and nobody is aware.
9. Next setp - Possibly: Admin updates the execution Target.
10. User runs application and now gets the PROPER profile level script, must be magic!

Where the code broke:

Joe's rules of the Streaming Client - NOTHING goes into the RadeCache\guid_v directory that did not come from the CAB file on the network server.  Scripts at the profile level need to be copied local for execution - true.  They do not need to go into the RadeCache directory on the client.  Is another directory needed for the profile level scripts?  Yup!  Where should it go?  I don't care, but it should be someplace writable by the Streaming Service and not writable by ordinary users.  It should also "hang around" between executions so that the streaming client can diff the local scripts with the network server to see if anything was updated.  This may require putting file date/time stampts into the XML data and accompanying files that describes the profile so that a network side diff isn't needed.  Conveniently, we already have this date/time data in other files with the profile so the delivery method of network vs. http will not be an issue.  What it will mean long term is that merely updating files on the network server to update the profile level scripts is "not good enough" if you expect them to get executed on clients.  The Streaming Profiler needs a chance to store file information about the scripts so that it will know when profile level scripts are updated - to trigger clients to bring down the new versions of files.

Defect tracking

The writings above are what I normally put into the Citrix defect tracking system.  This is what I'd call a good bug report - one which developers can actually use to see the bug, know how to fix it and testers can then write additional testcases so this doesn't get out the door busted a second time.

Workarounds

1. Use only Target level scripts.  This is fine if you have only one target.  If you want profile level scripts, this is no good.
2. Update the Targets when updating the profile level scripts.  Works, but causes target upgrades unnecessarily.
3. Write a script to erase all files in the script directory and run this script as the final pre-launch script and the final post-exit script.  This will force the streaming client to pull down the script content from the network server on each run.  I haven't technically tried it, but this should be the preferred workaround. Its a neat script too! Batch file with: "echo Y|del ." .  This is probably better entered as "if exist ..\scripts echo Y|del ..\scripts\." .  To be clear, this would not be needed for Target level scripts.
4. Erase the RadeCache\GUID_v\Scripts directory via software management system on client workstations when you update the profile level scripts.  This is much like "3", but prevents copying of script files on each launch, so it is better.

Thoughts on full disclsure
Why did I paint my horse ugly?  If I were an admin and was encountering something like this, I would want to know the cause and I would want to know the workarounds.  This post should help.   Let me know if it was useful.

Joe Nord. 

Citrix Systems - Product Architect, Application Streaming

Those of you who attended Synergy this year may have taken part in our first ever Geek Speak Live, where we ran an "unconference" in parallel with the main event. Folks like Shawn Bass, Doug Brown and Rick Dehlinger got up and spoke about the technical topics on their minds and yours. We also had some open mike sessions as well as Q&A.

Well, the good news is that we will be repeating Geek Speak at our upcoming Citrix Summit that is being held in Orlando on October 26 - 29. A number of the Synergy Geek Speakers have kindly agreed to speak again, and we have agreed on the following topics:

• VDI vs TS: Rick Dehlinger
• Pros and Cons of Virtualizing XenApp : Doug Brown
• The reality of implementing "Green IT": Charles Aunger
• Best Practice implementations for Tele-commuters, Home Workers and other "Virtual Workers" - Steve Greenberg

In the true spirit of Geek Speak, I and the speakers would like to hear from you on what you think of these topics, and are there other topics you would want to hear in an unfiltered way? Even if we cannot fit them into the Summit schedule, or you can't attend Summit because you aren't a Citrix Partner, they could be added to some upcoming live and virtual Geek Speaks that I am planning. But I'll keep you in suspense by leaving more on those in an upcoming blog .

So please let me know what you think of the topics we could discuss by posting a reply to this blog.

     
In my last post, I discussed the new look and feel for our Access Gateway user experience.   Most of the focus was about the consistency of user experience across Citrix Delivery Center.   Well, the WANScaler product team has done the same with the Accelerator client plug-in. The Accelerator desktop icon is pretty cool...



The real value of Accelerator is that it makes things go faster (hence the name, gotta love those creative marketing folks ).  

In my job, the biggest kick that I get with Accelerator is when I transfer files from my laptop to my V: drive on the network.   First pass on a big Powerpoint presentation download can take a couple of minutes across the world, but then after a few tweaks to the file, the upload  takes less than 10 seconds.  There is no way that I'll ever let someone take this away from me.  

The performance improvement is a result of Delta compression where only the changes are re-transmitted.  The running joke is that we'll improve this someday and call it Gamma compression.

The geek in me has fun opening the Accelerator Manager window and watching  the Performance page. The more light blue in the graph the better.  Here, it's making my home DSL line feel like I'm in the office on the LAN.

Accelerator integrates with the Access Gateway client so that you get the combined benefit of a fast and secure connection when you are remote.  Although, I run in this mode on our open wireless network when in the office as well. More on this some other time...

With the Accelerator icon running in my systray, I know that WANScaler and the Accelerator client plug-in are quietly working in the background to make my experience "LAN-like" everywhere I connect.

Go Fast!

Gordon  

UPDATE: You can see the second post (and presentation) in this series at this link.

The XenServer posts with technical presentations embedded (here and here) have been very popular. This next presentation dives down into the architecture and functioning of XenDesktop.

This presentation does have several slide notes that provide additional detail. You can view the slide notes here

Frank Anderson on the XenDesktop team has created a few screencasts covering the features of XenDesktop. You can watch his short screencast covering the provisioning and lifecycle management features of XenDesktop here. Frank's screencast on user experience is available here

Download the free XenDesktop Express Edition here

It's that time in the XenApp world again... Migration.  With the release of XenApp 5, many of you are contemplating a migration.  Why is migration such a big deal? I've heard numerous reasons like "It takes a long time to test my applications with the new XenApp (especially true if there is a new operating system involved)", "It takes a long time to rebuild my servers as I have to update my server build scripts" or "My current XenApp environment works fine, so why change it".

Those were all good points a few years ago.  But with the enhancements and optimizations made on XenServer for XenApp virtual machines, it is a great time to test server virtualization for XenApp to simplify migration.  And if we virtualize the XenApp servers, migration to XenApp 5, 6, 9, 11 or even XenApp 243 will be even easier (of course we will have changed the product name a few times. Let me hear a Hallelujah for HomerFrame or XenHomer).

But if we are going to migrate to XenApp 5, why not make the migration easier. Just how will XenServer make migration easier?  That is a great question, and I'm glad I asked it

Hardware
First, part of a new XenApp version means organizations will have to update their server builds.  Many of the server builds I've seen are complex scripts or require many manual changes once the build is complete.  Many times, there are multiple builds because of differences in the underlying hardware.  With XenServer , the links between the OS and the hardware are cut resulting in the ability to create a single build that can span multiple hardware variations.  How many fewer images will you now have to maintain?  Simplified

Optimization
With XenApp, you want to get the most users out of  your hardware.  This has been true with previous versions, is true with XenApp 5 and will be true in the future versions.  With a new OS and a new XenApp, do you have any idea how much hardware you need to support your users for the different application sets?  This is a challenge, especially when trying to design the new environment.  When you designate a server for a certain function, it is awfully hard to change the server's function, unless you virtualize.  With XenServer, you can make a virtual machine into anything you want.  You can move the running virtual machine to another physical server without the users ever knowing.  With XenServer and XenApp, you are no longer stuck in your static environment; instead, you are dynamically changing the environment based on the needs of the business. Simplified

Maintenance
How many of you like spending your days patching servers?  Not many.  Unfortunately, with each piece of software, there will undoubtedly be patches. With physical servers, you have to patch each server. With server virtualization, you still have to patch each virtual server.  But with XenServer Platinum, you only have to patch your base image, which is delivered to the virtual server via Provisioning Server.  If I have one XenApp image for SAP and another XenApp image for all of my other applications, I only have to patch both of those images.  Those images are then streamed to hundreds of physical or virtual servers.  Simplified

Evaluate
How could we do a migration without evaluating the apps and OS and XenApp configuration? This is critically important, especially if you are upgrading to a new OS like Windows Server 2008. With XenServer Platinum, the evaluation and testing phase is simplified.  How do you typically do this?  Well, you build the environment in a test lab.  You run test, modify, re-test. The cycle continues until a golden image is created.  That image must be used as a guide for rolling into production.  If you use scripts, you have to figure out how to script the build process to mimic your image.  If you use cloning solutions, you have to modify based on hardware.  If you use Provisioning Server, which is part of XenServer, you take your server, create a Provisioning Server image, and copy the image to production for delivery.  Simplified.   

Rollback
Let's say you upgraded without doing a proper test (shame on you).  As it turns out, one of the applications, which unlucky for you, is mission critical and is not working correctly.  What do you do?  Well, you have a few options:

• Try to troubleshoot and fix. You will be under the gun to get it fixed quickly as the business needs the application.
• Rebuild the physical server with the old setup. This will take a few hours for the build to complete and configure the applications.
  

Neither of those options sounds good to me.  Instead, if the environment was virtualized with XenServer Platinum, you would easily be able to change the version of XenApp delivered based on the Provisioning Server image you associated with each target device.  Simplified

XenServer for XenApp can simplify migrations by focusing on the areas of Hardware, Optimization, Maintenance, Evaluation and Rollback (This is what I like to call the HOMER Criteria).   It's a great way to get more done without working harder.  You get the migration done faster while providing a more dynamic environment for the business. 

Daniel

 
 In my last post, I discussed the importance of user experience -> It's All About The User Experience (IAATHUX) 
Our Access Gateway team has come up with a new look and
feel that is nice and clean.   I think this is much more intuitive and consistent with the experience across Citrix Delivery Center.   Notice that they are using plugin terminology in anticipation of App Receiver.

The desktop icon has changed from the "two rubic's cubes connected by a red pipe" to the simple and easy to understand lock symbol.   The rationale here is that secure access is not just about remote access but should secure connections onsite and offsite.

The thing I like the most with Access Gateway is that with auto-reconnect, I can just live in secure connected mode all the time.  At Citrix, we run open wireless networks at most locations, so I can just put my laptop to sleep and start-up in any location (including at home) and be assured a secure connection without having to do anything.  I just see the secure lock icon in my systray and the auto reconnect happen as I transit networks. 
 
With the advantages of de-perimeterization,
I think more and more users will appreciate this model. Check out the Jericho Forum, for more on this model.

Cheers,

Gordon