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.
  

MAV 4.5 - Things to know

Here are some small issues that I ran into while testing Microsoft Application Virtualization 4.5:

• An important change is that the MCVAS service is now launched under NETWORK SERVICE credentials instead of the LOCAL SYSTEM credentials that were used in the 4.1/4.2 server. This means that the NETWORK SERVICE should have read & list rights on all files and folders of your content directory and on the content directory itself. If this is not the case, the MCVAS server cannot access the package files and this will result in "Launch Failed" errors at your clients.
  
  
• The 4.5 beta sequencer has the same bug as the older 4.2/4.1 sequencers: when creating a new package and defining the server URL, do not select "RTSP" or "RTSPS" (or "FILE") in the package configuration wizard. This will write an URL with capital "RTSP" or "RTSPS" in the OSD file that is created with the package.
  
  The server does not handle application requests from clients that use capital protocols well and will log an error "Unsupported method" and the client will give you a "Launch Failed" error message. Manually changing the URL inside the OSD file to have a lowercase "rtsp" or "rtsps" in it will fix the problem as was already mentioned in a previous post on this blog. (Ironically, all other XML tags should be in uppercase for them to work properly in an OSD file, the protocol should apparently be in lowercase).
  
  
• The 4.5 beta sequencer still has the same bug as older 4.2/4.1 sequencers: when upgrading a package, changes made to the package are not shown in the "Files" tab of the sequencer until either you run the Application wizard again (to determine FB1) or until you save the package --- all changes are included but not just immediately shown.
  
  
• The usage of BITS (Background Intelligent Transfer Service) is not supported or possible with a stand-alone installation of MAV 4.5. Probably the SCCM integration allows to download virtualized applications (MSI files) in the background using BITS, but this remains to be verified & tested.
  

(to be continued with more issues as they come up)

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).

Microsoft Application Virtualization 4.5 beta - Heavyweight Server impressions

In a first series of post regarding the recently released 4.5 beta version of Microsoft Application Virtualization, we're going to have a look at the standard server installation, refered to as the Heavyweight Streaming Server (HWS). The stand-alone mode and "Lightweight streaming server" (LWS) mode will be discussed in an upcoming series of posts.

0. Introduction

The new release of Microsoft Application Virtualization 4.5 introduces a set of deployment models that are available for delivering virtualized applications to clients. This post discusses the HWS model, which is closest to the "traditional" SoftGrid server that we know from the older 4.0/4.1 (SP1) releases of the SoftGrid server. The components for this set-up are as follows:

• MCVAS server (Microsoft System Center Virtual Application Server) which performs the desktop configuration of the clients and performs the streaming.
• SQL server and Active Directory backends for the MCVAS.
• Fileserver for the content location
• Management Web Service which communicates with the SQL backend.
  
• Management Console for performing the MCVAS configuration; the management console connects to the management webservice.
  

1. Installation

The MCVAS setup comes in the form of an MSI installer, as was the case with the previous 4.x server installs.

• After starting the installer, I was informed that I need to install MMC 3.0 before the MCVAS installation could complete. This is quite surprising since I already had installed MMC 3.0 on that particular machine (Windows 2003 Standard Edition SP1). Luckily, this was not a showstopper for the installation which continued after this error message.


• An existing 4.1 SP1 server installation is properly detected and an upgrade path was proposed. This upgrade succeeded flawlessy.


• Prerequisites for installing the MCVAS server are the same as for a 4.1 SP1 installation:
  
  
  • Microsoft Management Console 3.0
    
  • Microsoft .NET Framework 2.0
    
  • Internet Information Services Web Service (presumably IIS 5.0 is sufficient?)
    
    
• It is no longer possible to install the "SoftGrid Client Management Console" from the server installer.


• The default installation path has changed from "C:\Program Files\Softricity\SoftGrid server" to "C:\Program Files\Microsoft SoftGrid\Microsoft System Center Virtual Application Server".


• It is no longer possible to install MSDE --- aka "the SQL overlords will punish you if you still use that one" --- during the MCVAS installation. The availability of a database is now simply a prerequisite for the installation. I used SQL Server 2005 Express Edition SP2 without problems during my tests.


• The default database name is now "SOFTGRID", which is irony at its best. The very release that they finally change the default database name from "SOFTRICITY" to "SOFTGRID", the product gets renamed.


• It is no longer necessary to provide the a SQL built-in account with sufficient privileges during the installation; integrated authentication is used instead (no longer necessary to configure your SQL server to mixed authentication). The user that is installing the MCVAS needs sufficient privileges on this server to create a new database or to modify an already existing database.


