App-V 4.6 delivers big integration benefits with Windows 7, Windows Server 2008 R2 and more

[Note: This is an updated version on 1/6/2011 of the original 2/22/2010 post based on recent information provided by Microsoft on Branch Cache.  See also this post: https://www.tmurgent.com/TmBlog/?p=306  ]

 While many of us have been waiting on the release of App-V 4.6 so that we could upgrade our Terminal Servers to WS2008 R2 to take advantage of 64-bit (see my blog article on 4.6/TS ) it’s not the only reason that this release of App-V is important to customers. While App-V may also be important for the desktop as 64-bit desktop becomes a reality in the enterprise, there is much else new to talk about – especially for Windows 7.  In this article, I will discuss each of what I feel are the most important new things for the desktop, mostly focusing on Windows 7 desktops, but also hitting items of interest to other App-V deployments.

Of course, I need to mention that App-V for the desktop operating systems is only available through the Microsoft Desktop Optimization Pack (MDOP)  which is an option for desktops licensed from Microsoft via Software Assurance.

Duh, x64!

With so many physical desktops and notebook computers shipping with 4GB of ram, it makes sense to run the x64 version of the operating system.  Running the 32-bit limits you to effective use of roughly only the first 3GB.  So while going to the x64 OS uses a little more memory, the gain is larger.  With many of the reasons holding back x64 deployment at the desktop now gone – primarily driver issues – we are seeing more people deploying x64 operating systems at the desktop.

App-V 4.6 adds support for the x64 operating system clients.  This includes the x64 versions of Windows XP, Vista, and Windows 7.   Virtualized applications may be either 32bit or 64bit applications.  For a large part, existing 32-bit applications sequenced (the process of preparing a virtualized application) with App-V 4.5 will run with a small tweak to an xml file to inform the client that it is OK to run the app on this OS version.  Sometimes this might not work on an app when you test it; in the worst case, all I have had to do is open up the package in the new 4.6 sequencer and save it again to make it work.

Windows 7 UI Integration

Windows 7 has changed the way the Task Bar works.  Gone is the “Quick Launch” bar, but now we have “Jump Lists”.   Applications can be “pinned” to the jump list, which means they remain on the task bar whether running or not.  App-V 4.6 adds support for jump list pinning for virtual applications.

While sequencing on Windows 7, if the application that is being virtualized is pinned to the Jump List, this will be detected and saved as part of the package.  When the virtual application is published, this setting is applied and the user will have the same experience.  The user can override the jump list setting, either pinning an app to the list or un-pinning.  On a publishing refresh, the unpinning would be lost (meaning it will be pinned again if the application publishing pins it).  On the other hand, the publishing refresh would not remove a user initiated pinning just because the app did not have that setting.

Pinning all published apps wouldn’t make a lot of sense; that is what the Start Menu is for.  So automatic pinning of apps sequenced with older versions of the sequencer is not done.  It is possible to manually edit the OSD of an application sequenced on another OS (or previous sequencer) and add the shortcut to the jump list.  That shortcut setting will simply be ignored on clients running Windows XP and Vista, where it would be inappropriate.

Windows 7 and Branch Cache

One of the cool features in Windows 7 is for users at smaller branch sites of an enterprise – Branch Cache.  Windows Branch Cache lets remote site users share a site cache that automatically detects files previously sent from the main site, providing local copy access instead of the slower WAN link (and adding to the congestion there).  While this works great for CIFS/SMB traffic, it does not accelerate access to files using any arbitrary protocol without support.

[Edit:  It turns out the following paragraph contained in the original post was in error.  This was due to incorrect information provided by Microsoft.  The new information from Microsoft is added in the bold paragraph that follows.  The non-bold portion of that new paragraph is from me.  I am sorry for the confusion.]

App-V 4.6 adds the support needed to allow the RTSP and RTSPS protocols to work with Windows Branch Cache.  This means that if one desktop (or site local 2008 R2 remote desktop server) streams down an application from the App-V Server, the others can get the portions streamed locally from the branch cache, reducing traffic on the WAN and speeding up application deliver for the end user.  

BranchCache improves performance when copying files between central and remote or branch offices by using the SMB, HTTP, and HTTPS protocols. SMB is the protocol that is used to transfer files between shared folders on Windows networks. HTTP and HTTPS are the protocols that are used by web browsers and many other applications.  Thus BranchCache does not help with remote App-V clients using RTSP or RTSPS to communicate with a head end server.  BranchCache should provide help for remote site clients that use non RTSP/S methods of retrieving the packages, including HTTP and HTTPS, or ASR/ISR/OSR overrides using the file:// syntax.  It is unclear to me what (if any) changes were made in the 4.6 client to enable this.  More likely, you need the 4.6 client to run on Windows 7 and it is Windows 7 that supports Branch Cache.  DFS would be another option here for the file:// (SMB) scenario that should be considered instead of Branch Cache.  Ultimately, it appears that BranchCache support is targeting those few customers using HTTP and HTTPS protocols with App-V.

Keep in mind, that only Windows 7 and Server 2008 R2 hosts support branch cache.  So while this might have the potential of replacing the Application Virtualization Streaming Server from the remote site, you probably cannot do so until you upgrade everything at that site.

App-V “Read only” Cache Mode

Microsoft also added a capability for multiple machines to share a single cache, but only if you plan carefully.  The primary use case is intended to be VDI.   The goal here is to save on storage by having each of the Virtual Desktop operating systems share a single copy of the necessarily large FSD file.  For this to work, we need to ensure that the App-V clients running in the VDI images will not attempt to update the FSD.  When used this way, updating the FSD becomes an offline operation that only needs to happen once.  Microsoft has a White Paper, “How to Configure A Read-Only Cache”, that describes this in detail, but here is the crib sheet version.

In short, you set up a test client that is configured normally.  Then using an administrative account that has access to all of the needed applications, cause them to be fully loaded into the cache.  Copy that cache file (FSD) to the DAS/SAN storag server share (requires shutting down services to unlock the file) and mark it read only.

Now you can configure your App-V client on the Master VDI image to attach to this central app-v cache in read-only mode.  This involves two new registry key settings, one to turn on read-only mode and another for the location of the Error Transaction Logs.  Of course you also need to modify the registry setting for the new location of the cache file.  

In case you are tempted to use this read-only mode in situations other than described for VDI, keep in mind that while having latency between a server streaming content into the FSD is supported, the client expects direct attached storage latencies when reading from the FSD itself.  So placing the FSD on a windows file share might not work out so well for the user.

Windows 7 and Med-V together

Of course, not every application runs in Windows 7.  Enterprises have legacy software that was designed for an operating system many versions back.  To some extent, Microsoft has spoiled us with an awful lot of application backward compatibility.  But some older applications just don’t work (or work as well) on Vista and above, and Microsoft introduced Med-V to help companies move forward without having to abandon these older applications.

When you deploy App-V 4.6 on Windows 7, especially the x64 version of the OS, you might find a mission critical legacy application that not support Windows 7, or is 16-bit, or needs  32-bit device driver.  By installing that app in the Med-V background VM, it can still run and the application “seems” integrated into the Windows 7 desktop experience.  Most of the time, these applications can still be virtualized and run in the background VM, yet appear seamlessly integrated into the host machine.   For those needing the device driver, perform a native install to the background VM.  This combination makes it possible to finally deploy 100% of your applications on a 64-bit Windows 7 machine.  The “stateless desktop” might become a reality.

Win-7 and AppLocker

I previously wrote about App-V integration with Windows 7 AppLocker when the support was added to 4.5 SP1 in the fall.  As far as I can tell, Microsoft has not made any changes affecting this in 4.6.  See the original article for details on integrating these two features.

Using AppLocker, which only works with Windows 7 and Server 2008 R2 with a Domain Controller also running Windows Server 2008 R2, offers complete flexibility to ensure authorized application use.  In 4.5SP1 and 4.6, App-V supports use of AppLocker as a means to control virtual application use. If using AppLocker to ensure who is running which virtual application sounds interesting, Microsoft also has a video showing App-V and AppLocker working together here.