One of the first screens you will see in the Streaming Profiler wizard is a screen about "Enable User Updates" or in the earlier profilers, this was called "Enhanced security" or "Relaxed security".   Wow!  Mysterious terms!  The first thing we do in the profiler is hit the admin with a question that they don't know the answer to.  Hum.

Steps:

1. Describe the panels
2. Describe what the settings do
3. Examples of how this effects application execution
4. Guidance on how to configure the setting

Here's the panel in the streaming profiler version 5.2 (XenApp 5 Feature Pack 2):  Hot off the presses, released GA to the web download last night.

Here's the same panel in the previous streaming profiler (1.3)

What does this setting do?

Under the profiler, it doesn't do a whole lot.  It just sets a BOOLEAN that accompanies the streaming profile.  You can see via nice visual form in this streaming profiler, but if you dig down, you'll find that all this does is set a boolean in the profile XML data; at the PROFILE layer.   Changing this setting actually does more work, but I'll get to that in a minute.

Going back to the Layers of Glass, there are conceptually 3 layers of isolation.  Here's an abbreviated version.

At runtime, the applications in the isolation sandbox see a multi-layer merge of the true machine at the bottom, masked by the installation image and at the top, a per-user layer.  The per-user layer is seen "first", followed by the lower layers of isolation and finally the true disk or true registry of the machine.

The normal action is that the machine starts out pretty much clean, the streaming profiler captures the installation activity of an "installer" that writes stuff to the file system and registry.  These are packaged up to become the "blue" layer above, the installation image.  

At end user execution, the installation image is laid down on top of the execution machine and as far as the isolated applications are concerned, they are installed.  It's all a lie - they aren't really installed.

The top layer is initially "clear" or "blank".  As the programs run, they may store documents and similar, but these would generally not be in isolated space, so they don't really show up in this picture.  The application though may WRITE things to "off-limits" locations which would be caught by the isolation system and end up with storage of stuff to the per-user layer of isolation.  These land in the top layer of the isolation stack which is set up as one per-user.  This is what allows ill-behaved application to run happily under isolation on a multi-user machine when they won't happily run without isolation.  As an example, consider an application that stores settings to the program installation directory in a .INI file.  Under isolation, this will be captured and land in per user space and the application becomes runnable in a XenApp Terminal Services world where otherwise it would not work successfully.

Back to this post

If the application updates itself at runtime, the update will land in the per-user layer of isolation and this is bad.  Standard procedure when profiling application installations is to TURN OFF all automatic updates.  The application should not update itself - this should only be done in the profiling scenario where the administrator commands the update.  Recall that the isolation space is ONE and the per-user space are MANY, so we only want application content to be updated in a single place.

What does "Enable User Updates" do?

If the user downloads application updates such as .DLL updates or .EXE updates, should this be permitted?

The general answer is "NO!".  Some administrators may have a scenario where this is desired.  The common ones are users wishing to install their own plugins for isolated web browsers or install their own addons for things like Microsoft Office.

How does it work?

Put your file system filter driver writer hat on.  For isolated applications, EVERY TIME the application opens a file or tries to open a file, you get first look.  If the file open is for executable content, should this be permitted?  If "enable user updates" is "off", then file opens for RUNNING executable content from the user layer will be denied.  

The neat part here is that the isolation system distinguishes this behavior based on WHO the caller is.

If the caller is vanilla application wanting to read or write content, no problem - do what you want.  If the caller is the Windows LOADER, then this setting comes into play.  If the LOADER is trying to load executable content from the per-user layer of isolation, then the isolation system can be told to FAIL that operation, and this is what this setting controls.  Pretty neato.

One headache

The setting while stored as a profile level single property (a boolean) is implemented in the isolation system as an attribute of EACH of the isolation rules for EACH execution target of the profile.  If you set the profile level property, the streaming profiler must modify the isolation rules (many) for each Target of the profile.  This means that if you have a profile with 4 execution targets and you're editing one of them - and you set the profile level property, behind the scenes, the profiler brings the other 3 execution targets into "edit state" to make the change and will eventually write all 4 targets back to the application hub.  Going to edit state to change the rules requires unzip of the can file from the network server onto the profiler machine.  If the profile/targets are large, this can be a very painful operation to accomplish a single boolean set, but this is how it is.  If you make this change, be aware of the large behind the scenes work that the profiler is doing.  Grummble yell a bit and then it will be done.

Fun with streaming - Great entertainment in isolation circles