• Several new features that are asked during the installation include:
  
  
  
  • The "SoftGrid Secure Communication Mode", which allows to assign a server certificate to the server to immediately allow secure communications (more on this later in this post). The server certificate must be installed before the setup is started.
  
  
  • The port to use for the MCVAS server's communications (RTSP, default: 554)
  
  
  • The port to use for the MCVAS server's secure communications (RTSPS, default port: 322). That is no typo, the default port number for RTSPS has indeed changed from 332 to 322.



• A small "bug", or rather, discomfort, that I ran into is when trying to install the MCVAS on a server that is not joined to a domain. When prompted for the SoftGrid Administrators and SoftGrid Users group, this leads to an error in the installer log file "ADSOpenObject Error 0x80005000, no value for domain name". The default option of "Domain Admins" (for the SoftGrid Administrators) is listed instead, and only when trying to continue, an error message stating that the domain could not be found is listed. We will see later in this report that indeed it is no longer possible to install the MCVAS on a server that is not joined in the domain.
  

2. Management Console

A first thing I noticed (also throughout the installation) is that the term "SoftGrid" is still used in many locations; for example, the management console is still named "SoftGrid Management Console", the opening picture that has "Softricity" in it is still used, and the reports still contain the same old logo's.


Sure, no drama here, but it makes you wonder why 17 months after the purchase of Softricity by Microsoft, no-one took the time to replace the GIF images in "C:\Program Files\Softricity\SoftGrid Management Console\images" ?

At first sight, not many things seem to have changed in the MCVAS management console:

• The good old options "Applications", "Filetype Associations", "Packages", "Application Licenses" and "SoftGrid Administrators" seem to be the same as in the previous versions with no visual differences.


• The "Provider Policies" option has been simplified; in the provider pipeline, the "Basic Authentication" and "Anonymous Authentication" have been dropped, now you can only authenticate using "Windows Authentication".
  
  
  This might have a consequence for those of you that use separate provider pipelines for anonymous authentication or PC's that are not joined in a domain.


• An interesting development in the "Server Group" option is the easier management of certificates in the "Ports" tab of a SoftGrid server.
  
  
  By clicking the "Server Certificate" button, it is possible to select a certificate that is stored in the Computer account's personal certificate store as the base certificate for RTSPS communications. This greatly simplifies the configuration of encrypted streaming (see a previous blog post of mine for the lengthy procedure in pre-4.5 servers).
  


• In the advanced configuration of a SoftGrid server, the "Max. Block Size" option is still present, even though AFAIK, the entire 4.x range of servers simply ignores this option and automatically determines the maximum block size.
  
  
  
• The greatest surprise is without doubt the absence of the "Account Authority" option which allowed to configure a SoftGrid AD browser account in previous versions of the SoftGrid server. In practice, this means that the reference domain for assigning rights to applications is now the domain that the MCVAS server is placed in. This is also a simplication that was to be expected after generic LDAP support was dropped.
  

3. In the background...

Of course the major changes implemented in version 4.5 are not in the graphical interface, but functionalities that are only visible when looking a bit deeper. Here are some nice changes that I discovered when poking around in version 4.5's internals:

• Remember that pesky server.conf file that contained a database user and password in plaintext? That is finally fixed: now the machine account of the MCVAS server is used to read the configuration from the database (the machine account receives SFTeveryone and SFTread roles in the database). In order to make changes to the database, the default security on the database is such that you need to be in the SoftGrid Administrators group (SFTadmin SQL role). This also means that no longer the "sa" account is needed during the installation, and that mixed authentication can be disabled on your SQL database server.


• The registry keys for the SFT content and logging have moved from "HKLM\Software\Softricity\SoftGrid Server" to "HKLM\Software\Microsoft\SoftGrid\4.5\Server". The only new value created there is a "Version" REG_SZ value which contains the complete build number of the 4.5 SoftGrid server, in casu "4.5.0.606".
  
  
• Corrected: The older SoftGrid 4.1 / 4.2 clients seem to (partially?) work with the new 4.5 beta server. I was able to stream a pre-4.5-sequenced application but let it be clear that there is no guarantee whatsoever that a new 4.5-sequenced package will work on an older client. (This should not come as a surprise of course, how would an older client know how to interpret features that were introduced in a newer version of the sequencer/server?)
  
  In fact, as Gene Ferioli pointed out in a comment, Microsoft does not support the connection of older clients to the 4.5 server; the recommended upgrade path is to first upgrade all the clients to 4.5 (since this client knows how to talk to the earlier 4.1/4.2 servers) and only then to upgrade the server to version 4.5.
  
  

4. Roundup

The functional improvements that are visible in this beta version of the HWS MCVAS surely have their benefit:

