The App Streaming “next” release will support isolation of NT services. A tech preview is available for download now as part of the larger XenApp Parra tech preview, download here. To download, you are required to register for the technical preview – this separate from normal mycitrix credentials.
Update: This was released as product in version 6.0
App Streaming “big items” in the preview:
1) Isolation of NT Services
2) Depreciation of CAB files in favor of unzipped directories, link.
What does isolation of services mean?
First, what is a NT Service? The long version is this fine write up from the Microsoft MSDN. The short version is that a service is a program that runs outside the context of any user session, normally once for the whole machine. Services “generally” run automatically at system startup, but can also be configured to run on application demand. In concept, services are “high power” and user applications are “low power”. Services are “one”, user applications are “many”. Services run with no user I/O.
When a user application needs to do something that requires more power than a user application has, the low power app can send a request to the high power service and request that the service perform the work. Since the high power service is trusted, this can be accomplished without violating the system integrity.
Services are also commonly used to implement a central point of control, where multiple user applications contact the service and the service ensures single access to the thing that is single use. There are many ways to accomplish this exclusive access, but using a service is one solution.
The perhaps biggest use of NT services in App Virtualization space, is the implementation of licensing services. Here, a service exists to control permitted use of the application software. When the application runs, it contacts its service to see if execution is allowed. These can be implemented and “gated” on a number of factors including vision to a dongle, local machine restrictions and the more common, network implemented application licensing where a central licensing server is used to limit execution of the application throughout the enterprise. The classic problem for App virtualization is that if you cannot run the service, the application will refuse to run. This has been a headache for Citrix App Streaming since it’s first release, but will be solved with this tech preview and ultimately with the next release of XenApp.
Above said, one should understand the limitations. Just because you run a service isolated does not necessarily mean that the application will work. For example, consider a software licensing service that TIES the application execution to the same MAC address to which the application was “installed” or profiled. App Streaming isolation of services does not LIE to the application to change the MAC, so even if the licensing service is run, if the execution machine is different than the profiling machine, the application will still refuse to run. In a corporate world, the common scenario is a central licensing server which the licensing service contacts over the network – these will work; well, they SHOULD work.
In conversations with many customers, I have been asked, many times, about isolation of services. My question back to the customer is usually the same, what about privilege? Running services under App Isolation is conceptually not that hard. Running Services with PRIVILEGE under isolation and keeping the user space and system spaces separate, is hard. Put differently, deciding to NOT run services when you otherwise view it as an app is hard and preventing apps from escalating due to the availability of the service, is hard. This is why it has taken 4 years…
Services need to be “powerful”, or don’t bother running them; to run services in “user space” is an incomplete solution. Without privilege, you’ll have some services that work; but others that don’t.
Services exist often because the application programmer has privileged needs. If they could get it done from user space, there would be many fewer reasons to go through the hassle of writing a service and setting up all the communication between the user space application and the privileged service. This takes lots of work and for many cases, the programmer would not bother if they didn’t really need privilege.
The consistent customer answer:
- I do not mind running services, just make sure you run only the services I approve.
The tech preview will load and isolate services, but the code to “white-list” the services isn’t done yet, so for the moment, everything is white listed. This will be fixed for the production release where an admin only space will be used to limit the services that can be executed. Until then, don’t put the tech preview into production.
Isolating applications compared to “privilege”
Just because the service is run “with power” does not mean that it is run outside of isolation. Isolation and privilege are very different things, conveniently described here last month. The key is that the privileged service is still run isolated, so it’s runtime needs for profile content can be provided by the isolation system in the same manner that the isolation system supports user mode applications.
The App Streaming system will run the user space applications in their own sandboxes (plural) and execute the supporting NT services in a separate sandbox (singular – one per profile for the whole machine). This makes it possible to maintain the ONE service for the “machine” view that the applications may expect.
For the “layers of glass“, the service and the user space applications share the application image, but they will have SEPARATE user spaces, or the top layer of of the layers of glass. This means that cache fills to benefit the user application will also benefit the service in the same manner that two users support each other in a multi-user execution environment.
Isolated Services DO have network access
Some services install to run as user LOCAL_SYSTEM. Others may install as NETWORK_SERVICE or even to run on install time created user accounts. The install credentials of the service are reflected to runtime machine for the standard identifiers, but the user accounts installed services will be converted to run on one of the standard identifiers, which can be adjusted in the streaming profiler. Notice that LOCAL_SYSTEM has very limited abilities to talk on the network, so there are places here where running on non system credentials and the ability to reflect service run privilege can be advantageous. The particulars of these capabilities will depend on the application; the account used to run the services is configurable in the streaming profiler.
What does all of this mean?
In theory, it should bring a whole class of applications to the Application Streaming “App Compat” front. We have tested with the Beta of Microsoft Office 2010, which includes 3 NT Services, and it seems to work. Hopefully the tech preview of the Parra XenApp will show many other applications that will now “work”.
Please give it some exercise and let us know how it goes. Best place to comment is via feedback page and associated forum on the tech preview.
Citrix Systems Product Architect – Application Streaming and User Profile Manager.