Configuration Manager 2012 Application Model

System Center Configuration Manager 2012 brought a new delivery method for software: Applications.  Applications bring the intelligence of who\what needs the software from the collection to the Application.  The two main differences between Packages and Applications are detection method and requirements (there are others).  There is also the supersedence feature, and that can technically be covered here as well...but I will leave that to you to figure out.

The main feature I will discuss here is the detection method.  I love this!  The Application does a local check on the machine prior to taking an action.  If it detects the software exists already, it takes no install action; and if the deployment type is uninstall, it only takes an action if it does detect it...all dynamically on the local machine not using possibly old data from software\hardware inventory.

How can I do this with Configuration Manager 2007?

Unfortunately I have still had the need to manage SCCM 2007 environments after being spoiled with this new delivery method in SCCM 2012.  One delivery method that I have been using for years came to mind in the interim: Task Sequences.  What, you say: those are for Operating System Delivery. Yes they are, but they can be used for so much more. They can be used for simple things like initiating a Software Updates cycle with an Install Software Updates task, or they can be used for small or complex application installs that may require a controlled restart between actions: something that packages do not handle well.

--On a quick aside, task sequences are also good for installing applications that include large data source size, as they automatically delete the content on completion.

Conditions

What task sequences bring to the table are conditions (on the Options tab of every task).  These can be set to many things, but the important options for this scenario are file or folder information, registry settings, or even WMI.  These conditions, like Applications, are verified locally on the machines prior to running the specified task.  These conditions allow you to put the intelligence in the Task Sequence instead of in the collection.

--Applications bring the option to deploy to All Workstations; using this type of application deployment does the same as no action will take place unless the condition is true.

Install Example

For the installation of an application, one way (one of many ways) to check to see if an application with a specific version exists is to look at file properties.  To show an example of how to check for two different criteria, we will look for the existence of an x86 version of Java on both x86 or x64 bit operating systems – since the uninstall string should be the same for both.  To do this we need to use an If statement and select Any condition.  At this point, now we select a file condition and browse to both %ProgramFiles% and %ProgramFiles(x86)% and to Java\bin\java.exe, separately.  After selecting each file, we then have the option to only check for its existence, to check for a specific version, or other attributes of the file.  In this case, we want to check for version, as we are getting ready to install a specific version and don’t want to take any action if the application is already installed.  We do this for both file locations.

Uninstall Example

When I uninstall an MSI based application, I generally use the syntax msiexec.exe /x <ProductID> /qn.  So how do I know this command string (uninstall action) is required to be called?  In an Application, I would point straight at the MSI and it detects the ProductID for me.  In 2007, to detect the existence of the application prior to trying to uninstall it, I look for it in the registry:

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<ProductID> or

HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<ProductID>

With this information, you can now use the registry condition to verify the software’s existence prior to uninstalling it.  In this case we can just look for the existence of the registry key prior to taking action.

Summary

This methodology is great for applications that have dependencies or ones that do not uninstall older versions of their software prior to installation of the current version: say Java for instance!  Some people write complex scripts to uninstall older versions, where we can use Queries to find out what versions are installed on our networks, and create a task for each version: see my article on SCCM 2012 Uninstall Applications for more pointers on this.

As I mentioned in my BLUF (which means bottom line up front, btw), the one downside of this method of application delivery is that you cannot target user collections.  Since the feature was created for Operating System Deployment (a computer task), Microsoft did not provide the option to deploy (advertise) Task Sequences to users.  This downside is pretty minor though...

As always....enjoy and keep on automating!!!

Old Software Cleanup

It is not uncommon to have a lot of old software (usually vulnerable to security risks) on your network.  Some applications don’t always uninstall older versions when installing newer versions, so cleaning up this software is important.

An uninstall script is usually a one liner.  Creating Applications in Configuration Manager 2012 for scripts is generally a lot more work than just creating a non-content package to run a one-line script.  Unfortunately you cannot use the supersedence feature of Configuration Manager Applications with packages.  To use the supersedence feature in Applications, you need at minimum two things: Uninstall String, and Detection Method.  With MSI installed applications, one piece of information is required to meet both of these requirements: Product ID or GUID.

Preparations

• Find current versions of software on the network

• Create base MSI application (any will do)

• Create Uninstall applications
  

Finding the software

How do you know if you have more than one version of software on the network?  I use queries (Monitoring->Queries) and usually return Display Name and Version with a query for Installed Applications.Display Name like %<softwareName>%.  To make this process a little easier, I would suggest returning Product ID as well.  This value will return a GUID for MSI installed applications.  As all of us SCCM administrators know, this value is very important when looking for a way to uninstall an application (msiexec.exe /x {GUID} /qn).

I like to have my data in Excel when working with it.  To do this, select one entry from the query results, select Ctrl-a to select all results, select Ctrl-c to copy the data, and select Ctrl-v to paste it into Excel.

Note: If the Product IDs returned are not GUIDs, more research will need to be done to collect the uninstall strings and detection methods for your software.  Uninstall string is usually found in the registry in HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\<ProductID> and HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<ProductID> for x64 systems.  Examples of Detection Methods are file versions or registry settings.

Create Base MSI application

As the requirements indicate, the MSI needed for this step is not important.  Once one MSI application is created (feel free to copy an existing one), there are just a few updates that need to be made to it to make it your base Uninstall Application.

Once you have created the MSI application, open the Properties window of the Application.  Change the name to something like Uninstall Application Template on both the General Information and Application Catalog tabs.  Then open the Properties of the Deployment Type from the Deployment Type tab.  Change the Name of the existing DT to Uninstall <application>.  On the Content tab, delete the contents of the Content location.  On the Programs tab, change the Install program to dummy.msi as this is a required field, but we will not be using it.  Select OK twice to close the Properties windows and save the new application.

Application Creation

Create Uninstall Applications

This base MSI application can now be used to create the applications for uninstall.  All we really need to change in the copied application is the Name for meaning, the Uninstall program for the correct action, and the Detection Rule Clause so that the installed application can be found for action.  I am sure you can change names without instruction, so I will leave this to you.  This is where the spreadsheet comes in nicely; just copy the GUID and get ready to paste in two to three places.  Now all we have to do is create one uninstall application per old application.  The first place to paste the GUID is in the Uninstall program, the second may or may not be the Product code field on the Programs tab (seen it without and with), and the last in the Detection Rule Clause on the Detection Method tab.  Now we are ready to rid ourselves of this old software.

Setup Applications for Uninstall

On the Properties window of the Application, the last tab is Supersedence.  This tab allows you to select an existing application to be superseded and there is a checkbox for Uninstall.  Brilliant!Just enter each of the Uninstall applications, select the checkbox and be done.  You don’t even have to look for what computers need the old application removed.  If the newest application targets a machine that has any version of the application installed, it will install the newest version and uninstall all older versions, per the supersedence rules. I have not verified, but I think that if the newest application is already installed, and the superseded applications are added post, they will still uninstall given the requirements of the application for install.

Summary

The applications that customers have sought most to uninstall are Java and Adobe products as they seem to just hang around; I've even done VLC Player.  This model has proven well to clean up your network.

If you are looking for an even easier way to keep your network clean, AppV 5.0 SP2 has brought an easy way to manage these same type of applications.  My previous blog speaks about this: http://blogs.technet.com/b/christianwb/archive/2014/03/15/configmgr-2012-app-v-5-0-and-internet-explorer-plug-ins.aspx.

As always....enjoy and keep on automating!!!

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!!!