Post to Twitter
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:
- Describe the panels
- Describe what the settings do
- Examples of how this effects application execution
- 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