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