The Best of Two Worlds in App-V

In our latest master level training class on Microsoft App-V 4.5 in Boston last week, Christopher Cawvey asked a question that lead us down an unexpected path; through it we may have discovered a new way to deploy virtual applications to terminal servers and branch office desktops.

In our latest master level training class on Microsoft App-V 4.5 in Boston last week, Christopher Cawvey asked a question that lead us down an unexpected path; through it we may have discovered a new way to deploy virtual applications to terminal servers and  branch office desktops.  In this article, I explain what we found.


With the latest version of Microsoft System Center Application Virtualization (App-V for short) we have three methods to deploy the virtual applications.

  • Use a Dedicated Server to stream virtual applications to clients.
  • Use an SCCM 2007 Sp1 with R2 server to push/stream virtual and non-virtual applications to clients.
  • Use an MSI method to install the app shortcut and deploy the virtual application.


Until 2008 we only had the first option available.  This dedicated server provided the most feature rich deployment model, not only streaming the virtual applications, but centrally assigning applications on a per user basis and reporting on use of virtual applications.   It also has a robust application license enforcement and monitor built in.


 Last winter, Microsoft released a utility that gave us the MSI option.  You could manually run the MSI or use an ESD solution to push it out, but once "virtually installed" you would have the advantages of virtual applications with none of the back end infrastructure.  The disadvantages of this option was that there was no application usage reporting, or licensing, and you lost the ability to assign applications on a per user basis on terminal servers (or shared desktops).


With the App-V 4.5 release, Microsoft also offers SCCM as a deployment model.  Like the MSI option, you loose per user assignments on shared PCs such as Terminal Servers.  You also loose the application usage reporting and licensing, although you might be able to get a view into app usage with a crude form of metering.


Also in 4.5 is the Streaming Server, for use in the dedicated server environment at branch sites.  Branch sites are a problem because of connectivity issues with the main office.  Both available bandwidth and reliability come into play here.  Before the streaming server, either branch office users connected back to the main site for the dedicated virtual application server or a local site copy of the dedicated server was deployed.  In the local case, a site copy of the virtual applications would cut down on bandwidth considerably, but leave a dependency between the local server and the main site Sql Server.  Sql Server replication has never been supported for SoftGrid/App-V.


As mentioned, this new Streaming Server is intended for the Branch Site.  It focuses only on streaming the virtual app to branch clients from a local branch copy.  Application publication still happens from the main site dedicated server, but application use is not recorded and no reporting or licensing is available (but this removes the Sql dependency).


An Unexpected Question

With the client in stand-alone mode for use with virtual application MSIs, or with clients configured for SCCM you do not configure the App-V client to talk to a publishing server.  In fact, Microsoft made it very clear when they released the MSI tool last year that once you configure the client to work with MSIs it will only work with MSIs.


We were testing with the MSI client in the class last week when Christopher Cawvey asked what would happen if we did configure the client to talk to the publishing server.  I told him that Microsoft said it wouldn't work.  But then I thought about it some more, and decided that we should test it and find out.  That is one feature of our class that I love -- we can go off the planned track when someone has an interest to learn more!


But first, why would someone want to do this?  Simple.  If you use MSIs, or SCCM, you loose two important features.  The first is per-user application publishing, which you need for terminal servers.  The second is reporting/licensing. 


Now Chris has  terminal servers with Citrix at branch office sites, and today these users connect to the dedicated server back at the main site.  He  uses a script to ensure that the virtual application cache remains full on these branch-site terminal servers.  And Chris cares very much about application usage reporting and licensing at the branch office site.  When he upgrades to 4.5, he might use the streaming  server at the remote site (when he upgrades to the 4.5 release), but he has an SCCM implementation so he has other options.  His SCCM implementation isn't R2 and probably won't be soon, so using SCCM to stream isn't an option.  But using SCCM to deploy MSIs to the branch site to fill the cache is a possibility, if he can get the features he needs. 


I was also interested in the MSI option for native terminal servers where desktops were shown.  But I figured that maybe we could use the MSI with no start menu or desktop shortcuts, to add the virtual application and fill the cache, then try to use the dedicated server to perform per-user application publishing.


The diagram below shows the two options that we were thinking about.  In both cases, we sequence the application and store on a file server share (the "content" folder).  In one case, we publish the virtual applciation without shortcuts via SCCM R2.  In the other case, we install the virtual applciaiton on the client using the MSI (which could have been pushed out using any version of SCCM, or SMS, or another ESD solution).  In either case, we use the Dedicated App-V server to publish shortcuts on a per-user basis and collect usage information and enforce licensing.  Because CHris would not use SCCM R2 to stream virtual applciations, we chose to test the MSI case. 



