ESX 3.5 on a whitebox

It has been very quiet from my end for the past weeks because I was very busy at a client & at the same time spending all my free time working on my ESX-on-whitebox hardware project. After being inspired by some colleagues, I decided to order the following hardware:

• Asus P5BP-E/4L motherboard
  This motherboard supports an Intel S775 processor, has VGA and audio onboard and most importantly, the LAN controllers on this motherboard are ESX certified (Broadcom 57xx chipset).
  
  
• Intel Q6600 Quad Core processor (2.4 GHz) and 8 GB ECC RAM (4x 2GB)
  Just to be sure I have enough CPU power and memory resource pools :)
  
  
• Dell Perc 5i Integrated SAS Controller
  My colleagues advised me that storage was the biggest bottleneck in their ESX whiteboxes (based around the very nice Asus P5M2/SAS board). I decided to go for a dedicated hardware controller. I picked up the Dell Perc 5i controller, which is more or less a rebranded LSI Logic 8408 SAS controller on EBay with 256MB of RAM and a battery backup unit for about 175 EUR.
  
  The main advantage of SAS controllers is that they also support the (cheaper) SATA consumer drives. A quick test confirmed this; I had absolutely no problems at all with this controller & even flashed the latest LSI Logic firmware to it :).
  
  Maybe of interest for some: the later Dell firmwares and also the later LSI logic firmwares for this controller provide support for Write Back without a BBU present.
  
  
• SATA to SAS cables
  The Dell Perc 5i has SFF-8484 SAS connectors on board, so I purchased two Adaptec SFF-8484 to 4xSATA cables from a nearby store to attach all the drives.
  
  
• 8 Seagate SATA harddisks (4x 1TB and 4x 200GB)
  Space... loads of space.

The hardest thing was getting all these disks in my Silentmaxx ST11 casing; it required some case modding and loads of patience to get everything well fitted. The 500W PSU that is necessary to provide enough juice, was recycled from an Antec Sonata case. I also added a small 3Com 3C905 100Mbps card for my ISP modem connection.

The installation of ESX 3.5 was a piece of a cake & and I can confirm that the above hardware works like a charm. For those interested, I also noticed that ESX 3.5 supports the ICH7 SATA controllers (found on many consumer motherboards as well). I think -- but this has to be confirmed by someone else -- that you need to configure your ICH7 disks in a RAID before the ESX kernel will accept them as a storage pool.

MAV 4.5: How to perform a Dynamic Suite Composition

The blog of Justin Zarb details a step-by-step guide of how the Dynamic Suite Composition (DSC) in Microsoft Application Virtualization 4.5 functions. He describes how to include a Snag-It bubble into an existing Office 2007 bubble. There are not many technical details about how DSC works, but some interesting facts are mentioned there:

• Appearantly, it is possible to compose multiple bubbles but only one level deep. If you attempt to include an OSD file that in itself has another DSC, this third bubble is not included.
  
  
• Sequencing tip: make sure your sequencer workstation has all the software installed that you want your second bubble to hook onto. For example: if you are sequencing an application that integrated with Office 2007, do a fat installation of Office 2007 first, and only then start the monitoring and sequencing of the add-ins.
  
  Personal note: also for applications that depend on Java or Oracle clients, you obviously first need to prepare your sequencer workstation by installing those core components.
  
  
• The user changes that are made in the dynamically composed bubbles are all redirected to the primary bubble's UsrVo_sftfs.pkg files.

I am already planning for a few weeks to delve deeper into the DSC of MAV 4.5 beta and to check in more details what Justin describes, but a project at a customer currently prioritizes my spare time into non-MAV related things. Be sure to check regularly here again for more information on DSC.

Microsoft SoftGrid 4.1 SP1 and 4.2 Hotfixes

The Microsoft SoftGrid blog contains the announcement for the first Hotfix Rollup Packages for SoftGrid 4.1 SP1 and SoftGrid 4.2. The main new feature for these two packages is support for the MSI Utility that was released at Christmas.

Further improvements include:

• Better ActiveUpgrade and better downgrade of a package version.
  
• Improvements to nonpaged pool usage when sequencing large applications.
• Improvements when you sequence applications that use both the Microsoft .NET Framework 1.1 and the .NET Framework 2.0.
• Improvements to command-line parameter handling of virtualized child processes.

The new versions are downloadable from the Microsoft Support site:

• MSKB 938497 for SoftGrid 4.1 SP1
• MSKB 941408 for SoftGrid 4.2

Enjoy!

MSI Utility 1.0.0.16 released

The long awaited replacement for the SMS Connector has been released a few days by Microsoft. The MSI Utility 1.0.0.16 can be used to convert a SoftGrid package into a MSI file that can be deployed using third party electronic software distribution systems. When executed, the MSI wrapper will import the virtualized application on a 4.1 SP1/4.2 SoftGrid client, thus allowing to run virtualized applications in situations where no "MCVAS" server is available. The MSI utility is no longer needed for the 4.5 beta release since the 4.5 sequencer allows direct saving of MSI files (compatible with those produced by the MSI utility).

Mixed-mode scenarios, such as using MSI delivery for initial deployment and streaming delivery for updates, is not supported.


The MSI Utility is freely downloadable from the Microsoft site. In order to use the MSI Utility, you need to upgrade your SoftGrid clients to versions 4.1.1.21 or 4.2.1.21 respectively. These versions, which will contain a set of hotfixes, will be released in the near future.

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