• the integration with the domain is more tight (no need for browser accounts, direct Windows authentication, no database accounts).


• the configuration of RTSPS is much easier and now directly compatible with a Microsoft Certification Authority.

Besides these small functional improvements, there have not been many changes to the Virtual Application Server. At this moment, after having investigated the main server component, I am a bit afraid that this new version is also mainly about improvements in the virtualization itself (i.e., at the client & sequencer side). I don't see any immediate improvements in management and scalability:

• it is still not possible to have a delegated SoftGrid administrator permissions (as is possible, for example, in SMS and SCCM where you can have separate server and package administrators).


• For centralized client management, it still seems necessary to revert to third-party or self-made administrative templates for GPO's.

The scalability issues should be tackled by introducing different deployment schemes as discussed in the beginning of this post. These different deployment schemes will be discussed in a series of other posts. To be continued!

Microsoft Application Virtualization 4.5

The long awaited version 4.5 of "Microsoft SoftGrid" has been released in beta, and there are some remarkable surprises to be read in the release notes.

• First of all, the name "SoftGrid" is dropped and now we should talk about "Microsoft Application Virtualization".
  
  
• Secondly, the centralized management and integration with SCCM 2007 is now in effect. This was the major improvement in functionality that was expected previously. This is basically manifested in the different installation modes that are possible:
  
  
  • Standalone mode: which allows the execution of virtual applications without the streaming but using SCCM or another electronic software distribution (ESD) tool to get the SoftGrid package at the client.
    
    
  • "SoftGrid compatibility" mode: the infrastructure as we know it from version 4.0 - 4.2 where a central application server performs the desktop configuration, performs application tracking/licensing/access management and streaming.
    
    
  • Streaming Server mode: which is a trimmed down version of the previous mode where only streaming is performed at such a server. I suppose that this is the component that will be placed on SCCM distribution points once SCCM2007 R2 (which would feature Microsoft Application Virtualization integration) is released to allow for distribution points to perform the streaming.
  
  
• Finally, the big new feature is that we now can merge bubbles on the fly! The "Dynamic Suite Composition" feature allows to create separate packages for middleware such as Java Runtime Engines or Oracle clients.

The beta can be downloaded at the Microsoft Connect website. More details on this new release can be read at the SCCM site or at the SoftGrid team blog --- I wonder what we should call that blog from now on ;).

I am yet to test this new release but you can expect some detailed feature reports very soon.

Virtualized Domain Controller's time synchronization issues

At home, I use the excellent VMWare Server to run my own little network with domain controller and SoftGrid server, like most of us do. Due to circumstances, I regularly reinstall the entire network, and a single problem keeps on recurring: the times on all my computers go nuts after about a week of running properly synchronized. Quite annoying if some of your client PC's have a TV-card with a thight recording schedule ;).

The problem is the bleeding obvious: the time on the domain controller (which holds the PDC role as it is the only domain controller in my miniature network) is not correctly synchronized anymore after a while. I noticed that it starts with small deviations at first, but very soon, this accumulates to very large deviations. The skew between the "real time" and the DC's time seems to increase in a nonlinear fashion. Also, the DC uses bridged networking so external timesources such as "time.windows.com" are reachable at all times.

I still have to figure out if this is due to the fact that this is a virtualized domain controller on VMWare Server; I cannot remember seeing this problem elsewhere (not on a VMWare ESX or on physical installations of a domain controller). Anyway, here is the solution to the problem, you might find it useful at a given point in time:

• First of all, inside the virtual machine, ensure that the option "Time synchronization between the virtual machine and the host operating system" is disabled. In my setup, this could potentially lead to a loopback since the host OS is in fact a member of the domain of which it is hosting the domain controller (and PDC emulator) in a virtual machine.
  
  
  


• Secondly, I had not configured the domain controller to use an external time source. The procedure is detailed at Microsoft's Knowledgebase article 816042, but in essence, it comes down to setting the following registry values under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\:
  
  
  
  • Parameters\Type = "NTP"
  
  
  • Parameters\NtpServer = "time.windows.com,0x1"
  
  
  • Config\AnnounceFlags = "5"
  
  
  • TimeProviders\NtpServer\Enabled = "1"
  
  
  • TimeProviders\NtpClient\SpecialPollInterval = "60"
  
  


• Finally, you need to restart the W32Time service at the domain controller using net stop W32Time followed by net start W32Time.
  

On your clients, use w32tm /resync to reset the time according to your domain controller (you can also use this command at the domain controller to immediatelly poll the NTP server you specified).

What happens to Feature Block 1 when you upgrade a package?

Recently, I had a discussion with a colleague around what happens to Feature Block 1 when you perform a package upgrade: does it get completely restreamed, when is the FB1 data erased when opening a package for upgrade, ... ? I decided to perform a set of small tests in order to figure out what happens exactly.

Here are the results: I used the SoftGrid Sequencer 4.2 build 303 for creating the packages, SFTExplorer 1.0 for finding out what the FB1/FB2 contents looks like and NetLimiter 2.0.10 Freeware to monitor network traffic.

When is the FB1/FB2 separation erased when opening a package for upgrade?

A first test consisted of finding out when the FB1/FB2 separation is erased when using the "installation wizard" for making modifications to the package:

• When adding a new file to the package using the "installation wizard", and not running the "application wizard" (FB1 determination), results in a loss of a previous FB1/FB2 division. The entire package becomes FB1 data.
  
  
• When adding a new file to the package using the "installation wizard", and then running the "application wizard" for FB1 determination, results in FB1 containing those (parts of the) files that are accessed during the FB1 monitoring. This is precisely the expected behaviour.

When opening the package for upgrade and immediately saving the package without making any modifications, retains the FB1/FB2 separation. As mentioned above, when you click the "Begin Monitoring" button in the "installation wizard", the FB1/FB2 separation vanishes, even when not changing anything in the package. This means that the "Begin Monitoring" click is (roughly speaking) the point where the previous FB1 is lost.

A second test consists of what happens when you use the "Encode Directory" option to modify the contents of the package instead of the "installation wizard". Something interesting here:

• When you use the "encode directory" wizard, the FB1/FB2 separation is lost, which coincides with the behaviour of using the "installation wizard". Strangely enough, now the entire package becomes FB2 (!!) with only SoftGrid's osguard.cp file being in FB1.
  
  
• When using the "encode directory" wizard, followed by the "application wizard", creates the usual FB1/FB2 separation that one would expect.
  

Here, the start of the "encode directory" wizard triggers the erase of the previous FB1/FB2 separation.

What is streamed to a client after a package was upgraded on the SoftGrid server?

This is very simple: the entire package needs to be restreamed to the client when the package is upgraded on the server. I performed the following three tests on a SoftGrid package that contained 3 files of 5 MB each:

• The first time the package was created, I added one file of 5 MB to FB1 (by reading it into WordPad during the monitoring phase). After publishing this application on the SoftGrid server, the SoftGrid client pulls in 5 MB as expected ; this was monitored using NetLimiter and verified in the SoftGrid client management console.
  
  
• Then I opened the package for upgrade, ran the "Application Wizard" and now touched the original 5 MB file that was already in FB1 and also a second 5 MB file. The sequencer correctly reports that the FB1 size then becomes 10 MB, as expected.
  
  The client's total transfer size after placing this new package on the server (using "Add Version") came down to 10 MB, the entire FB1. Notice that the launch bar kept on saying "100%" at the client side, even though a restreaming was in fact being performed.
  
  
• The third test consisted of opening the package with a 10 MB FB1 size and changing a single byte within one of the files that was in FB1. Again, it turned out that the entire FB1 was transferred to the client when I upgraded the package on the server.

I have heard several people say that SoftGrid will only stream the difference between an original package and the ActiveUpgrade that is performed on it; from these simple tests it turns out that this is not the case: upon every package upgrade, all previously cached data is invalidated at the client.

In a sense, this is not really surprising: at every save of a package, it is restructured and optimized for streaming according to the FB1/FB2 separation that was specified during the application wizard. This new SFT structure could in principle be completely different from the old SFT, making it nearly impossible or inpredictable on a 32 KB-block level to say which blocks need retransfering. I don't really see a practical way of implementing this when using a streaming protocol that only knows about block numbers and not about the contents of the package.

SoftGrid applications without a SoftGrid server

A convenient trick to launch a SoftGrid application locally, without contacting a SoftGrid server, is to direct the SoftGrid client directly towards the SFT file. This can be done by editing the OSD file and replacing

HREF="rtsp://%SFT_SOFTGRIDSERVER%:554/content/appname/app.sft"

with

HREF="file://D:/SoftGrid/appname/app.sft"

(replace by the correct path) and then double clicking on the OSD file. This triggers SFTTray.exe to launch the specified application.

Some caveats and things to know:

• The path that you specify may not contain any spaces or you will get a "Launch failed" error message.
• The "file" prefix in the URI is case-sensitive (but this is also the case for the more traditional rtsp & rtsps prefixes).
• You need the "Add Applications" privilege in order for this to work: double-clicking the OSD file of an application that is not known on the system will first add the application and then start loading FB1 into the cache. Only afterwards, the application is started.

This means that by the default configuration of the SoftGrid client, you need to be a local administrator before you can use this trick.