Turn on the -x RadeRunSwitch so you can an isolated command prompt when you launch your next favorite streamed application.  This assumes you have user updates disabled, which is the default.

cd c:\windows\system32
c:\Windows\System32>notepad.exe
< it runs >

c:\Windows\System32>type notepad.exe
< see textual giberish - the file open succeeded for read access from CMD.exe >

c:\Windows\System32>copy notepad.exe n.exe
        1 file(s) copied.
< file copy was successful - n.exe is at the per-user layer of isolation >

c:\Windows\System32>type n.exe
< see textual giberish - the file open succeeded for read access from CMD.exe >

c:\Windows\System32>n.exe
The system cannot find the file c:\Windows\System32\n.exe.

FIREWORKS HERE!

The isolation system LIED to the Windows Loader - returning ERROR_FILE_NOT_FOUND (2) rather than completing the loaders request to run this file from user layer of isolation.  This is what this setting does!

But wait, there's more!

c:\Windows\System32>copy n.exe notepad.exe
        1 file(s) copied.

c:\Windows\System32>notepad.exe
< it runs!! >

Why does notepad.exe succeed in the final case?  Easy, there are two notepad.exes.  At the per-user layer, there's a notepad.exe which was written on the file copy from n.exe.  We don't care what this file is, but it is executable content and it exists at the per-user layer of isolation and therefore it doesn't exist for purposes of running programs.

Since the "Enable user updates" setting is set to disable user updates, executable content at the per-user layer of isolation does not exist from the perspective of the Windows loader.  BUT - at the physical layer, there does exist a file with that name and this can satisfy the file open, without violating the isolation rules.  There could also be a file with that name at the application installation image layer.  In this example there wasn't, but there could be.  The isolation system starts at the top and goes down until it finds a hit.  If "Enhanced security" is enabled, then the per-user layer is "off-limits" for execution of executable content.

The grand result

The application "update" applied by the user may have been applied as far as the user or application is concerned, but in reality, it was not applied.  The version of the application that is running is the version that the administrator profiled.  Pretty cool stuff.

Why did we rename the setting?

Putting "security" in the title implies that this will somehow prevent users from doing things to run content that they download and this is not what it does.  If the program updates itself, then this setting will block that content from being executed.  The setting can also block user installed additions to the program (plugins), depending on the location to which they were installed - was it included as an isolation rule during profiling?

Take a web browser for example, if the user downloads executable updates to the browser, this will be captured and the user installed stuff won't run, but if the user downloads evil.exe and places it on their desktop, and then double clicks it - this will be outside of isolation so the layers here do not apply.   This is also true if the user downloads evil stuff to locations outside of isolation and launches it from the isolated application.  It will still run isolated, but it will run!  Describing this activity as "disable user updates" is more accurate than the previous words, so we've made the change.  I also hope that it removes confusion in the streaming profiler wizard.  "Enable user updates" is pretty easy to understand.

How should you create your profiles

1) Enable user updates should generally be "off".  Plugins are a rare need and where there is a real need for users to add plugins, start asking yourself if you can add those plugins at profiling to the common layer.  OR, if the use of user installed executable content is large, should this application be locally installed rather than isolated?

2) Always tell the application to NEVER update itself at runtime.

 A look to the future

Streaming dev team are discussing removing this option from a future release.  That is, "Enable user updates" will always be OFF.  I'm not sure of all the ramifications of this yet.  The question really is "how many admins are profiling their applications with user installed updates permitted"?  I hope the number is "few".

Joe Nord

Product Architect - Application Streaming

Citrix Systems

To use agent-less streaming or installed agent streaming; that is the question.

I have received inquiries recently - lots of inquiries on the same question actually - that all imply that "user mode" streaming and isolation is "better" than evil kernel driver streaming and isolation, because it doesn't have any kernel components.  This sounds exciting on first glance, but when you dig down the problem is more complex.  There are advantages to installed isolation systems and there are advantages to all user mode.  This blog shows some examples for both categories. 

To get it started, consider an isolation system's ability to load and isolate a Windows NT Service.  How can you isolate the execution of an NT Service if the isolation system itself is "user privilege".   At user rights, the isolation system lacks the privilege to start a service that isn't already installed, so it can't run and isolate services unless the service is already installed outside of isolation.  

Scalability is also a big concern.  It doesn't matter for a small system, but if you load the machine up with lots of users and lots of applications, having a separate copy of the installation system for each application becomes problematic.  

