christianwb

System Center and App-V Fun...from an Automator's Point of View

ConfigMgr 2012, App-V 5.0, and Locally Installed Applications

ConfigMgr 2012, App-V 5.0, and Locally Installed Applications

  • Comments 1
  • Likes

Update: Very important change relative to App-V 5.0 SP2

As of App-V 5.0 SP2, most virtual applications that would normally be used as Internet Explorer plug-ins now integrate seamlessly with Internet Explorer.  All that needs to be done is to sequence (or re-sequence) the application with the 5.0 SP2 sequencer and this integration is seamless!  This change pretty much makes the rest of the article obsolete as it relates to IE plug-ins.  If you needed to integrate Adobe Flash or another Office plug-in with an Microsoft Office product, the RunVirtual key mentioned in this article is required and the methodology indicated would be relevant.

BLUF (bottom line up front): Don't forget your Dummy as it is the key to ease of management when your virtual applications are updated often.

System Center Configuration Manager 2012 SP1 introduced the integration of App-V 5.0.  With the introduction of App-V 5.0 came a deeper integration with the physical Operating System and its applications.

Please reference Aaron Parker's article on how to integrate virtual applications with locally installed applications; the portions of the article that are important for us are the Configure RunVirtual section and especially the However comment.

Terminology

In this article Virtual Environments and Connection Groups will be mentioned.  These terms relate to the same thing: Virtual Environment is the ConfigMgr term while Connection Group is the App-V 5.0 client term.

The Dummy!

This application is quite simple and really can be anything.  How I accomplished it was to start the sequencer and initiate a New Package->Add-on or Plug-in->custom installation (doing this prevents the requirement to select an actual installation).  I then opened Windows Explorer (Windows Key + e), created a new folder within C:\Users\Public\Documents called V_Office_Dummy, and within that folder a text file with the same name.  At this point, we are done making any changes to the Dummy application.  Finish the wizard and save the application.  Yes.  That is it.  I don't call it a Dummy for nothin'!

Virtual Environment

Add the Dummy virtual application and distribute\deploy it to the same clients that are getting the Office Plugins. Create a new Virtual Environment (VE) and add all the Office Plugin virtual applications to include the Dummy application.

Note: When you create VEs, you are prompted for a name on creation and then again when you select Add the first time.  It may not be obvious, but when adding multiple applications to the second Add, these applications are combined with OR logic.  By adding multiple applications via the first Add, this changes the logic to AND.  Keep in mind that each client will evaluate whether the VE is required by this logic. If all applications are added by AND logic, they all need to be installed for the Connection Group to be created on the client.  This evaluation is done on each Application Evaluation Cycle, so if one of the AND applications is removed, so will the VE.  This may affect how your plug-ins function, so be careful.

RunVirtual

In order to integrate virtual applications into a locally installed applications, a couple pieces of information are required: PackageID and VersionID of a package in the relevant VE.  The easiest way to get this information is by running a simple PowerShell command: Get-AppVClientPackage. If you forget the command, it is listed in the App-V client console under VIRTUAL APPS in the bottom left hand corner.  Running Get-AppVClientPackage will list all virtual applications and their attributes to include PackageID and VersionID.  If you get an error, make sure to Set-ExecutionPolicy Unrestricted.  The application that has the information we need is the Dummy application.

So why did we create this Dummy application?  To integrate App-V 5.0 applications into locally installed applications, a physical registry key is required on the client (under HKLM:\Software\Microsoft\AppV\Client\RunVirtual).  The name of this key is the name of the locally installed application (word.exe in this case).  The Default value of this key should be PackageID_VersionID of any package within the Virtual Environment.  We create the Dummy application as this application should never have to change.  One of the reasons we are virtualizing applications is so the maintenance of these applications will be less.  If we need to always write an update to the local registry of each client when we install new versions of these plug-ins, this does not minimize the number of applications going to the client; it increases it to one for the application and one for the registry edit.  Using the Package\Version ID information for the Dummy application, this registry entry doesn't ever have to change.

Repeat as Required

Other uses of this methodology include the Adobe Flash Plugin for Adobe Reader, Adobe Acrobat, and all browsers other than Internet Explorer.

Looking forward to hearing feedback on how else you all are using this...

Enjoy, and keep on automating!!!

Comments
  • Great idea!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment