Archive for March, 2012


I had an opportunity to speak before our user group on Application Virtualization a few weeks ago. We record the videos so we now have this talk available online.

The basis of the talk was a higher level talk than I normally do, but it does explain what I see going on in the AppVirt space right now, which is a whole lot of activity — primarily associated with folks migrating to Windows 7. Below is a link to the video, and another to the slide deck.

“App Virt on the Desktop, in VDI, in the Cloud”
TimMangan_VirtualAppsEverywhere_2012DeepDiveDay.ppt

One side conversation from the discussion when I later presented this at a cloud conference in NY: It is amazing just how much App-V is being implemented right now as part of Windows 7 migration.  If ever a product took a while to hit the mass-market penetration stage, App-V would be it.  But the truly amazing part is that it is happening at a time that the trade press has pretty much forgotten about application virtualization, except as a side note like “and of course you want to use appvirt when doing VDI“.

I haven’t posted a sequencing video in a while, so I was due. Then a customer queried me about dealing with a large package. When I looked into the question, I found that the way I used to deal with large packages isn’t supported by the sequencer any more (when did that change?).Sequencing With Tim Mangan

So I worked out a different way, and decided to document it for everyone else.

The Issue

The issue is that the SFT file has a 4GB size documented limit. The 4GB limit is after compression, so you can stuff more in as long as it compresses. As we have seen in the past, the 4GB limit seems to be somewhat of a soft limit; you can go over a little and the package seems to still work — but you are never sure if a user might eventually hit a piece of functionality that crashes the app. And we aren’t sure what “over a little” really means, because packages fail at some point. My friend Nicke has further determined that if you create a small feature block 1, you can create a much larger app that seems to work. But still we worry about those.

The solution to getting under the limit is in understanding that it is a per package limit of the SFT itself. The most common techniques to work around it are:

  • Reduce the size of the app. Often this means a custom install with less features, and/or cleaning files out that are not really needed.
  • Redirecting portions of the package to live on a file share as supported by the app. This requires an app that has some registry based path locations that you can modify.
  • Redirecting portions of the package to live on a file share using the Microsoft App Compat toolkit. This unfortunately involves developing a shim and then requires an external install of the shim at the client to work so it isn’t so popular of a method to use.
  • Moving portions of the package to live in a depdent package and using Dynmaic Suite Composition. This method always works and is supported.

The Universal Solution

The solution that seems to work for all apps is the last one. And this is what I show how to do in the video. When Dynamic Suite Composition (DSC) is used, the sum of all the assets may rise above the 4GB limit. To our knowlege, there is no limit on the sum size of all of the layers. As there is no known limit to the number of dependent packages that you can add. In a practical sense, the limit might just be disk space in the cache, followed by how much memory you have.

The video for lucky Episode 13 may be found here: Sequencing With Tim Mangan. It is about an 18 minute video, and if you pay attention to the system clocks in the VMs, you will see that I shot the two sequencings and client testing all in a single sitting in under 15 minutes.

Last week Microsoft opened up the Beta for App-V 4.6 Service Pack 2. You can apply at http://connect.microsoft.com for permission to join the Beta.  They ask a lot of detailed questions about your environment, but it seems to be an automatic approval into the program.  You find the beta under the Microsoft Desktop Optimization Pack, although it supports both Windows Desktop and Remote Desktop Services.

So just what is this beta?  Great question.  All we have for information right now is a blog post by Karri announcing availability (Windows Team Blog ).  So based on past practices of Microsoft, here is what I think.  I cracked it open over the weekend for a look as well.

The Beta consists of only the sequencer and client, no server components.  This looks and smells like just a tool to support lab tests of the Windows 8 Beta and Consumer Preview.  Microsoft did a similar thing for App-V when the Windows 7 Beta appeared.  Of course the odd thing is, unlike with Windows 7, I didn’t really need a new App-V version to work with Win8.  I have been happily sequencing and testing virtualized apps on Windows 8 Developer Preview, Consumer Preview, and Server Beta using 4.6 Sp1 with Hotfix 3 or above without any issues.

The only noticeable change to these components, is the addition of the three new OS  names to the OSD files.  These new tags ( Win8, Win864, and Win8TS64) have now been documented in my updated OSD_Illustrated online reference , and in my OSD Reference e-Book .  But since most of us routinely use the “allow to run on any OS option”, these are not really necessary.

I assume that the 4.6 SP2 Beta includes a rollup of the current hotfixes.  There have been 5 hotfixes since the last release; and the first three are important to everyone.  Microsoft would normally include all existing hotfixes, but it is possible that Hotfix 5 could be missing because it hasn’t been out very long.   But we don’t know because release documentation is traditionally a weak link with App-V.  (On a side note, I had a great side conversation with a leader in the support team while at the MVP summit last month on this topic.  Possibly we will see better documentation in the future as someone on that team now understands how little we really get, and how useless most of it is).

Applications sequenced with the SP2 beta have OSDs that are marked with a minimum client version of 4.6.0.0.  This implies that packages sequenced using SP2 should work with clients that have Sp1, or even 4.6 without a service pack.

But as I usually find, there are other differences in SP2 Beta.  Nothing that affects the UI – the sequencer still has the same “improved” wizard (Microsoft’s term, not mine).  I only did a few apps, but managed to run into one that exposed an issue not present in SP1.  Hey, it is listed as a Beta and we shouldn’t be using it in production — I get that.  I’m not complaining, just pointing out that it is different.

But different opens another door.  An unsupported, “don’t go there” door as far as Microsoft is concerned, but to me a door is a door if it gets me where I need to go.  If you have an app that won’t work under SP1, you might just try sequencing it with SP2.  Who knows; it might just work due to some other undocumented change.    And since you can test that app and deploy using supported clients, what would be the harm?

Will there be other surprises in this service pack?  Time will tell.  Microsoft isn’t publicly speaking about what is next with App-V yet.