I ran the effort to build the original version of App-V at Softricity, the company that Microsoft acquired the product from, almost a dozen years ago, and the 5.0 Beta release represents the most dramatic set of changes to the product since. Much has changed in computer technology of that period, and Microsoft very clearly has looked at what is needed for application virtualization today and redesigned App-V from the bottom up, eliminating outdated implementation concepts, focusing on the goal of making virtualizing applications as simple as possible.

As I have been digging my way through the early versions of App-V 5.0, one thought stands out from all of the others. Microsoft is clearly evolving the way that App-V integrates virtual applications into the Windows experience. In this article I will talk about several of the changes that illustrate this thought, not only for End-users, but IT professionals and ISV developers as well.

Goodbye .SFT, Hello .APPV!

One of the first things you notice about App-V 5.0 is that the old SFT file format for containing the virtual application packages is replaced by a new APPV format. The original SFT format was a rather clumsy format. Back when we built the original product, we created the SFT format using a mixture of file system and Windows PE technology. Back then, software piracy was ramped. Because we wanted to make sure that ISVs didn’t view us as a new way for people to steal their software, we made sure that the format of the SFT would make it very difficult for someone to reconstruct the software from if they sniffed the package streaming down over the internet. Internally, we called this the “jigsaw” format, because we pretty much chopped files into pieces. For years, this format was officially undocumented, and except for a couple of third party tools that exposed the contents of an SFT, the file format was a black hole. This eventually changed as Microsoft wanted ISVs, or at least the MSI repackager companies, to support the SFTso they officially documented the format.

Shortly after acquiring Softricity, Microsoft hinted that they wanted to migrate the SFT to a standard format. Their thinking at the time was to move to a VHD format, but have settled on a new proprietary format based off of zlib compression, which is natively supported by the OS kernel, and reasonably understood by many standard tools. Enterprises today understand and actively manage application licenses today, so the need for the original obscurity of the format has gone away.

If you make a copy of the new .AppV file, and rename it to .ZIP, you can open the package as you would any other zip file to browse and view the contents. Because the compressed file contains unique block offset information for streaming purposes in the XML based metadata files, you should not make any changes to this zip file opened in this maner (hence the “make a copy of” in the opening sentence of the paragraph).

Presumably, Microsoft will officially document the AppV format, and we will see tools crop up that support creation and editing of these files outside of the sequencer. For now, it is great just to be able to quickly look into a package without special tooling.

So what is in this AppV file? Functionally, it is the equivalent of not only the SFT file, but also the manifest.xml, OSD, and ICO files all rolled up in one. I’ll talk about the OSD files going away later in this article. What you will see inside the App-V file is a folder called “root”, under which the virtual file system lives, a virtual registry file, and several XML files specific to App-V.

Much of the XML used in App-V borrows heavily from schemas used in the new APPX format for Metro style apps. Specifically, App-V seems to extend the AppX schema files that Microsoft created to be their new standard for an application self-description. This is not at all unlike how Softrgid (App-V) extended the original (proposed) OSD standard. Virtual applications have unique requirements that require these extensions. I assume that Microsoft will also formally publish these schema extensions to better support third party vendors sometime before product release.

The elimination of the Proprietary SFT format coincides with the elimination of the 4GB package limit. Microsoft has not stated a new size limit, but it would be much bigger than any application you might want to virtualize with App-V.

Ultimately, that this new APPV format is much more transparent than the old SFT format should make dealing with Virtual Applications much simpler for the IT staff that has to deal with them. This might not directly affect the end-user, but was sorely needed today.

Goodbye “Q” Drive!

One very sore point to anyone implementing prior versions of App-V (and SoftGrid before it) for the first time is the requirement that they identify a drive letter to mount the virtual file system. By default, App-V, defaults to use the Q: drive letter for this mount, so we generically call this the “Q” drive, no matter what letter a particular customer might use. In App-V 5.0, the “Q” drive goes away! There is no need to have any additional mounted drive letter at the client.

