Archive for April, 2012


Hello, my name is Patrick Mangan, and I have been sequencing with App-V. This year TMurgent added a sequencing service where we take on applications that customers are having a really hard time sequencing. Recently while working on one application that had a proprietary licensing scheme to work around I ran into another, unexpected error that I needed to troubleshoot.

After creating my package, I was able to deploy it to stand-alone clients and have them run it just fine, however when I tried to add it to SCCM as an App-V package, I receive a weird error.

Load Virtual Package Failed.

The message told me that there was a problem with some of the file icons, and SCCM would not let me complete importing the App-V package. The App-v sequencer automatically generates icon files for applications that have shortcuts or file associations.  It does this by extracting an icon resource from the executable file that would be run.  EXE and DLL files contain resource sections inside their PE format, which are normally used by the Windows Explorer to display the file.  The App-V sequencer will grab one from the file and save it as an ICO file.  This is needed at the App-V client to make the shortcuts and file associations “look right”, because the actual exe for the shortcut will be the App-V client launcher (and we don’t want all of those shortcuts looking the same).  So what was the problem with the icons and which one or ones were causing the SCCM error?

When I tried opening each of the icons from the App-V package up using the Windows Photo Viewer,  some of the icon files gave me a generic error message (shown below) that wasn’t helpful except to let me know which icons were a problem because they would generate this error.

Windows Photo Viewer cannot open this picture

These icons also could not list their details when I looked at their properties by right clicking on the file in the windows explorer.  Here are examples of a good and bad icon file.
Blank Details tab Details tab with details

App-V is known to have an issue with icons that are of rectangular (not square) dimensions, so this was my initial thought.  But rectangular icons wouldn’t have looked bad in Windows Photo Viewer so something else was going on.

To solve this problem, I opened the problematic files in Visual Studio. This gave me multiple types of information, including the image itself and version info. Deleting the extraneous information did not make the files work, but I was able to copy the graphics information and create a brand new ICO file with just the copied bitmap images. After replacing all the problematic files in this manner, I was able to create an App-V package in SCCM.

The problem appears to be that the icons for some of the obscure shortcuts were originally created by a 16-bit app, and those are not supported on the x64 systems we were using. I don’t know much about icons and the word bit has too many different meanings, so I can’t tell if these were 16-bit icons or not.  Certainly the executable behind the shortcut was not 16-bit, since it worked fine on the x64 OS.

So if you run into this error, replace out the icons!  You don’t need a fancy tool like Visual Studio.  There are lots of simple tools around that will let you draw your own icon from scratch.

Note:This is part of a series on App-V 5.0: Part 1 Part 2 Part 3 Part 4 Part 5

Check out the size of this second package in the App-V 5.0 Beta.  10GB!

10 GB Package

Note:This is part of a series on App-V 5.0: Part 1 Part 2 Part 3 Part 4 Part 5

A long staple of App-V has been the OSD file.  This XML based file, along with the sfttray.exe command that runs it, has been the behind-the-scenes mechanism for how users start virtual applications.  but you won’t find them in App-V 5.0 Beta.  What happened?

Two things.

First, at the client, the publishing process no longer points to an App-V client launcher program (sfttray.exe).  The shortcut is to the actual exe, and the App-V client intercepts the loading to do it’s special magic.  So no OSD is necessary at the client.

App-V 5.0 virtual app shortcut

Second, at the server, you might notice something called the Defualt Config when you right click on the package. 

App-V 5.0 server console

This is an XML based replacement, but affects the entire package and not an individual application.  The name default config imples that perhaps we can have multiple configurations, although there doesn’t seem to be a way to have more than one to a package at this point. From the Server Management Console you can easily disable applications, shortcuts, and file associations from the package. You can also export it to a file for ready viewing or editing.

Config XML file

The cool thing about this config is that the App-V server now supports both per user and per machine configuration. For years we have wanted the ability for both. Specifically, Universities often need to deploy AutoCAD only to machines in a specific lab, while other apps whould be per user. The App-V server did per user only, and SCCM 2007 did (effectively) per machine only. SCCM 2012, when finally released, will add real per-user as an option, and whenever 5.0 releases we get the per machine option for the App-V server.

Note:This is part of a series on App-V 5.0: Part 1 Part 2 Part 3 Part 4 Part 5

One of the new surprises to be seen in the App-V 5.0 Beta is that the old SFT format is gone, replaced by an AppV format.  So what’s up with that?

The SFT format was created for the original SoftGrid product in order to support the groundbreaking file system we created to support streaming on a block, rather than file, basis.  This file system, which we called the “Jigsaw” file system internally, was unique from any other file system due to this feature.  Most of the Softricity patents were based around this file system and it’s usage.  Any other file system, CIFS, NFS, and others, could only remotely copy entire files, but this file system could bring over portions of files on an as-needed basis.  To make use of this unique feature, we needed a file format that presented these blocks to be streamed, and this was the SFT format.

