Microsoft Application Virtualization 4.5 beta - Client impressions

After publishing a set of first impressions on the two MAV 4.5 beta servers, now it is time to do some initial tests with the 4.5 beta client. Here are some things that I came up with...

1. Installation

The first thing that one notices during an installation or upgrade are the prerequisites that must be met before the MAV 4.5 client starts its installation:

• Microsoft Visual C++ 2005 SP1 Redistributable package
• Microsoft Core XML Services (MSXML) 6.0 SP1
• Microsoft Application Error Reporting
  

These components are included in the MSI package that the client comes with, so there is no hassle of downloading components of the internet (in case all prerequisites are met, the installer automatically continues). Some remarks at this very first step of the client installation:

• The MSXML 6.0 installation triggers the installation of Windows Installer 3.1 (KB893803). This is not explicitly listed as a prerequisite but is also installed along automatically.
  
  
• My previous 4.2 client installation was detected and upgraded automatically. It was necessary to manually stop the SFTTray icon process (sfttray.exe) before the MSI installer allowed performing the upgrade.
  
  
• A reboot is required after the installation or upgrade (as was the case with the older 4.1/4.2 clients).
  

The automatic detection of non-installed prerequisites is very convenient. Let's hope this becomes a standard practice :).

2. Client Management Console

The visual appearance of the Client Management Console did not change a lot, and by starting the "SoftGrid Client Management Console" (which I suppose will be renamed to remove the reference to SoftGrid), we are again greeted by the familiar list of applications, filetype associations and desktop configuration servers.


There are some striking changes that are not immediately noticed:

• The remote management of MAV Clients is no longer possible. Yes, you read that correctly, you can no longer use a central Client Management Console to connect to another user's computer and to perform changes.
  
  This has the very unfortunate side-effect that it is also no longer possible to connect back to a local computer using different credentials (this was a very convenient trick to perform administrative actions in a SoftGrid Client Management console when taking over a user's screen when working within the user's limited security context).
  
  
• Logging can now also be done to the local event log (Application). The loglevel for the event log can be specified separately from the regular sftlog.txt file that existed already in earlier versions of the client, and is configured under the "System Log Level" dropdown that is shown in the figure above.
  

There are not other visual changes to the client management console.


3. New Client Functionality

There are some interesting new client functionalities that are available for configuration in the background:

• Dynamic Suite Composition (DSC): this functionality allows to merge two bubbles on the fly such that the two virtualized applications can communicate with eachother.
  
  This is very convenient for applications that depend on middleware such as Java, Oracle Client or Office; now you no longer need to include in each of your bubbles a copy of the Java or Oracle client, but simply merge a single SFT file containing Java with the application in question.
  
  At this moment, the DSC is limited to two bubbles (one bubble can be merged within one other). I will go into more detail on the DSC feature in a later post where I will explore the limits, how the merging is done, ...
  
  
• ApplicationSourceRoot, IconSourceRoot, OSDSourceRoot: it is possible to overwrite the SFT, ICO and OSD locations that are specified by a desktop configuration server. This allows to redirect traffic intended for one MCVAS server to another (for example, when traveling to a branch office). The redirection can be done to another MCVAS server (using URL) or to a UNC path.
  
  This redirection is done by changing the respective ApplicationSourceRoot, IconSourceRoot and OSDSourceRoot keys in the client's registry at HKLM\Software\Microsoft\SoftGrid\4.5\Configuration. For example, setting the ApplicationSourceRoot to "rtsp://localmcvas" will force the client to connect to "rtsp://localmvas/data.sft" when the original OSD file says that the SFT file that should be streamed is "rtsp://w2k3-mcvas/data.sft". For ICO/OSD files, one would typically use a UNC path or HTTP path for the redirection.
  
  The SourceRoot redirection can be a very powerful tool for branch offices in combination with the lightweight streaming server discussed in a previous post on this blog. With some clever loginscripting or GPO setting, you can now make the SoftGrid client context aware.
  
  
• Autoload functionality on clients: applications can be triggered to load FB2 data at a low priority in the background after the application has started and FB1 data has been loaded into the cache. This behavior is controlled by the AutoLoadTarget and AutoLoadTriggers registry keys in HKLM\Software\Microsoft\SoftGrid\4.5\Configuration.

(more functionalities will be added soon :))

4. Internals

Some nice other things to know about the new client:

• By default, the MAV 4.5 client no longer supports streaming data from a local file, a trick mentioned before here. Attempting to do so will result in an error message
  
  "The operation failed because you do not have sufficient permissions to stream from a file. Please report the following error code to your System Administrator.
  
  Error code: 450260-14901604-0000180B",
  
  as shown below:
  
  
  In order to re-enable streaming from files, it is necessary to change the AllowIndependentFileStreaming registry value from 0 to 1 at HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration.
  
  By the way, now you can also stream from local OSD files that contain spaces in their full path location, this used to give errors on earlier clients.