A Little History of the “Q” drive App-V uses a unique file system to enable the block-level streaming capabilities. While the streaming mechanism changes in App-V 5.0, it still does block level streaming. The Q drive dates back to when we first designed the SoftGrid platform at the end of 2000. Back then, the predominant installed operating system in the enterprise was Windows NT, and Windows 2000 Professional was the newcomer. The only way to mount a file system that was supported by those operating systems was to mount to an unused drive letter. The capabilities that we have today, to mount to a folder did not exist. So this new file system had to be mounted to an unused drive letter. As we built the product and started working with applications to be virtualized, we found that so many of the applications in those days had file paths stored in all sorts of oddly named files. For those applications to work, we needed the apps installed on the sequencer to the same drive letter as would appear on the client. So we created the practice of standardizing on a single drive letter for any companies implementation. We needed to pick a default drive letter for the installers, so I sent a developer around our building with the task of looking at everyone’s PC to determine a reasonable letter that wasn’t in use. The developer came back with the letter Q. If the CFO had been in the office that day, we probably would have ended up with a different letter, since I know he used Q: for Quicken!

App-V 5 eliminates this legacy complication for new deployments. While we can’t tell for sure if the new technology used is technically a “mount”, the effect appears as if each APP-V package deployed to a client machine is mounted as a sub-folder in the hidden system ProgramData area. For each package (on a system installed using defaults) you will find the new APPV file under C:\ProgramData\AppV\PackageId\VersionId (where PackageId and VersionID are the package GUID and package version GUID).

If you use the Windows explorer to view a deployed package, you will have read access to view the package. What you will see is identical to what we see when we open the .AppV file as a zip file. In addition, if you do this shortly after adding the package to the system, before the package is fully streamed (called downloaded in the new system), you can notice a visual difference in the file and folder icons. When the package is added, the manifest is immediately brought to the client and is used to describe all of the files to the OS, allowing the Windows explorer to show you the complete directory listing, even when the files themselves are not yet downloaded (streamed). Those files that are not yet fully downloaded will appear with a grey “X” over the file icon, as is seen in the image below:

We sometimes use the term “over isolation” to describe the problems that occur when a virtual application becomes too hidden for the integrations needed by other applications or the OS itself. This new visibility to the mounted application in App-V 5 implies another significant transparency change in the new App-V system. Applications running outside of a virtual application now can have visibility into the files of another package. Thanks to isolation, this is different than running in the same virtual environment, but has uses in enabling certain isolated app launches that required manual scripting and external (native) deployments in the past.

Another transparency improvement is the storage of the virtual registry. Previously, this was also a unique proprietary format called CP, but in App-V 5, Microsoft has adopted a standard registry format. You can use regedit to mount the Registry.dat file inside the .APPV file as a new hive to view the virtual registry.

To date, I find only one concern over the new mounting method, and I have yet to find an example to illustrate it. What we lose in this new mounting method is the ability for the application to appear in the exact same file layout as on the sequencer, so those apps with hidden folder references would break. I knew from experience that application developers have been getting so much better about storing those locations in the Windows Registry. I have routinely tested new applications in the current system for about two years by NOT installing to the Q: folder and have not been finding issues, so I know the ISVs have improved their applications. But I still expected to quickly find several apps that would break due to hidden strings under App-V 5. They probably exist, but I have not found any yet. If one does show up, we can probably deal with them using the new deployment scripts, so all is not lost.

The removal of the Q drive will clearly make virtual applications more deployable across the enterprise, eliminating a stumbling point in new implementations. It also makes the virtual apps appear more natural to the end-user and eliminates help desk calls when users try to access folders on that drive.

No more tray icon popups

Prior to App-V 5, as virtual applications stream, launch, and shutdown, there are messages that appear above the icon tray. Streaming progress is displayed, but there is this indication of launching and shutting down the application. When we built the original system, this streaming progress was very important as it took much longer to stream an app than it does today. Over this period of time, applications may have doubled in size on average, but LAN capacity is generally an order or two of magnitude greater.

