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

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.

Package information leakage through the Q drive

We all know that if you are a local administrator on a machine that has a SoftGrid client, then you can see all the applications that have data in the local sftfs.fsd cache file by opening the SoftGrid Client Management Console and finding all the applications that don't have a "Idle (0%)" package status. This is because local administrators can see all applications that are defined on a machine in the Client Management Console, whether or not they actually have the proper group memberships or SoftGrid access to be able to start the application.

A colleague (thanks Anthony) pointed me out to another interesting way of finding out what applications have cached data on a SoftGrid client, but that doesn't require administrative privileges. Simply go to the root of the Q drive inside a bubble and look at what asset directories you can see!

It turns out that a user can see all the asset directories of all applications that have some data cached at the client, even if the user doesn't have access to the applications themselves (note: of course you cannot see the contents of these directories since this is prohibited by the isolation; you can only see their existence).

As an illustration, notice on the figure below how the user only has access to Office 2000 and still can see the asset directories of Office 2003 and Office 97 on the Q drive.


You can do this test yourself as an end-user by modifying a locally cached OSD file (hey, they are in the All Users profile with write access for all!) and using the following script tag:

<SCRIPT TIMING="PRE" EVENT="LAUNCH" PROTECT="TRUE" WAIT="TRUE">
  <SCRIPTBODY>
    @echo off \n
    dir q: \n
    pause \n
  </SCRIPTBODY>
</SCRIPT>

Then (as a local administrator), perform an unload of one of the applications that you don't have access to as a regular user and witness how the next time you use the script above under the user's account, the asset directory has vanished!


Note on motivation:

So you might be thinking... big deal, so what? Who cares about that asset directory being visible or not?

It was important for one of our customers, because they wanted to prevent users from seeing what applications were installed on a machine (locally installed and virtualized). One reason for that was security: knowledge of applications installed might open ways to use certain exploits. Another reason was cost: they had a very peculiar licensing system for a set of applications that required them to cough up the license fee from the moment an end-user could see that the application was installed. I suppose they didn't want to enter a legal dispute whether the visibility off the asset directory would mean they have to start paying license fees ;).

Automatic starting of SoftGrid applications

It is possible to publish applications to the "Startup" menu, i.e. by placing an icon in %CSIDL_PROGRAMS%\Startup location. However, it might not be a good idea.

The problem occurs when you have use the desktop configuration to perform refresh cycles of the shortcuts of the icons, and in this case, the problem is two-fold. First of all, the icon is added to the start menu only after the user has logged in (at least when you configured the SoftGrid client to perform a refresh upon login). This means that the first time the application is published in the Startup menu, the application will not execute since the logon moment has passed and Windows already processed all the Startup menu entries. On the other hand, from that moment onwards, the SoftGrid shortcut will remain in the Startup menu, it points to the locally cached OSD file and the next logoff/logon of the user will start the virtualized application from the Startup menu as expected.

The second problem occurs when retracting the user's rights to this application. The icon will be removed the next time the user logs on again (... if you enabled refresh upon logon, that is; the reasoning remains valid if you use periodic refreshes and the user logs off before that period refresh removed the icon). However, before the SoftGrid client removes the icon, Windows will already have processed the Startup menu and attempted to start the virtualized application, which will result in an error message because the user no longer has the proper rights.

If you manually publish your shortcut in the Start Menu's Startup folder (not relying on the desktop configuration of the SoftGrid client), you are not vulnerable to this error. You will notice that the SoftGrid application will be started upon the user login, as expected.

Terminate Children (yes/no/abort) ?

When you specify the TERMINATECHILDREN="TRUE" value in the VIRTUALENV element, then all processes that are running in the bubble are killed when the main application closes. The name of the element might let you think that only child processes of the executable that you specify as FILENAME in the CODEBASE element are removed, but this appears not to be correct. This also means that any script that you still have running in the background can be killed, or a command prompt that you opened up for troubleshooting.

In my opinion you should be careful using TERMINATECHILDREN, since the child executables and other processes can also perform I/O operations that might get interrupted. If you want to alert the user of the killing of background processes and make them aware of this danger, you might want to check out the LaunchIT utility from Tim Mangan. This utility monitors all child processes that are launched by the main process and optionally alerts the user when child processes remain once the main process has closed.

