Independent App-V Blog

The MSI Utility for Microsoft Application Virtualization is a new tool designed to extend virtual application deployment in certain key scenarios. In cases where a computer running Microsoft System Center Virtual Application Server is not available, the MSI Utility allows delivery of sequenced applications directly to Microsoft SoftGrid Application Virtualization for Desktops and Microsoft SoftGrid Application Virtualization for Terminal Services. 

Read more and download at source

Earlier than expected, Microsoft has introduced Dynamic Suiting (interaction between separate bubbles) in the public beta release of Application Virtualization version 4.5. 

It is fairly easy to allow two applications to interact with each other. The only thing you’ll need to do is to edit the OSD-file of the application that you want to allow to interact with another bubble. 

For example, you want to allow the application front-end to interact with middleware. Open the OSD-file of the Front-end application with a text-editor and add these lines:

The CODEBASE element can be copied from the middleware-OSD you want to use. All you need is the REF, GUID and SYSGUARDFILE from the middleware OSD and the additional MANDATORY=”TRUE” setting.  Note: don’t confuse the tag with the older tag. Now import the edited OSD in your VAS-server and refresh your 4.5-client (note: dynamic suiting will only work as of client version 4.5). When you launch the front-end application, the middleware bubble as defined in the OSD-file, will also be launched and interaction between the two will work like a charm. It is only possible to allow interaction between bubbles on one level. If you’d edit the OSD-file of a third application to allow access to the front-end bubble, this third application will not have access to the middleware bubble. It will be able to interact with the front-end bubble though. It is also possible to allow more than one application to interact with the same middleware bubble. This provides for several front-end applications to use the same middleware package. The Dynamic Suiting feature is great news for all of you that have been struggling with middleware. Softgrid retains its position ahead of all competitors in the market, being the only true virtualization solution that offers virtualization of services and interaction between separate virtual environments. 

As usual, there are some downsides as well. Administration of bubble interaction is most likely going to be your biggest nightmare. Nowhere, except in the OSD-files of application using middleware, you’ll be able to find which applications are allowed to interact with other applications. This isn’t a big problem if you have a limited number of applications, but you can imagine that it can cause severe headaches if you have several hundreds of applications, using all kinds of middleware. Microsoft has not planned for any administration tool to address this. 

Another possible problem is conflicts. The default behavior of interacting bubbles is that the launched front-end application precedes over the used middleware. If you have two versions of the same DLL, the version in the front-end application will ‘win’. This avoids technical conflicts, but it can introduce other issues if certain functionality needed in the (possibly newer) DLL in the middleware application is required. This scenario re-introduces regression testing, something we were happy to get rid of with Softgrid in the first place. 

The really good news is that you don’t need to re-sequence your existing applications: all you need to do is to edit the OSD-files to allow interaction. This of course saves you and your customers a lot of time!

Finally…Microsoft released the MSI Utility for Microsoft Virtual Applications (aka the MSI Wrapper) and pretty quiet I might add. Not even a post on the SoftGrid Team Blog. I had expected some sort of announcement. Probably due to holidays or something.

Anyway, I’ve been waiting for this tool for some time and I’m curious if it meets up with my expectations. I know the SMS 2003 connector with its shortcomings and I’m hoping for a simple way to use SoftGrid applications in a SMS2003 / SCCM environment. On the download site I noticed that the tool supported only SoftGrid versions 4.2.1.21 (or later) and 4.1.2.21 (or later). Personally I don’t know these versions and was convinced that 4.1.1.310 (4.1 SP1) and 4.2.0.310 were the latest ones. Still…let’s have a look.

The download (MSI_Utility_1.0.0.16.exe) consists of an MSI Admin Utility Guide, MSI_Utility_Release_Notes and the actual setup. The setup still installs to [c:\program files\softricity\MSI Utility] by default. You would expect that “Microsoft” would have been used as part of the path (as in the 4.5 beta client). After installation, the tool offers a GUI and a command line version (both are included in the installation directory). Both tools are easy to use and can be used with an individual project (. Sprj) by using [MsiUtility / s ] or a directory by using [MsiUtility / f ] The GUI version looks like this

The checkbox “Recursively package all virtual applications in the folder” is ideal to get multiple SoftGrid applications migrated to MSI at once. Just point to the root of your Content share (or any other directory) and start converting. The downside to this mass conversion is that the MSI Utility doens’t change the SFT and it’s version. If you want to (re)distribute already enrolled SoftGrid packages through MSI you might get in trouble on clients that have the same package version in cache.

Anyway in the installation directory remains a file named Template.MSI which is used by the tool for generating the MSI(s). Any amendments made herein are therefore generated in all MSI’s. Very useful if you, for example, want to use project or company info to be included in Add / Remove Programs. So what is generated? The utility generates an MSI file and a xml file (manifest) similar to what can be found natively build-in the SoftGrid 4.5 sequencer. The OSD files, icons and xml file are included in the MSI (respectively in the PackageComponent and IconComponent), but also remains in the source directory (useless??)

The MSI uses LaunchConditions to determine whether SoftGrid client version 4.2.1.21 (or later) and version 4.1.2.21 (or later) is installed. However when I tested the MSI on my SoftGrid 4.5 beta client (which is a later version), the installation failed and told me that I didn’t have a compatible SoftGrid client. This will hopefully be fixed in later versions of the beta. The MSI Utility uses a CustomAction dll (SGDeploy.dll) to talk to the SoftGrid client, while the MSI from the 4.5 Sequencer fires the commands directly through SFTMIME. The three functions responsible for interaction are RemoveSGApps, DeploySGApps and UpgradeSGApps.

Still, when I removed the LaunchConditions from the MSI (and the installation begins to run) it still reported an error. Apparently, the 4.5 Client is not suitable for the commands that the SGDeploy.dll (yet?) Sadly the latest version of the SoftGrid client I had was 4.2.0.310 so I was unable to succesfully deploy an MSI. Eventough this time he recognized that SoftGrid was on the machine, it stated that the version was not correct. Again, removing the LaunchConditions didn’t help.

This means that I will just wait until I have the correct version of the SoftGrid client to see the whole thing work. Despite my disappointment after the long wait, it looks promising. To Be Continued …