What You Need To Know about Microsoft App-V 5
Microsoft today released version 5.0 of App-V. This complete re-write of the application virtualization stack modernizes App-V. Tim Mangan, who developed the original stack for Softricity, talks about the changes in this article.
In November 2000 we started the project to build the original SoftGrid application virtualization platform. While the software has been enhanced, renamed, and expanded over the years, many of the fundamentals and design decisions that we made a dozen years ago remain in version 4.6.
App-V 5 is the culmination of three years of work by the team at Microsoft. The software has been re-written from the ground up to meet the application challenges of today. About the only thing that will look the same to you is the user interface of the “sequencer” (a component used to prepare the applications for virtualization). So much changes in this release, that I can’t possibly cover it all in this article. Instead, I will try to focus on what you need to know right away (before your boss asks you about it).
|App-V releases via Microsoft Desktop Optimization Pack (MDOP) for the desktop OSs, but also supports Remote Desktop Servers (i.e.: XenApp) where the client license is bundled in with the RDS CAL.
Previously, Microsoft announced that their new User Environment Virtualization (UE-V) product would be released in a November update to MDOP. So while I don't yet know if UE-V is also released as of today, it probably is also. It is also unclear to me if and how one licenses UE-V on RDS. UE-V, known to some as the "Park City" project, provides for real-time streaming of portions of the user registry hive. Customizable using community generated app "recipes", UE-V should be an improvement over roaming profiles, but keep in mind that it handles registry only -- not files. More on UE-V here in the official UEV Datasheet PDF from Microsoft. Ruben also talks about Local Storage/VDI/UE-V here.
Is this a forklift?
Well, Microsoft wouldn’t want me to use that term, but it kind of is.
The bad news: There is a brand new server, a new format for the virtualized packages, and a new client. And these components don’t understand the old stuff, so we’re talking a migration here.
The good news: There is a brand new server, a new format for the virtualized packages, and a new client. App-V 5 client also supports a “co-existence mode”, so you can deploy old and new to the same user in parallel. Add the new client to support new apps and slowly migrate old apps over. There is a package conversion software that will migrate some of your packages automatically. Personally, I am not a big fan of using the conversion software and prefer to re-sequence, but it might be useful for some customers.
SFT and RTSP goes away
The SFT file format is used to hold the virtualized application contents. In App-V 5, it at long last goes away. We designed the SFT format specifically to work with the specialized file system driver that we had to invent in order to stream applications. In 12 years, things have changed! Today, this can be accomplished with SMB or HTTP streams using specialized drivers that are not complete file systems. Both the format, which was not understood by many external tools, and the protocol, which was challenging to load balance, were sticking points that made it harder for some organizations to deploy App-V.
The new format is called “AppV”. The AppV file is basically a zip compression of the complete package (essentially everything that was the SFT, OSD, Icons, and Manifest) in a single file. I should note that while we can view the contents as a zip file, standard zip file utilities cannot write an App-V file today because the streaming data needs to match the actual file layout. This change is one of many changes that make App-V 5 act more transparently.
In App-V 5, the RTSP protocol also goes away. Originally we only had RTSP, but Microsoft enhanced this with SMB and HTTP streaming previously. For the past couple of years I have been advocating using either SMB or HTTP streaming instead of RTSP. This is a good thing!
Q Drive goes away
Back in 2000, when we were dealing with mostly Windows NT, and a few Windows 2000, machines, there was only one way to mount a file system in the OS. And that was to mount it as a drive letter. So to mount our SFT based file system we needed to use a letter.
Additionally, a lot (most?) applications used private configuration files containing file references. To make these applications work, we specified that you had to prepare the app using the same drive letter that would be used at the client. Based on something as stupid as having someone walk around the machines in our own office and look for a commonly unused drive letter, we settled on a default letter of “Q”. This has always been an issue to adoption. While it was OK to need a drive letter at the client, implementing the same letter companywide meant moving some existing applications. This isn’t insurmountable, but was a pain point to adoption.
Today, most applications use the windows registry to store these paths, so App-V can virtualize all of these settings correctly. In addition, we can now do the equivalent of mounting to a folder instead of a drive letter. So in App-V 5, the virtual drive letter completely goes away. To be honest, when I first heard of this change I expected there to still be a lot of legacy applications that would not work with App-V 5, but I have been testing an awful lot of apps and they just work.
The most challenging part of application deployments (whether you virtualize or not) is managing the integrations that the application vendor creates. These can be integrations with the OS itself, or integrations with other applications. In some cases, virtualizing the application would help by allowing IT to eliminate unwanted integrations (especially those causing conflict), but in others virtualizing the app restricted app functionality in undesirable ways.
App-V 5 expands the integration points that are supported. Previously we had integrations to the start menu, file associations, and some COM objects. In App-V 5, these are now called “Extensions”. Importantly, Microsoft has expanded the kind of extensions that we can have. Among these are COM based protocol handlers, such as “mailto”. The expansion of these extension points significantly increases the number of apps that can be virtualized. And many of the new apps working under App-V 5 are some of the most complex to deploy as native apps.
While virtualizing applications to isolate apps from each other is fantastic to help eliminate conflict between applications, sometimes we need them to work together. When Microsoft announced Dynamic Suite Connection (DSC) we were excited because before then we had to package up everything that had to work together in a single package. Now we could package separately, and then define what needed to work together. Unfortunately, the implementation proved difficult to manage if you used a lot of DSC because the linkage was buried within the OSD file that was part of the base application.
In App-V 5, Microsoft redesigns this capability, making the connection a separately publishable component. This allows us to properly manage these connections and will greatly expand the use of “package to package” integrations.
Did I mention the OSD goes away?
As Softricity, there were limits on what we could do in the OS kernel that Microsoft doesn’t have to live by. Previously, we had a file with an extension of OSD that was the launch point for virtualized applications. Application shortcuts and file associations would point to a single executable (the virtual application launcher utility) with this XML file as input. The launcher utility would read this OSD file as a kind of script to tell the client how to start the app. All that goes away in App-V 5. Sometimes this caused a challenge when users or applications would try to access the application directly.
In App-V 5, the virtual application executable are directly accessible. So if they are launched in any way, the App-V client intercepts and runs it in the appropriate virtual environment. This makes the app deployments more transparent. For example, that shortcuts now point to the actual program being launched means we don’t to do “special work” to get things like the icon to look right when publishing via XenApp.
Yes, there is a new App-V Server. Or should I say Servers? The old App-V server had two components which performed several functions: A management interface to configure, a server to publish, authorize usage, stream, and collect usage statistics.
The new App-V server has three servers. For a small implementation, these can still all be placed on a single OS, but the Microsoft design is for scalability, and it follows the SCCM scale out model.
The new Management Server, is used to configure and assign applications. If you know SCCM, this is the equivalent of a Site Server. It sports a new management console that isn’t written as an MMC app. Did I mention that they started this work three years ago? Well it is written in Silverlight.
The new Publishing Server you can think of being like a Distribution Point, but probably without the files to be transferred. The Publishing server is responsible for telling the client apps that have been published to the user or to the machine. Machine based publishing was previously only available if you used SCCM, so this is a long sought after enhancement to the App-V server implementation.
The new Reporting Server is separate and optional. Interestingly, the reporting server will gather information on App-V 5 apps delivered via SCCM or stand-alone clients too. Many enterprises have other tools to monitor application use, but this server will record every use of every virtual application.
SCCM 2012 SP1 Integration
If you want to deploy App-V 5 apps via SCCM and use SCCM 2007 or 2012, you can use the virtual MSI method. But in reality you are going to want to plan your move to SCCM 2012 SP1 (Note: at the time of this writing I do not know the release date for SP1). With SP1 there is built in support for App-V 5. And just like the App-V Server, you can target virtual apps to either devices or users.
Dynamic Configuration and Enhanced Scripting
Microsoft really upped the game with Dynamic Configuration files. These files allow you to package the app once and configure separately. This does require manual XML editing today, but the flexibility is great.
Best of all is the enhanced scripting. In particular, I love that we can target a script to run when the virtual app is published. The machine deployment time scripts run in the local system space instead of the user’s own security context. This allows us to specify actions like to natively install a required device driver even though the user has standard rights. This requires publishing to the machine (without shortcuts) for this scripting, and then publishing to the user with the shortcuts and without the script.
Scripts may not only be defined for publishing, but for unpublishing, and package or application start/stops.
Streaming and Cacheless Mode
The “read-only” cache in App-V 4.6 SP1 was interesting but was not practical due to the maintenance aspects when you have to update the single cache file containing all of the apps.
5.0 has a cacheless mode that eliminates the headaches and is a winner. It works directly with the server share App-V file. This is my preferred mode for any XenApp or VDI deployments. It might be interesting for other well-connected desktop clients as well, but if they have the disk space I would prefer to let the
client cache to disk. Obviously any mobile clients need to get cached to disk. The directory listing below shows the cached file area for a typical application in App-V 5. Previously we could not get a view of the files of the package from outside the virtual environment, so that we can even see this is part of the new transparency. The uncached files of the package appear differently in this list, with the icon slightly greyed out and with an X placed over it.
Previously, App-V packages could either be created optimized for streaming (The initial portion of the app delivered immediately with rest on demand) or for offline use (everything delivered initially). In version 5, we now have three options:
Optimized for Delivery. Only the Metadata is delivered initially with the rest on demand.
Optimized for Streaming. Only the Metadata and initial portion is delivered initially.
Optimized for Offline. Everything delivered initially.
And just as in the past, if you are not configured in cacheless mode, background streaming options are available. The client background caching in 5 has slowed down and will no longer overload the network. If anything, I think the background streaming is too slow. But you don’t have to wait. Just launch the app and it will stream right away.
Package Upgrades and Coexistence Mode
App-V packages are usually backward compatible, but this release is so different that this isn't possible.
To help, Microsoft has a powershell tool that will attempt to upgrade packages. The tool, which is part of the Sequencer, is just a formatter so you can try running all of your packages through without the need to revert a VM for each. The tool has a test option to pre-determine many of the things that prevent the converter from working, but just because the tool works doesn't mean the package is good. You still need to test.
A first for App-V, it is possible to have both a App-V 5 client and a 4.6 SP2 client on the same machine. This would let you 4.6 for a while, but use 5 to cover one or two apps that don't work well under 4.6. Or conversely, move fully to 5.0 even if you find that odd app that doesn't work well on 5 yet. Personally, I have apprehensions about having a fully mixed environment with half of your apps on each client; I wouldn't be surprised to find some odd app interaction issues if you did that.
Client OS Support
As you would expect, 5.0 (as well as 4.6SP2) supports Windows 8 and Server 2012. But notice that support for Windows XP goes away in the 5.0 release.
What does Tim think: Should I use 5 or stay with 4.6SP2?
I really like what Microsoft has done with App-V 5. So much has changed, and I think that for the most part Microsoft has clearly thought through what AppVirt means today. These virtualized apps will work more like Native Apps, and things hidden away in poorly documented and complex black holes (like the FSD or PKG) are now transparent. But even though I have worked with early builds for over a year, I am still cautious. So much has changed in this release; we should expect to hit some unexpected bumps in the upcoming months and will need to work around what we find. Probably the least understood to me right now is the impact of running in compatibility mode. Customers should fully evaluate and test thoroughly if they want to go into production soon.
So the answer to what version to use depends on a lot of details in your environment, but since I don't know your environment details I will suggest the following framework to help you answer this yourself.
If you cannot get off of Windows XP, at least those clients will not be able to upgrade to 5.0.
If you are starting a new deployment, or are still just starting your Windows 7 migration, then I would jump to 5. I think you will prepare more apps and faster.
If you currently use 4.6SP1 and are heavy into (or just finished) your migration to Windows 7, I would hold off for a while. Most likely you should upgrade the clients to 4.6SP2 as soon as possible. If you have some troublesome apps that you still need to deal with, try them in 5.0 and consider adding the 5.0 client in compatibility mode. Over time, you can slowly migrate apps over. How long you live with compatibility mode is up to you.
If you currently use 4.6SP1, and are not into a Migration, you might stay pat for now. Start testing with 5 and know your options. While the range of apps that App-V 5 can do will be greater than for 4.6SP1, we don’t really know if it will be a proper superset, or if we will find some that no longer work with 5.0. So far, things look pretty good in this regard, but it is not unconceivable that some applications might fall off the list.
Tim Mangan is a Microsoft MVP for App-V and a Citrix CTP. He is the author of several books and can be found at TMurgent Technologies (www.tmurgent.com) where his title is "Kahuna".