On the plus side for agent-less, it is really nice to NEVER need admin rights on the execution machine and this can help engage work from home or kiosk environments.    Another plus for agentless, the "attack surface" is smaller if there are fewer privileged components; this is the point that usually starts the conversation that "agentless is better".   Keep reading...

First, some definitions:

Agent-less streaming

Nothing is "installed" into the machine.  The isolation engine can run the profiled software without ANY components themselves being installed.  "Admin" rights are never required and the system usually embeds the isolation system and profiled application into a single .EXE image that is "executed" to run the isolation system and the isolated application.

Examples of agent-less isolation systems include ThinApp, InstallFree, XenoCode.

Installed agent streaming

With an "installed agent", parts of the isolation system are "privileged", they require an install time execution which usually includes the installation of at least one kernel mode device driver and generally also includes the installation of a NT Service that supervises the sandboxes that are active on the machine. 

Examples of installed agent isolation systems include Citrix Application Streaming and Microsoft App-V.  Even this is a simplification as the Citrix system uses kernel mode for process monitoring and file system filtering and USER MODE for registry filtering, which makes it kind of a hybrid.  App-V uses kernel mode for both.   The real key is that an installation step was required.  If you require an "install", you are a member of the installed agent camp!

Which is better?

The answer is simple: Mine! 

The real answer is that you have to ask what "better" means.  I mean, better at what?  Each of the systems have their advantages.

Consider installation

Not needing to install an agent is handy for some environments especially where the execution machine is not company managed.  USB Thumb Drives were the original player here; you can take you application anywhere!  By contrast, if you're really running in a company environment, either stream to client, running on a XenApp Server or even on a XenDesktop hosted world, the installation of an agent is not a gate - the admin controls the base image and can install any agents that they want.   For more on this, see "security" below.

Consider scalability

If you are running a heavily loaded XenApp Server.  Let's say 64-bit machines, with 64-bit Operating System, a handful of high end CPUs and enough RAM memory to run 100 concurrent users, with each user running 5 distinct isolated applications.   How many isolation spaces is that?  100 * 5 = 500 isolation spaces.  If the isolation system is 100MB, that's 500 * 100MB = 50GB of allocated virtual memory just to load the isolation engines.   I made these numbers up, but stick with me on the concept.

How many separate copies of the isolation system do you want to load?  Answer: One would be nice.  

With kernel mode or NT Service isolation systems, you'll have ONE single code space for all of the isolation sandboxes, a bit of instance memory for each sandbox and other than that, you're off and going.

This too is a over simplification.  For starters, the Citrix App Streaaming case is a hybrid.  I haven't checked the memory footprint lately, but the kernel pices are ONE and the registry and named object pieces are MANY as these are implemented inside the isolation space.  To get back on subject for this post, think of it as ONE installation system because all "installed agent" systems are in the same camp.

Does agentless mean that there is really a separate isolation engine for each application?  yes and no.   We tend to generalize this to say that the isolation engine is carried along with the to be run application.

If the agentless isolation system uses DLL references to get to the isolation engine, then the agentless system's memory load will be page table shared across the images.  This a function of the Windows NT PE Loader and memory manager.  With DLL load of the runtime, many pages of the 500 instances of the isolation system will be shared.   I don't know if the clientless systems use DLLs for the agent runtime, but if they don't, they could and this will share the load.  

Citrix App Streaming uses DLLs for the registry filtering, so the shared model here still applies (ONE).  

How to update the agent

If the isolation agent needs to be updated, how many application images do you have to update?  This is a plus and a minus for both again.  With installed agents, you update one and all the profiles/sequences benefit.

With agentless, you have to touch each of the isolation images.  Or, back to the DLL approach, you could achieve the same ONE update in agentless if you're using DLL based runtime.   

If go with the "one app, one executable to distribute" model, then the isolation system is not shared and the memory usage on a XenApp hosted model will totally suck.  Prototypes will be great, but actual performance under load will be a heavy hit to single server scalibiltiy.  When it comes time to update the isolation agent, you'll have to touch all of the profiles to get things updated; or you can skip this as a plus toward not having to maintain anything once you profile it.

Consider security

There is a perception that if kernel mode components are involved, then it's less secure.  This is mostly a statement of "attack surface".  There are many privileged components in the machine and they are all candidates for attack.  The real headache with privileged components is that they have to be "installed", but the security aspects still apply and are real.  

If you're installed and you have power, then you can do powerful things.  The corollary is that if you are not installed and you don't have power, then you CANNOT do powerful things and this is as much a plus as a minus.