Users should not have to care whether an application is virtualized or not. In a LAN environment, they probably won’t even notice any difference in running the application for the first time before complete download (streaming) or after. It was time for this visual distraction to go away.

One downside is that if you have a very large application package and the user attempts to start an application in that package right after publication, but before much is downloaded, we have lost that visual indication that something is happening. We can still create a smaller subset to stream down first (what we used to call Feature Block 1) to improve that user experience.

No More “Unnatural” Looking Shortcuts

Under the current App-V system, the shortcuts that a user receives to launch an application all point to a single executable, either sfttray.exe or vapplauncher.exe. In App-V 5, the shortcut points to the actual exe located in the mounted virtual application package!

The only indication that this is a virtual application will be that the path will start with C:\ProgramData\AppV and a couple of Guids. This will be important for the Help desk folks to understand that this is a virtualized application. We still have the ability to “reset the pkg”, which is now called “Repair User State”, should a user damage their virtual application. And since it still works on a virtual application package basis it is much better than having to delete the entire user profile!

Another impact of this change is that the user no longer has to start the application via an App-V integrated launching mechanism (shortcut or file type association). Any way that the user launches the identified package application, including browsing to it and double clicking on the exe, will cause the executable to be launched in the virtual environment. The App-V client intercepts the launch request and handles the launch appropriately. The need for this natural launching mechanism has become more and more important over the years as users have become more sophisticated computer users.

Improved Integrations

Applications need to integrate with the user experience, and App-V has traditionally imposed limitations on virtual applications by only supporting a subset of these integrations. Support has included application shortcuts, file type associations, and some additional shell integrations.

The limited shell integrations have been an annoyance, but not a hindrance to virtual application deployments. While certain simple integrations, such as adding a “Send To”, were supported, others, such as “MailTo” were not.

App-V 5 significantly extends these integrations, supporting more (but not all) of the integrations commonly used by applications. For example, those protocol handlers, such as “Mailto” to use whatever external mail program you use, are now supported.

It isn’t 100% coverage. For example, that drag-and-drop handler that 7zip has is still not supported as of the Beta version, but we haven’t seen the final release). But the integration support is much improved, allowing more applications to be virtualized and those that are to have fewer limitations.

New Event Logging, No More 0A-0000100E!

While users don’t care about logging, IT professionals, as well as third party developers do. Microsoft has re-worked the old text log mechanism used by App-V. Previously, Microsoft adapted this text logging system to also post to the Event log, under the Applications log, but it really was just a copy of the information posted to the text based log file. Those messages used an archaic message number scheme that was difficult to decipher and made searching for information online difficult.

In App-V 5, Microsoft eliminates the text based log file and those error codes. Instead, the product has its own dedicated area for logging in the “Applications and Services Logs” portion of the event viewer.

Messages are easier to locate, and appear clearer and to the point now. Moving the location and making improved use of the EventId code will also make it more possible for monitoring applications to listen for certain events and take appropriate actions.

A Console Your Mother Won’t Hate

While I am not in love with the new client console, it is at least something you can consider letting users have access to. Redeveloped in Silverlight, the console is now graphical and not just another MMC snap-in.

The big question is whether you want to give users “self-repair” rights. As I have discovered no way to disable this functionality without removing the console, this question appears to be the gating item in whether to give this console to end-users or not. You can see this feature in the Packages list of the new console, shown below, as “Repair User State”.

These days many companies understand that they have more computer savvy users than before, so giving users the right to control their own applications is more acceptable (even desired in some cases) than it was in the past. If you are one of those companies, you might like this console more.

Summary

While there is much more to talk about with the new App-V 5, the changes I have discussed in this article make it clear that this version will make the experience of virtualized applications more natural, to end users, IT professionals, and independent developers.