In the App-V 5.0 Beta, Microsoft has removed the Jigsaw file system, as exposed by the Q: drive, and thus also chose to eliminate the SFT format and replace it with a new AppV format.  I think that this effectivly eliminates block level streaming, but I stopped being a fan of that feature many years ago, so big loss there.  So just what is this AppV formatted file?

Basically a compressed folder.  After sequencing a new package with the 4.0 Beta, I made a copy of this .AppV file, and renamed the file extenstion to .zip.  Now I can browse and look into the APPV file.  I’m not sure if I can make any changes here, as it might be based on a compressed format with something special that I might break by saving a change, but at least I can look around.  Here is an example:

AppV format

So since the SFT format is gone, does this also mean the end of the 4GB limitation?  You betcha!

Note:This is part of a series on App-V 5.0: Part 1 Part 2 Part 3 Part 4 Part 5

Plowing my way through the new Sequencer.  Looking at the options page of the sequencer, the ParseItems look a little different.

ParseItems

One of the most important jobs of the sequencer is to make the package Machine, OS, and User neutral.  The sequencer does this by locating hard coded paths in the windows registry, file path info, and maybe looking into some files like .ini files (although some of that latter support has been removed over the years).

When we built the product, we latched onto a Microsoft developer technique to produce code that was OS neutral – CSIDL.    This stands for “Common System InDependent” plus something starting in the letter L.  Different documentation in the day called it “List” or “Link” depending on which you found.  CSIDL solved the problem of a client windows installed to the Windows folder or WindowsNT folder (which was popular at that time), or on a drive other than “C” (popular under Citrix).  When Windows Vista came out, it also solved the problem of “Documents and Settings” versus “Users” folder names.  So whenever the sequencer saw “C:\WindowsNT” it would replace it with “%CSIDL_WINDOWS” in the sft package.  Then the client could replace the CSIDL with whatever was appropriate there.

Microsoft originally documented the CSIDLs in a KB article that has long since been removed.  It was updated in each OS release to include sections of OS specific changes.  App-V, at least prior to 5.0, used these CSIDLS like environment variables in these Parse Items.  There were a few non CSIDL additions as became necessary, like the famous %SFT_MNT% (representing the Q: drive).

But with Windows Vista, Microsoft deprecated CSIDL and removed the KB (It seems they now have one with a partial listing ) and started recommending developers use a new, but very similar KNOWNFOLDERID  KNOWNFOLDERID syntax.

It was unclear how App-V would handle this transition, and until this Beta they have been able to ignore it.  But here in the 5.0 Beta, we can see that they have replaced the old CSIDL syntax with an App-V specific syntax that they can map into whatever the OS supports to help with the mapping.  This is nothing more than in internal plumbing change that will make it easier as the OS continues to evolve.

Beta for App-V 5.0

Note:This is part of a series on App-V 5.0: Part 1 Part 2 Part 3 Part 4 Part 5

In a blog post today, Microsoft’s Karri Alexion-Tiernan announced the Beta for App-V 5.0, plus an additional MDOP add-on called UE-V.

 App-V 5.0 is the most dramatic change to App-V in a really long time, possibly the biggest since the initial release by Softricity.  While I have been working with previous releases, I’m not ready to talk much about the Beta.  So much of what I know is under NDA and Microsoft surprised us with the announcement today, so I’ll need time to confirm what is actually in the beta.

For those people who have been asking me if Microsoft will continue with the App-V server, the beta answers this clearly with a “YES”.  The server has been rewritten and works completely differently.  The console is browser/silverlight based, and we can say goodbye to the RTSP protocol, as the new server prefers more mainstream protocols like HTTP.  And you’d better learn powershell because you’ll need it on the server.

The Client also undergoes radical change, as the virtual drive (Q) goes away.  Things are now more “transparent” than before, which may or may not turn out to be a good thing.  SFTMIME and SFTTRAY are a thing of the past, and powershell is now the name of the game.  Also, I’ll note that the changes for VDI are a vast improvement over the Read-only cache implementation of 4.6SP1.

The Sequencer remains similar to 4.6SP1 from a UI perspective, however the output is no longer the SFT format.  Conversions of old packages to the new APPV format are possible using some powershell utilities (I have a tool to help automate that), but expect to find more than the usual number of packages that will have to be re-sequenced from scratch.  That’s the downside of removing the Q drive.

Oh, and did I mention powershell?  Yeah, if you don’t know it yet and want to work with the new App-V you better start learning fast.  I’ll write more as I get a change to confirm what a may or may not say yet.  What I can say (since nobody at Microsoft gives me the slightest inkling of a release plan) is that this is probably an early beta and we are far from release.  Since Microsoft announced the Beta of 4.6 SP2 just one month ago (to support the Beta of Windows 8), this adds credence to a slow release process.  But you never know.

As to the UE-V announcement, folks like Appsense and Unidesk must be really happy to see Microsoft validate the user environment (layering) strategy.  UE-V as a Microsoft product is not likely to be robust enough to cut into their market share;  possibly acting as Terminal Services does to meet the needs of a few while enhancing the need awareness to Citrix XenApp.  But again, time will tell.