For more information, see the OSD illustrated which also explains this, or Microsoft KB 931589.

Hiding the Q drive on SoftGrid clients

So finally you have gone through the work of getting a SoftGrid server up and running, configuring your clients, sequencing your packages, ... to get a zero footprint of applications on your workstations. And right at that moment it turns out that the SoftGrid client leaves a very visible trace on the client computer: the Q drive is plainly visible there. And what is even worse, inside your bubbles, the end user has full write access on that Q drive (or at least, within the application's asset directory). Are you really ready to become your helpdesk team's new nightmare when all the calls come in, whining about documents saved to Q gone missing? ;)

I think not. So we simply hide the Q drive from the end-users who want to store their documents everywhere but their home drive!

• First, we must hide the Q drive from the user's desktop. Thanks to the isolation, users cannot access the Q drive (unless they are in a bubble), so hiding the Q drive from the desktop is purely for aesthetic reasons. Edit your domain policy and set the Hide these specified drives in My Computer group policy to hide the Q drive. Since the default options do not include a "Q drive" option, you will need to edit your system.adm file to include such an option; all the details are in Microsoft Knowledgebase article 231289, but basically you should modify the system.adm file as follows:
  

  
  POLICY !!NoDrives
    EXPLAIN !!NoDrives_Help
       PART !!NoDrivesDropdown          DROPDOWNLIST NOSORT REQUIRED
          VALUENAME "NoDrives"
           ITEMLIST
                 NAME !!QOnly           VALUE NUMERIC 10000
                  ;low 26 bits on (1 bit per drive)
                 NAME !!RestNoDrives     VALUE NUMERIC 0 (Default)
           END ITEMLIST
      END PART              
    END POLICY
  
  [strings]
  QOnly="Restrict Q drive only"
  RestNoDrives="Do not restrict drives"
  

  Of course, you can create a separate SoftGrid.adm file that includes this registry change...
  
  You can also use a registry file along the lines of
  

  
  Windows Registry Editor Version 5.00
  
  [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
  "NoDrives"=dword:00010000
  "NoViewOnDrive"=dword:00010000
  

  in the login script to prevent the user from seeing the Q drive.
  
  Note: The value 0x00010000 displayed above is the value that hides ONLY the Q drive. If you want to hide another drive, or multiple drives, you need to recalculate the value there as described in the knowledgebase article!
  
  
  
• We also want to hide the Q drive inside the bubble to avoid that a clever user overrides the OS registry values that we just defined, or that a sequencer accidently overwrites these values due to bad packaging. So, we must also include the above registry setting in the virtual registry! Microsoft knowledgebase article 931626 discusses three ways of doing this, but without doubt the cleanest way is to modify your OSD file and add a REGISTRY entry in the between the VIRTUALENV tags:
  

  
  <VIRTUALENV>
   <REGISTRY>
     <REGKEY HIVE="HKCU" KEY="Software\Microsoft\Windows\CurrentVersion\Policies\Explorer">
       <REGVALUE REGTYPE="REG_DWORD" NAME="NoDrives">10000</REGVALUE>
       <REGVALUE REGTYPE="REG_DWORD" NAME="NoViewOnDrive">10000</REGVALUE>
     </REGKEY>
   </REGISTRY>
  </VIRTUALENV>
  

  
  This does not pollute the user's virtual registry.
  
  Note: The virtual registry overwrites values from the underlying OS. If your group policy hides other drives than Q, they will reappear if you blindly use the "0x00010000" value shown above as an example!
  

Of course, this does not prevent the innovative user of accessing the Q drive from within bubbles (after all, it's only hidden). But if they really insist on saving their data on the Q drive, at least now you have a valid reason for applying all your voodoo on them :).

SoftGrid error 0060922C-800736B1

This is a good one to know. If you get the following error message...

The SoftGrid Client could not launch (APPNAME)
This application has failed to start because the 
application configuration is incorrect. 
Reinstalling the application may fix this problem.

Error code: XXXXXX-0060922C-800736B1

then you might want to consider installing the Visual Studio Runtime Executables. It solved a problem for me where a package streamed ok, but the application itself simply refused to launch (Adobe Reader 8).

More information available at the Microsoft Knowledge Base in article 939084.

Sequencing... WinZIP

There is no real problem in sequencing WinZIP: just follow the standard procedures, and you got yourself another SoftGrid package! Except for one annoying message that keeps on popping up: "WinZIP is currently not associated to...". In the sequencer, this error does not appear.




What goes wrong here is the good ol' File-Type-Association that is handled by SoftGrid and no longer by WinZIP itself. In fact, there is nothing you can do to prevent this message, except for making sure it does not appear anymore. This can be done by adding a virtual registry key AssocMsg at:

HKCU \ Software \ Nico Mak Computing \ WinZip \ WinZip  

as a REG_SZ and setting its value to "0". This simply does not show that particular dialog window anymore to the user. This does not impact the functionality of WinZIP, since the filetype associations are handled by the SoftGrid client.

Configuring RTSPS (RTSP over TLS) in SoftGrid

One of the convenient features of SoftGrid is that all the streaming and management traffic can be encapsulated in a TLS tunnel. This is very useful if you want to make SoftGrid available through a webinterface or to internet users. Some documentation is available (MSKB930870) on how you should configure the RTSPS protocol on the SoftGrid server, but very little is said on how you should obtain a server certificate that SoftGrid can understand.

It turns out that SoftGrid requires a cert.pem and key.pem file, and cannot read Microsoft's PKCS#12 certificate stores (where multiple certificates and keys are stored in a single file). So how can you obtain a separate certificate and private key file if you only have a Microsoft Certification Authority in your enterprise? Here's how...

I. Preparing to request the certificate

First of all, you need to create a new certificate template that allows the exporting of private keys from a Microsoft certificate store. If you don't do this, you cannot separate the private key and the actual certificate that are stored in the single PKCS#12 file. An additional complication is that your certification authority need to be running Windows 2003 Enterprise Edition in order to allow for custom templates! If that is all set, do the following steps:

1. Open a MMC and open the Certificate Templates snap-in.


2. Rightclick the Webserver template and choose to duplicate it.


3. Change the following settings:
   
   
   
   • Template Display Name: Webserver (25 years and exportable)
   
   
   • Validity period: 25 years
   
   
   
   Also make sure that on the Request Handling tab, the Allow private key to be exported checkmark is checked!


4. Save the template & exit this MMC.


5. Next, open the Certification Authory MMC on your CA server, and go to the Certificate Templates branch in the navigation tree on the left. Rightclick and select New template to issue.


6. Select the template you just created. Afterwards, restart the CA service.

Done! You have just created a new certificate template that allows the private keys of the (entire) certificate to be exported.

II. Requesting the certificate

On your SGVAS server (... you need to do this on every SoftGrid server!), navigate to the CA's certificate webpage, which is typically available at http://ca_hostname/certsrv.

1. There, select to request a new certificate, select advanced certificate request. Then, select the option to Create and submit a request to this CA..


2. Enter the following information:
   
   
   
   • Certificate Template: “Webserver (25 years and exportable)
   
   
   • Name: use the FQDN of your SGVAS server.
   
   
   • Ensure the Mark keys as exportable checkmark is checked.
   
   
   • Enable Store certificate in the local computer certificate store.
   
   
   • Attributes: can be used to specify additional hostnames for a particular server.
   
   
   • Friendly name: specify a human readable name here for the certificate, e.g. SoftGrid SGVAS Certificate.
   
   


3. Click the Submit button when done, and install the certificate afterwards.

That concludes the requesting and installation of the certificate.

III. Preparing to convert the certificate

Before we can convert the certificate into a form that SoftGrid can understand, we must first extract it from the local certificate store again. This is done using by following these steps:

1. Open a MMC, and select the Certificates snap-in for Local Computer.


2. Find the certificate you requested under Personal / Certificates.


3. Rightclick the certificate, select All tasks and choose to export the certificate.


4. In the next screens, ensure that:
   
   
   
   • The Yes, export private key option is selected.
     
   • The export format is set to PKCS #12.
     


5. Enter a private key password and be sure to remember it!!


6. Select the filename to save the certificate and private key to, e.g. sgvas.pfx.
   

Now we're ready to convert the certificate once we have installed the OpenSSL tools which allow the manipulation of X.509 certificates (the Microsoft tools suck). Go to the OpenSSL site and find the page that gives a link to binary distributions. You will be pointed towards the Shining Light Productions Win32 port of OpenSSL. Download and install the light package, the current version is v0.9.8.e.

IV. Converting the certificate for SoftGrid

Follow this procedure to convert the PKCS#12 certificate to a separate private key and security certificate file:

1. Open a command prompt and go to the installation directory of OpenSSL (default is C:\OpenSSL).


2. Enter the following command (change the location of the input file sgvas.pfx and output file sgvas.pem as desired):
   

   
   openssl pkcs12 -in sgvas.pfx -out sgvas.pem -nodes
   

   
   You will be prompted for the import password, which is the private key password that you choose when exporting the certificate in the Microsoft management console.


3. Open the sgvas.pem file using a text editor like WordPad. Find the part that is enclosed by the BEGIN RSA PRIVATE KEY tags, and copy it entirely (including the begin/end declarations) to a separate file that you call key.pem. The resulting key.pem file should look like:
   

   
   -----BEGIN RSA PRIVATE KEY-----
   MIICXAIBAAKBgQC4rRo0XjlmXOAoC+0GawMzqxRpB/i8PsbljR6pKfF1RGxzzN9y
   l/dQN8DYlE9FRLTFruZnKfzMdInYr+nRcGczrRMkkfJiGOpF6DvBkHqwu+j/Rf5g
   hEwdZNJzT48aC0F8H5zZ4hY1E006zQuoS2LTh8A70RsufHd7T0paX2p04QIDAQAB
   AoGBAIX+WxgKEb26v4sdfhsdfjsdkfjhsdjkfhsdjkfhsdjkfhsdjf5HgtL6UPsT
   yNxqeHtCZrwNk/XIzMejA5TJ6KYyaW8YANngLKa8oNDmoQZ65HDok4fenBDMRPUT
   vOfdzYWKBf1Vt9aFVshsoe0htvyGPuashok1K6w4NIKHpkfRAkEA69VzRGS7OuKg
   S4gz3M8ENgS5S0blablablalbalbalbalbalblalbalblablazKubfjP4y7nRioq
   D4s+UUyMFQJBAMh3x6i4mSOFDh5t5Bz0WmqwNW9mNpmgInd/n5Gmdp8pBBRcgTdc
   R84blluqXaq2sWHhaLwMG6YbFz7p24fdXJ0CQEMCzdP7Q3BCAQY1V3dAo5Ot1/Da
   WetlkC9chM37YoKgpKyzA5xAMS71eiCffA1X21SIRJnrM/At/vGXwUdcltkCQDjS
   OrWIHWAEBsx5OX87gsdf789sd7f89sd7f98sd7fsdh3hun6GmZPCHgw9be9FeWHV
   Emq6w9uBMkWS47bO98ECQB+23/UKHZEgxFvamFz4uz2QaxOqLfFqJ7v9Gs8b7fsI
   vsn1FFD36zzTPTzGwqNSVHZNms99ctBdYgZWtMiwJcg=
   -----END RSA PRIVATE KEY-----
   



4. Back in the sgvas.pem file, find the part that is enclosed by the BEGIN CERTIFICATE declarations and copy it entirely (including the being/end declarations) to a separate text file that you call cert.pem. An example of how this file should look like:
   

   
   -----BEGIN CERTIFICATE-----
   MIIGCzCCA/OgAwIBAgIKF55bUgAAAAAABzANBgkqhkiG9w0BAQUFADA9MRUwEwYK
   CZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgdwcmV0bmV0MQswCQYD
   .. .. ..
   d+RlSH6zX6R20XG6sgv4icLxHVhXF3zF3CUnMfkGIQ8rfHYcOmD+mXju/uLXbFYJ
   lid5NBZ7JoNgHoTY/sa9T1ckaoo1MTLL5Kc6X9NUx3fa/tiVPqzjbQPu/Zj/2El3
   4uw1pPuC+x5rT1vsnil4
   -----END CERTIFICATE-----
   

This gives you a cert.pem and key.pem file that you can use in SoftGrid.

V. Configuring SoftGrid

From this point on, you can follow the procedure described in Microsoft Knowledgebase article 930870. We briefly summarize that here:

1. Copy both the cert.pem and key.pem files to the following directory:
   

   C:\Program Files\Softricity\SoftGrid Server\conf

   
   Ensure that the files are deleted from all other locations to prevent compromising your security (the private key is not supposed to leak out!!)


2. Open the SoftGrid Management console, go to Server Groups and rightclick the SoftGrid server that the certificate was generated for. Add a new protocol (RTSPS) and fill out the certificate and security key values as follows:
   
   
   where you use the password that you entered when exporting the key in the Microsoft Management console.
   


3. Modify all your OSD files to use RTSPS and port 332 instead of RTSP at port 554, i.e. replace all occurences of
   

   rtsp://%SFT_SOFTGRIDSERVER:554/...

   
   with
   

   rtsps://%SFT_SOFTGRIDSERVER:332/...

   
   
4. Restart the SoftGrid server to enable RTSPS streaming at the server side.

That finishes the server-side configuration of enabling the RTSPS. Now do not forget to reconfigure your clients to use a Secure SoftGrid Virtual Application Server to let them use RTSPS.


Note: A bug in the SoftGrid client 4.1.0.56 breaks the TLS functionality in the client. You are thus forced to upgrade to 4.1 SP1 / 4.2 or roll back to the 3.x client if you want to use a TLS tunnel!

SoftGrid & Office 2007

After a long while, I finally decided to attempt to sequence Office 2007. I had tried a couple of times in the past, but I always failed because of stupid things like...

• using an older version of the sequencer; you need to use at least 4.1 SP1 since Office 2007 uses WinSxS.


• not having enough memory in my virtual machine, which led to an out-of-memory error when downloading the virtual environment after the monitoring; solved it by using 768MB of RAM.

Yesterday, I finally got around to sequencing it under the right circumstances with version 4.1 SP1 of the sequencer and enough memory.

The sequencing went alright, but now the importing of the Office suite failed on me! The error message was a mysterious:

"Unable to create new application. Please report the following error code to your system administrator: 0000B003"

Some googling turns up Microsoft Knowledgebase article 929944, which informs us that the "friendly name" of a shell command associated to a file type must be unique. Consider the following example:

<SOFTPKG>
  <MGMT_FILEASSOCIATIONS>
    <PROGIDLIST>
      <PROGID>
        <SHELLCOMMANDLIST>          
           <SHELLCOMMAND NAME="open" FRIENDLYNAME="&Open DefaultApp"/>
           <SHELLCOMMAND NAME="edit" FRIENDLYNAME="&Open DefaultApp"/>
        </SHELLCOMMANDLIST>
      </PROGID>
    </PROGIDLIST>
  </MGMT_FILEASSOCIATIONS>
</SOFTPKG>

This will produce the same error since the friendly names are not unique...

So I went looking for errors in the OSD files that were generated, and sure enough, there were some duplicate "Print" friendly names in the Word 2007 OSD file. I solved the problem but still the application refused to import (note: you need to stop an existing import and start all over again after changing the OSD file before the changes are detected).

The problem got solved after I deleted the entire PROGID entry for "Word.Backup.8", which seems like a file type that I hope never to need using anyway...

Synchronizing Google Calendar with Outlook 2003/2007

The recent discovery of Google Calendar has made the planning of my personal agenda a lot easier... now my wife can do that for me ;). However, what lacks is the synchronization with Outlook, which in turns allows to see your appointments on the PDA.

A very nice tool that tackles the problem is Remote Calendars, which is a COM plugin for Outlook to connect to iCalendars all over the internet, and perform a periodical synchronization between both. The tool is straightforward to install and use, and has all the features I was looking for:

• One-way synchronization from Google Calendar to Outlook; two-way is also possible but I didn't want that ;).


• Automatic categorizing of imported calendar events; optionally mark these events private.


• All settings like "all day event" or "recurring" are copied from the Google Calendar.

In short: the tool does exactly what it needs to do. The only disadvantage in my opinion is that you see a small "iCalendar update" window appear every now and then, which seems to freeze for a moment when no internet connection is available. Besides that, great tool, check it out!

SoftGrid MSI Utility

News regarding the automatic distribution of SoftGrid packages: Microsoft is working on a MSI utility that will take a SoftGrid package as input and deliver a MSI package as output, ready for distribution using ESD's such as SMS and SCCM. More information is available at the the SoftGrid team blog.

The article hints at how this will be done in practice: the SoftGrid package is loaded into the cache and published on the desktop. This probably means that the utility will roughly do this:

• Use the sfttray utility to load the unpacked SFT file into the cache.


• Publish the application using sftmime.


• Write uninstall information in the registry.

which is pretty much what the SMS Connector VBScripts do at the moment. Appearantly the MSI utility is going to replace the (crappy) SMS connector, which sounds like a good step forward. Also, the availability of SoftGrid applications in MSI form allows a better integration with existing ESD's, making application virtualization available without the immediate need for a full blown SoftGrid infrastructure.

Contacting SoftGrid servers in untrusted domains

In large environments, it is not uncommon to have different setups for a development/test/production environment which typically consist of three domains without trusts. Suppose that you are working on a production workstation and want to launch an application from the SoftGrid server in the test environment, what would you do?

The problem is that the desktop configuration service captures the security token upon the user login, and uses these NTLM credentials to authenticate against the desktop configuration server that was specified in the SoftGrid Client. When there is no trust between the production and test environment, this means that you are presenting unknown credentials to the SoftGrid server in test, and thus you cannot perform a desktop configuration refresh...

One option is to just live with this and start applications from the OSD file. When the SoftGrid client sees that it does not have the proper credentials to start an application, it will query the user for valid credentials...


This can be used to launch applications from a different domain that the SoftGrid server is placed in (or rather: the browser account of that SoftGrid server).

Recently, I read about another option on Justin Zarb's blog, which uses the Windows XP network password features for computers that are not joined to a domain: by opening the XP Users And Accounts control panel, then clicking the user account & then the option "Manage My Network Passwords", it is possible to supply the credentials that should be used to contact a certain server (given its FQDN). when supplying the FQDN of the SoftGrid server that you want to use, you can force the SoftGrid client to use the credentials specified there. Read a full howto on Justin's page.

SoftGrid scripting: hiding the DOS box

So you have created your wonderful SoftGrid script that performs the most advanced features known to man, but there is always that annoying DOS box that keeps on popping up when you use SCRIPTBODY or even when you use a HREF tag to launch the script? (Yeah that's right, also with HREF you can get DOS boxes...).

Here is a workaround to launch an external script to hide the DOS box. The idea is very simple: you use a Visual Basic script that runs the batch file in the background, thus effectively hiding all output!

The VBScript code is a single line and as follows:

CreateObject("Wscript.Shell").Run WScript.Arguments(0), 0, False

Save this file as HideDOS.vbs on your content share, for example in the Tools folder or something. Then call your external script called G:\Doit.bat using the following syntax:

<SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE">
<HREF>wscript \\server\content\Tools\HideDOS.vbs G:\Doit.bat</HREF>
</SCRIPT>

There you go, gone is the DOS box!

Some SoftGrid gotcha's

In a SoftGrid coaching project with a customer, I discovered some small things that you should know and are not really mentioned clearly in the documentation... Here it goes:

• During the FB1 determination phase, when you can launch the applications that have been defined for that package, the changes to files and registries are included in the package. In other words: the monitoring is restarted during the construction of feature block one!


• In version 4.1 SP1 and 4.2, a modification that was made to a local OSD file are not reset by just performing a refresh of the applications. Only when the OSD file is modified on the server, it is copied again to the client.
  
  That is not really a disaster, but what is worse is that when you delete the OSD file from the cache (from the All Users profile), then 4.1 SP1 and 4.2 no longer are able to create the application!! The error message from the sftlog.txt indicates that the SoftGrid client can no longer find the OSD file (presumably because it wants to compare the local file with the server OSD file to detect changes on the server side). The same goes for ICO files by the way!
  
  This is different from the behavior in 4.1, the OSD file was always copied there. The end-result is that while troubleshooting with SoftGrid 4.1 SP1 and higher, you first need to create a copy of the local OSD file and work from there.
  


• There is no visual indication of whether the SoftGrid client has entered MDO (Minimal Disconnected Operation) mode, which typically occurs when the SoftGrid server is not available but where the application should be allowed to continue to run. However, it is possible to generate a log file that informs you when a certain application has entered the MDO state. More details are in MSKB 931252.