Consider that many agent-less streaming systems receive "yes" check-boxes in comparison matrices when discussing isolation of NT Services.  

Either you're USER MODE or you're not user mode, you can't claim to be both.  

A step back: NT Services are installed applications, with no GUI and no direct user interaction.  Services run on either a powerful system defined account or a named user account of install time specified rights. "LOCAL_SYSTEM" and "LOCAL_SERVICE" are the common installation configurations and these equal "powerful".

In many cases, the reason that the programmer went through the pain to write a service is that they needed to do something with privilege and that was impossible from the user privilege application space.  This is why they are done in the service rather than in the application itself.

If the isolation system is agentless (user mode), and if that isolation system can load and isolate NT Services - and have that service work - then a boundary has been passed and the isolation system is no longer user mode.  Given that the agent itself would not be privileged, how can the applications that it runs be privileged?

Answer: The agentless streaming system requires the applicaiton services to be installed outside of isolation, and by installed, I mean REALLY INSTALLED.   This pretty much deletes the check-box for isolation of services.

Some NT Services likely CAN tollerate user mode execution under isolation, but for the general discussion, the answer will be that this breaks down and the service requires installation to the local machine - breaking the isolation boundary between the application and the local machine.
An "installed agent" isolation system CAN have the power to start services itself, and in this environment CAN run the service isolated.  This is only possible because the agent itself is INSTALLED and has power.  If the isolation agent is not installed, then the user cannot start isolated services and there's a pretty big gap in the claimed support of isolated services.  The services have to be outside of isolation and installed - they aren't isolated and the access to that service is not governed by the published application set.

Consider application launch performance 

Now that Application Streaming 5.2 client is out (real-soon), I can describe the greatness of 2nd time application launch.  If a sandbox is running that will support this app, there is no longer ANY need to create an isolation space for a second, third or fourth application launch.   Creating an isolation space/sandbox/bubble is an expensive operation.  The 5.2 client's ability to skip this expensive operation will provide great benefits in launch speed.  I describe this briefly here, but need to write more.   

Can agentless do things to equal this application launch performance?  Can it toss execution over the wall to already running isolation spaces?  Probably, but as an big executable based execution, by the time they run to make this decision, they will already have the isolation system mapped into memory and it's big and I'm betting, slow.  Bottom line, I'm looking foward to a new round of statistics with the 5.2 client - we should kick some major butt!  "Agent based" here has advantages, but this alone will not sway a discussion.

Consider central management
Both Citrix Application Streaming and Microsoft App-V are heavily predicated on the concept of communication with a back-end infrastructure and administrator driven management of the applications available to users and even preventing the execution of non-approved applications. 

The applications are published to users and in App-V case, users or machines and both systems communicate information back to the central authority to decribe the use of applications.   App-V can even block the launch of applications based on license metering.  All of this is enabled because of communication with back end, from an installed agent.  

Can that communication be done from an agentless system?  Probably.  Is this done?  I'm not sure.  If it is done, is that something you really want happening from a user privilege component?

What applications are available to the user and how can I trigger the update of application content?  What applications have been actively used across my whole organization and which ones are published that the users really don't care about?  What applications should I focus my support on and which ones should I deprovision without telling anyone?  Do I have enough application licenses?  

All of these questions can be answered with back end information.  Agent-based makes this easier.   Having a NT Service hanging out to collect this information and centrally report back statistics is an opportunity for central management, control and monitoring of applications.

Then again - agent-less can get most of this too. 

For example, Citrix EdgeSight monitors application usage on a machine and reports this back to make truly beautiful reports that tell the admin what has been happening on their machines.  It doesn't matter if the applications are isolated or not isolated, the EdgeSight monitoring system still sees them and can report on usage.   This happens for Citrix Application Streaming and can just as easily occur for clientless based isolation system.   

Conclusion 

Is agent-less better or is agent based better?  The answer really depends on how the whole system will be architected and what control the administrator has on where the agent will be installed.   Both have advantages.

Joe Nord

Product Architect of Citrix Application Streaming (An agent based isolation system)

Citrix Systems - Fort Lauderdale, FL

The following is the Q/A session from the XenApp: Fact vs. Fiction - The Truth about App Compatibility with Citrix TechTalk.  For those of you who missed it or are wondering where to get materials, they can be found here:

• Recorded TechTalk
• PowerPoint
• Application compatibility site
• Community Verified site

Q: does the appcompat site differentiate between verification with xenapp hosting versus xenapp streaming?
A: Yes. In the platform column, you can see the product and whether it was hosted or streamed

