Microsoft Application Virtualization 4.5 beta - Lightweight Server impressions

The next step in a first peek at the 4.5 beta of Microsoft Application Virtualization is a short investigation of the Lightweight Streaming Server (LWS).

0. Introduction

The Heavyweight Streaming Server offers full blown streaming and desktop configuration options with a dependency on SQL/AD backends. The LWS version on the other hand, does not depend on these Active Directory and SQL backends, and does not even require a SoftGrid management console to operate properly.

Its intended use is deployment in branch offices: it can stream FB1 and FB2 data to clients that require additional data, and it can be used to authorize application usage in branch offices. This means that a client can launch an application from an OSD file that points to a LWS. The LWS cannot perform desktop configuration, this functionality is only offered in a HWS installation.

The following picture shows a typical deployment scenario for a LWS server in a branch office.



The SoftGrid client is connected in the branch office. Here is the remainer of the configuration

• The main office contains a HWS server, which uses the well-known SQL and AD backends, and uses a fileserver to host the SFT/OSD/ICO content.
  
  
• The branch office uses a LWS server that uses a non-specified algorithm to keep its local content directory in sync with the content fileserver in the main office.
  
  
• The client is configured to perform a desktop configuration refresh against the HWS server in the main office, which delivers the list of applications that the user has access to.
  
  
• The ApplicationSourceRoot, IconSourceRoot and OSDSourceRoot point the client towards the local LWS server whenever it needs SFT, ICO or OSD data (more about these configuration options in a post on the 4.5 client). This means that the hefty load of transferring OSD/ICO files during a desktop configuration refresh is taken away from the WAN link.
  

This makes the advantage of having LWS servers in branch offices clear immediately: in the 4.1/4.2 versions of the SoftGrid server, a desktop configuration refresh could mean the transfer of several hundreds of kilobytes of data per client, per refresh over a WAN link when no SoftGrid server was present in the branch office (and even with a SoftGrid server present, there was still some chatty behaviour between the SQL backend and the SGVAS server). All these problems are remedied by pointing the clients towards the local LWS server that uses a WAN-bandwidth efficient mechanism to keep the content in sync (... do I hear anybody say "SMS/SSCM distribution point replication"?).


1. Installation

The LWS server comes in a separate MSI file that is included in the Microsoft Application Virtualization 4.5 package. The prerequisites of MMC3, .NET2.0 and IIS are not needed for the LWS server. The installation is straightforward:

• The default installation path is "C:\Program Files\Microsoft SoftGrid\Microsoft System Center Virtual Application Server". This is the same path as the HWS so I suppose some care needs to be taken in case you want to mix a HWS & LWS installation on a single server (why would you want to do that anyway??).
  


• As with the HWS, it is possible to configure a server certificate, default server port (554 for RTSP, 322 for RTSPS) during the installation.


• The only thing needed during the configuration is the "content root" which is the location of the SFT files that you want to stream. This will typically be the folder that contains the replicated files of your main office's content folder.


• The entire streaming server configuration is summarized in a single screen during the installation:
  
  
  Most of these options are familiar from the HWS server's advanced configuration. Here's an educated guess at what the non-trivial settings mean:
  
  
  
  • Client connection management
    
    
    
    • Enable User Authentication: when disabled, the user's credentials are not checked when attempting to launch an application.
    
    
    • Enable User Authorization: when disabled, the authorization to use a package offline is not passed along with the launch of an application.
  
  
  • Package management
    
    
    
    • Cache Block Size: this could be the amount of memory that is cached per application to stream from, i.e., some sort of buffer that is filled for each application that is launched.
    
    
    • Max. Cache Size: the maximum amount of memory that is used for caching; this should in principle be the maximum amount of memory used by the LWS service (and core processes).
    
    
    • Package Detection Interval: the amount of seconds between each scan of the content directory; this scan is used to construct the package list that this LWS server offers.
    
    
    
    
  I must stress that these are interpretations that I give from my personal experience and that they can be wrong; anybody with corrections or a better knowledge, please let me know!
  

After the installation is finished, no visual footprint of the LWS server can be found: there is no management console or an icon that allows to do "anything". What we find back is the "SoftGrid Lightweight Virtual Application Server" service that runs in the background.

2. Internals

First of all, let's immediately get over the myth that the LWS server does not require anything Active Directory related at all; the server that hosts the LWS must be a member of the domain that your users belong to. When you authenticate users, this is against the Active Directory.

Furthermore, some AD connection is needed because supposedly the LWS will grant users access to the applications that they have access to based on the NTFS permissions of the files in the content directory that you specified during the installation.

Some more things that you might find interesting:

• From the moment a user has read permissions on the SFT file of the package that is being started, the LWS server will authorize that usage. This check can be bypassed by disabling the user authentication, either during the installation or by changing the registry key EnableAuthentication to zero.
  
  I noticed during my tests that setting the EnableAuthorization to zero, would also automatically put the EnableAuthentication to zero (i.e., disabling authorization also disables the authentication checks).
  
  
• The LWS server seems to require 4.5 clients; older client versions will give "Error parsing the XML file" messages when attempting a desktop configuration refresh against a LWS server. But even with 4.5 clients, a desktop configuration refresh is not possible, an error message saying "The server threw an exception" is listed. To me, it is not clear whether or not the LWS can perform a desktop configuration or not.
  


• The configuration of the LWS is placed entirely in the registry at the following location: HKLM\Software\Microsoft\SoftGrid\4.5\DistributionServer. Interesting name, that hints at a future integration with SCCM distribution points if you'd ask me.
  
  
• The application metering statistics of a LWS server are not stored anywhere. When launching an application that points directly to a LWS, or that was redirected there by using ApplicationSourceRoot, does not log the usage information (even if the HWS server is chosen as the desktop configuration server).
  
  This means that your reports pulled from a HWS server will not include the launches that were allowed by LWS servers.
  

3. Roundup

The LWS server seems to be the long-awaited answer to the branch-office scalability issues that haunted the older 4.1/4.2 SoftGrid servers, without eliminating streaming completely as is the case with using a "stand-alone" mode of the SoftGrid infrastructure.

The Microsoft Application Virtualization client can be redirected towards the local LWS server by setting the appropriate ApplicationSourceRoot, IconSourceRoot and OSDSourceRoot registry keys, thus achieving the context-aware streaming that we have been waiting for (without the burden of setting up a replicated database or a full blown dedicated SoftGrid server in a branch office).