An Unexpected Result

First, we set up a Citrix XenApp server in the lab and demonstrated how to publish the App-V application shortcuts to Citrix users using Web Interface.    Coming into the class this had been a problem in getting this right in Chris's environment.  Chris was OK with the idea of all the applications being technically available on the Citrix server but limiting access by using the Web Interface to publish only certain shortcuts to certain users.  None of his Citrix users get a full desktop on the server, so they should not even know the apps are on the server.


Next, we set up an App-V Client to be  configured for stand-alone operation.  We installed a virtual application on the box using the virtual application MSI.  , one with no shortcuts published to the start menu or desktop using the application MSI.  When I say no shortcuts, I mean that when the application was sequenced, application OSDs were created but no shortcuts with icons were published to the Desktop or Start Menu.  Then, we added the main-site dedicated server as a publishing server.  In the dedicated App-V server, we published the same application but added in the missing shortcut to the start menu in the App-V Management Console while importing.


My expectation was that when I logged into the client, it would probably contact the App-V dedicated server and download the shortcut.  And that is exactly what happened.  But my expectation was that since the client was configured to not require authorization that when we tried to run the application it would just run it locally and never contact the server, or possibly not run at all.  But I was mistaken!  The client did contact the server.  The virtual application ran correctly.  And the usage was logged.  I verified the usage by running the application usage report on the following day. 


Moreover, we decided to try an active upgrade.  We created a new version, published on the App-V dedicated server, but did not try to run the MSI  (you cannot do upgrade using the MSI, you have to uninstall and install -- so the user would loose their preferences).  When we ran the application again after adding the new version to the App-V dedicated server, the user received the upgrade and kept their application preferences.  This setup is shown in the diagram below.


More Testing Needed

We still need to test this some more, but it looks very promising.  We have not yet verified that the licensing module of the Dedicated App-V server works in this mode - but I have every expectation that it will.  I also want to test the same concept using SCCM to push out the application initially but use the dedicated server for shortcut publishing to users, application usage reporting, and licensing.


But I am intrigued.  I had been playing around with ideas to develop a shortcut publisher for terminal servers with App-V clients configured for either MSI or SCCM streaming, but it is looking very much like we have the tools necessary right in the product if we configure differently than Microsoft advises.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I have done some additional testing, after being spurred on by Microsoft's Brian Kelly.

First, I now understand more about how Microsoft changed application usage reporting in the 4.5 release.  Prior to 4.5, application usage was recorded in the database based upon the client making the RTSP(S) request to open the package application and quit it (technically, "PLAY" and "CLOSE")..  In 4.5 Microsoft changed this to allow the client to store application usage locally and report it upon next connection.  I had been assuming that the implementation used this information to enhance the info the already had, but it turns out it replaces it.  

This explains why in 4.5, application usage reports don't show recent application usage.  Even though the server saw the RTSP messages to play and close, those are no longer used to write the usage info to the database.  Instead, the client must perform a publishing refresh.  By default this happens upon logon and once a day afterwords.  this explains why we find reports usually don't have info for the last day.

Also, I tested both user assignment and licensing for the MSI deployed apps on my test client that also had a publishing record added.  I found that both App-V Server user assignments, and licensing is enforced.  Even though the client is configured with “require authorization even if cached” disabled,  I get “You are not authorized to use this resource” message on the client if the user is not assigned in the App-V Management Server.  Similarly, if I enable licensing on the App-V server I have to have a user license on the client.  It is not (yet) clear to me if this is a feature or a bug as I no longer understand what the “require authorization even if cached” = 0 setting really does!

I am convinced we can better deploy the branch site using these combinations, but await more confirmation from Microsoft to make sure we are not depending on a bug rather than a feature.



I would be really interested to hear the outcome of this.  We are migrating to R2 but have been speaking to Microsoft about some of the limitations of the SCCM/App-V integration.  I did ask whether we could use a dual infrastructure and have a R2/App-V client receiving apps from SCCM as well as performing DC refresh against a management server.  I haven't tried it but was told it wouldn't work...


I have not yet gotten to trying SCCM to stream and adding in the publishing server (but hope to).  That would be a more complicated situation.  

SCCM pushing the MSI and using the App-V Server for publishing would be the same as what I have been testing so far.

I'll add a comment as things move on.



I was struggling the require authorization if cached key also and I figured out the following.

Set to 0 (FALSE) the client will allways try to connect to the server. If a connection to the server cannot be established, the client still allows the user to launch an application that has previously been loaded into cache.


I ran into this when I setup the client in "standalone mode" but there was a server in the OSD which was reachable and the application wouldn't start!


I think, it's high time you updated your post with some fresh info. I am sure you have a lot of things to share!