Q: does per user image mean per user per app or per user for all apps
A: Per user per app.  Essentially, within the user's profile, you will have a GUID on the file level the registry level. Each GUID corresponds to 1 app. As this information is stored in the user's profile, you get down to 1 user and 1 app personalization.

Q: Is streaming licensed for XenApp 4.5 EE?
A: Yes. Enterprise and Platinum edition of XenApp 4.5 and 5 gives you App Streaming

Q: What is the difference between Stream to XenApp and Application Isolation?
A: Application streaming utilizes isolation environments. In older versions of XenApp, you could install applications into an isolated environment. The Isolation Environments are now only available as part of Application Streaming.

Q: Your Twitter site.
A: http://twitter.com/djfeller

Q: Daniel...need to know what hardware you use for your home setup? how many boxes do you have?
A: My personal lab setup is very simple and not a typical implementation.  I'm only looking at functionality and not scalability. Two powerful workstations (Quad core, 8GB RAM, 500MB storage).  Both systems are configured with XenServer. I also have a 1TB Debian Etch system I use for XenServer shared storage.  Within XenServer, I have 1 Domain Controller (SQL and File share), 2 PVS servers, 4 XA servers, 2 WI servers, 2 XD servers, 10 Vista and 10 XP workstations, 1 App Profiler

Q: It sounds like when streaming, the application runs on the client. If so, doesn't this defeat the purpose of XenApp ?
A: You can actually stream applications to the client (client-side app virtualization) or to the XenApp server (server-side app virtualization).  App streaming helps overcome app compatibility issues on either location. Doing client-side allows you to use some of your workstation's power and allow you to continue using the application if the network link is broken.  While XenApp streaming allows you to centralize hosting, better scalability, and better security, plus all the other benefits of XenApp.

Q: Do you recommend streaming for PACS app with high resolution graphic and clips
A: I would test to see if it will stream. Some applications just won't stream, especially if they have a Windows service or drivers.  Now if the app can be streamed, then you will need to see if the app performs adequately on XenApp with the graphics. I've seen many people have PACS on XenApp with great results when they use the SpeedScreen Progressive Display technology. 

Q: For offline... how much disk space for your apps. Slide 27 / 28?
A: Depends on the application. Some examples from my apps: Office is 1.1GB in size. Adobe Acrobat is 160MB, Firefox is 12MB. Remember, these are the sizes of the app profile that is copied to your local workstation for offline mobility.

Q: Would apps that require back-end connections work offline? It seems this should not without being connected to the network/internet... correct?
A: Correct. There is another TechTalk (XenApp: Take Your Data with You: App Streaming ) that talks specifically about App Streaming and offline mobility and covers this item. But long story short, apps that require backend data shouldn't be streamed for offline as they will more than likely be useless (although there are exceptions).  If the app syncs when back online, then you can stream for offline (Outlook is perfect example). 

Q: We're using linux and MS based Neoware thin clients almost exclusively. What problems does this present?
A: Well, you can still do server-side application streaming.  Right now, the streaming plugin (offline apps plugin) is only available for the Windows platform. Many of the thin clients also use an OEM version of Windows XP or do not include enough hard drive space to store the application cache.  You might want to look at XenDesktop which would give these users a desktop-like experience if that is what you are looking for. 

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

When I was an SE in Southern California back in the day, I had a toolkit that I always referred to for specific things. If you know me from those days, you knew that my biggest tool was the wtsuprn.ini file that I had created to map printers in NT 4.0 and Windows 2000 to the correct drivers on user devices. I was addicted to amassing as many mappings as humanly possible. But I had other things too - for example, a set of utilities that I would use to help troubleshoot applications that I wanted to install on XenApp servers. Well, I was talking to a customer today and it made me think back to those days and consider what my application validation toolkit would look like today.
First and foremost, my number one prescription for any application is application virtualization. This, in my experience, has offered the highest level of application compatibility with the least effort. Basically, what this entails is using the profiler tool in XenApp to package your applications. You create a single package that targets multiple operating systems. What's cool about this is that you can include registry keys, scripts, files, and anything else that you want into the application package. Examples might include a specific version of a system DLL that the application requires but which makes other applications fail. You would just isolate the file in the application package and it is made available to the application during run-time without overwriting the system DLL on the target device. Another great benefit of application virtualization is local and offline application delivery. I can essentially deliver apps to servers much faster but also to PC's and even for use while users are disconnected. This is ALWAYS my first step at delivering any application with XenApp... even those that I know will install directly without a problem.

Alas, application virtualization isn't a silver bullet for everyone. Maybe your vendor won't support it and that's a problem for you. Or maybe the application uses a service that can't be isolated. Well, in that case you might need to use a hybrid approach. You have three choices (I've listed them below in order of my preference).

1. Profile the app and stream it (we've already talked about that)
2. Install the service onto target machines and virtualize the application components (basically profile the app and stream it. It will be able to communicate with the installed service on the target device at run-time)
3. Install the application (this is the traditional method of delivery to XenApp servers)

If you have to go with 2 or 3, then you might need tools to help coerce some "poorly written" applications into working in a multi-user environment. Here is my list of utilities and resources that I would use to give customers and partners advice or to troubleshoot the applications myself. Some are resource lists, others are built into XenApp, others are available as free/shareware or for purchase. If you have a tool that you use, add it to this list as a comment. Let's build a list of resources together.

I hope this core list helps you. If you've got other tools, by all means... please list them below as comments and give us a little information about them. Also, I'm interested in knowing how many of you are using application virtualization and profile management. To that end, I'd appreciate if you could complete the quick poll's below. Here's to the community.

UPDATE: You may also wish to check out the TechTalkthat Dan Feller is doing on Application Validation.

Vinny Sosa

Q: Any recommendations for hosting or streaming components such as .NET, Oracle Drivers, MQ drivers, teradata, DB2, etc ?   

A: Many core OS components will need to be installed as part of the base image. Things like anti-virus, drivers, .NET. 

Q: Is there a place to find this "Leverage Existing Infrastructure" slide or the info later on?

A: Yes. In the next few days there will be 3 articles released to the knowledgebase called: Simplifying Application Delivery to the Virtual desktop (Reference Architecture, Getting Started Guide and Implementation Guide).  The item you are interested in will be part of the Reference Architecture. 

Q: Can you elaborate on the nature of the Citrix Receiver? One of the main benefits to XenDesktop, supposedly, is that it's clientless. It seems that the Citrix Receiver is a client...   

A: Nothing is clientless. Even a web browser is a client.  But in order to get to a virtual desktop, you will need a client application, the Citrix Receiver. Now the nice things about the Receiver is you aren't forced to install 20 different clients. This one client will provide you with all the features needed to receiver your virtual desktop.

Q: Could we possibly see a demonstration of a virtual desktop session?   

A: You can take a look at the items on this page: http://www.citrix.com/English/ps2/products/demo.asp?contentid=163057#top

Q: If we pre-cache the app on the VDisk - aren't we coupling the app with the vDisk. 

A: Not really. I consider installing an application to be coupling the app to the vDisk. Doing a pre-cache just optimizes the write cache so the app starts faster.  Remember, with streaming, the application is not installed and you only see the applications you have been granted.  Now if you have pre-cached an application and you now have an application update, do you update the pre-cache? Depends, of course.  If the update is major, meaning it changes many files, then I would update the pre-cache because these updates will cause the write-cache to expand. However, if the update is minor, meaning it only changes a few files, just update the application profile package and forgo the pre-cache updates. When the pre-cached application starts, the updates will be streamed down to the virtual desktop. This will increase the size of the write-cache, but because the updates are so small, the write cache growth will be small.

Q: Do you maintain a list of applications and how resource intensive they are?

A: There is a Citrix site called Citrix Ready (CitrixReady.com).  There are a fair amount of applications listed on that site. 

Q: For those of us who have not moved into the XenApp Realm yet and are trying to determine which product meet our needs, is there a better source of information, or a 'buyers guide' that helps us determine the correct path, XennApp, XenDesktop, etc?   

A: See if this document helps: http://www.citrix.com/%2Fsite%2Fresources%2Fdynamic%2Fsalesdocs%2FXenApp-XenDesktopTogether.pdf

Q: How many users can access a single vDisk from Provisioning Server with XenDesktop? An example...How many Provisioning and DDC servers will I need for 500 employees vs 1001+ Employees? 

A:   Take a look at this recently completed scalability document.  http://support.citrix.com/article/CTX119775

Q: If I still have to manage the client why would we want to create XenDesktop? I am not seeing the return based on the large infrastructure this will require to install.   

A: Excellent question.  There are many scenarios where it makes sense.  Below are a few, but there are many more. It all depends on your business and challenges experienced with the distributed computing model. # Forgo workstation upgrades but still utilize the latest Operating System and applications. Ever run Vista on an old workstation? You can now

1. Use Desktop Appliances: They are slim devices that simply connect to a virtual desktop
2. Remote users: Use your home computer without having to install apps or copy company data
3. BYOC: Bring Your Own Computer allows you to use your own personal workstation while still having a secure and separate corporate computing environment.

Q: Since streaming is regarded as a primary delivery recommendation, how do you get the network team on board since they occasionally present resistance towards this distribution method 

A:   Yes, working with the network team is critical.  How much data do you think is transferred just to boot the OS?  Remember, we ONLY stream the parts needed. So even though Vista is gigs in size, we are only streaming about 180 MB of data.  XP is roughly 90MB. However, for enterprise deployments, you would want the physical design of the environment to have both ends of the stream to be in close/fast proximity.  The Provisioning Server should be located on the same high-speed network as the XenServers that will receive the stream for the virtual desktops.  This helps control where the network usage is going to occur. 

Q: You mentioned that if there are applications that need a lot of resources and they are installed on XenApp server they could hog the XenApp server.  Does XenApp have an HA (high availability) architecture that would allow distribution of the XenApp load dynamically to hot standby XenApp servers?   

A: XenApp does have a powerful load-balancing solution to distribute load based on any number of configurable parameters (CPU, memory, page swaps, user load, etc).  However, these algorithms only come into play during the start of a new session. Once your session is on a XenApp server, that session remains on the XenApp server until the session is closed.   So, you could wind up with a bunch of users on a XenApp server (which is good), until someone runs a resource intensive application that can potentially slow down the entire server because resources are shared. 

Q: You recommended Stream Applications for Base, Anomalous and Resource Intensive apps.  Stream from where, from XenApp? 

A: Yes, application streaming comes from XenApp.  The XenApp servers will manage application enumeration and launching. If you select a streamed application, you will obtain the stream from the Application Hub (like a file server) controlled by XenApp. 

Q: What is a hosted application?

A: A hosted application is one that executes remotely on XenApp.  All resources used are resources on the XenApp server.

Q: What happens when Provisioning Server goes down?  Are existing workstations cached and still working and only new stream requests are impacted?  Or are all workstations down? 

A: Because there is no local disk on the provisioned desktops, if Provisioning Server fails, the desktop pauses until the stream is reestablished.   This is why we recommend turning on the HA option for Provisioning Server.  This will help overcome this potential risk.

Q: When pre-caching the streamed apps, would you recommend storing those in the base OS vdisk or in a separate disk attached to the VMs?   

A: Pre-cache into the OS vDisk.

Q: When Streaming apps, will I run into problems when I have a suite of applications that make calls to each other. I.E. MS Office, Email and Document Management Systems?   

A: Not with XenApp 5 application streaming. In previous versions, applications could not talk to applications in different streams, but that challenge was overcome in XenApp 5.  So if you put Word, Excel and PowerPoint in separate application streams, they can still work together.

Q: Would this work for remote users, or is network connectivity required

A: Right now, you need a network connection.  But Citrix has announced Project Independence which provides a client-side hypervisor where we can think about doing offline virtual desktops. Take a look at the video: http://community.citrix.com/display/xd/independence

Q: What is the process for preparing an application for streaming?

A: You need to run through the installation of the application with the Streaming Profiler.  The profiler will take the installation and create an application package used for application streaming. Once the profile is created, you simply publish it like any other XenApp application.

Q: What is the typical time to first launch for a streamed application? 

A:  It depends on the application size and the network speed. When properly configured, the actual streaming of the application should be very fast, one or two seconds)

Q: What type of apps are not appropriate for this solution? 

A: There are still some issues with applications that install services on the system or install OS-level items (.Net, drivers, etc) .  Many of the other challenges have been overcome.

Q: Are streamed applications isolated to the extent that they are not aware of and cannot interact with another streamed application?  

A: Yes and no.  Yes in that what you say is correct. Streamed applications do not interact with other streamed applications. However, in XenApp 5 you can configure rules for the applications so they can talk to other streamed applications. It is a pretty cool feature that overcomes some major challenges with application streaming.

Daniel

XenApp enables IT organizations to reduce the costs of delivering applications by centralizing management, security and control of apps and data. Application virtualization technology provides a flexible application delivery system that can select the best method to deliver an application dynamically, based on the user, application and network.

This next embedded presentation digs down much deeper into the application virtualization technology included in Citrix XenApp 5.0 .

(click here to see the presentation in full screen)

You can download the Delivery and Streaming Best Practices document here and the Office 2007 Profiling document here. The Administrator FAQ is here and you can find a Troubleshooting document here.

You can download a complete virtual appliance of Citrix XenApp 4.5 at this link.

Yesterday, we released the Application Streaming Profiler SDK version 1.2, and it is now available as a free download.

This SDK allows creating applications or scripts that automate the management of streaming profiles. The API allows creating, updating, reseting and deleting profiles, and can be combined with automatic starts of unattended installers. Without this SDK, these tasks could only be done through the Streaming Profiler user interface and would require the physical presence and monitoring of an administrator.

Here follow a list of improvements in this second release of the SDK:

• New APIs for Inter-Isolation Communication profiles: The New IRADEPackage2 classes include support for defining links between profiles.
• Includes the TLB file that allows the easy creation of COM client applications with C++.
• Includes and explains multiple working samples in both C# and C++.
• The files included in this SDK are better organized for easy navigation.

For more information about Application Streaming see the product documentation or search for "Application Streaming" on the Citrix Blogs, and for detailed questions about the SDK, visit the dedicated Community Forum. Also, keep monitoring the Citrix Blogs because Joe Nord, our Product Architect for Application Streaming, will soon post entries to further explain the Streaming Profiler, the SDK, and this release.

Very important: we want to know about your experience with this SDK:

• Have you been able to use the SDK effectively?
• What else would you like to see in the SDK?

Lastly, XenApp 5.0 was announced earlier this week. If you want to learn more about it, you should not miss Citrix Delivery Center Live. This live virtual event will take place on September 9^th. Make sure to register now!

We are always picking sides, our favorites! Today there is a growing debate on where application virtualizationshould be performed, 'client side' or 'server side'. The concept of separating the application from the underlining OS can be done on the client (Desktop/laptop) and on the server.

Many references to application virtualization (http://virtualfuture.info/2008/06/virtualfuture-appchart/) are usually about client side application virtualization. Products like SoftGrid, ThinApp, InstallFree and  XenApp application streaming (the application virtualization feature within XenApp) are mainly referring to the client side of virtualization. All these products do a great job of server side virtualization also.  In many XenApp installations customers are using server slide application virtualization to improve the return on their XenApp investment. From what I've seen there are more server side implementations of application virtualization, now the idea of client side application virtualization is getting into the spotlight.

There seems to be a debate brewing as to which is the best way to go - client side or server side? Do you run the traditional server based model of computing and delivery apps to users from the server or is it better to deliver  and run the apps as close as possible to the user on their PC? The good news is that application virtualization is applicable to both client and server side, so at the end of the day as long as you are looking at virtualization your applications you are heading in the right direction. Can you get the best of both world? The ideal scenario would be to prepare your applications for virtualization once and then decide later as to where would be the best place to execute the application, client side or server side. Even better would be a system that can decide based on policy, users connectivity or application usage controls where to vertualize, at the client or the server. The ultimate would be a system that can change where the application is virtualized and executed, based on the above scenarios - so in one instance you run your application on the client, and then, say, when you're, outside the corporate firewall, you would run the same application from the server. Of course you want to only use one instance of the virtualized application in both cases.

XenApp is an application delivery system that uses both client side and server side application virtualization to deliver applications in the most optimal way depending on policy. The application hub within XenApp stores the profiled applications and delivers the same application to the client or the server. Anytime the application is modified or needs to be updated, you only need to make the changes to the profile in the application hub and the virtualized application on the client and/or server is updated automatically. You can profile and store all your Windows applications in the application hub. Additionally XenApp works with Microsoft 'SoftGrid' application virtualization and other application virtualization technologies. XenApp is the overall delivery system for all windows applications. For example if you are using SoftGrid as your application virtualization technology that's fine, the XenApp delivery system still works in the exactly the same way, even more you can mix both SoftGrid and XenApp virtualized applications within the XenApp application delivery system. So if there is a specific feature within application virtualization you need, or you have already bought an application virtualization technology or you prefer a specific application virtualization vendor; you can use a specific application virtualization technology within the XenApp application delivery system.

The next version of XenApp which will also be on the Windows Server 2008 platform will provide even more features to enable application virtualization with XenApp. You should be using both sides of application virtualization; enabling all your Windows applications for all your users. You no longer need to decide which application virtualization side you are on, you can be on both sides, delivery the best of all worlds.

Are you working on both sides?

This is a wicked cool session where our guys in EMEA teach you the core of Application Streaming technology.

If this is something on your radar, I highly recommend watching this videocast.

Watch it offline

cheers,
Gus Pinto
Follow me