So you have several applications in your environment that get regular updates and your 3rd party software patching program doesn’t include them, or worse yet, you don’t have a 3rd party software patching solution. With a little work, you can setup your own way to target those applications and patch them with minimal work.
I also like doing this, as we install a lot of these applications during OSD, and I like the applications to be on the latest version during time of Deployment. I don’t like having to patch a system right after OSD, feels dirty.
- Create Query Based Collections to Find the software in Question
- Create Generic Query to find software and all Versions of said software
- Create Query for specific version of software
- Create Deployment Collections, Test & Production
- Create Application to Deploy
- Monitor Application (I like to use Ninite.Com, RSS feeds and even Twitter to get notifications)
- Download new version into your Folder Structure
- Copy Previous Application and modify for new Version
- Deploy to Collection
For my Example, I’m going to use WinSCP and NotePad ++
Please look at my previous posts about setting up Applications Deployments for WinSCP & NotePad++ before continuing, they are the building blocks for this post.
Collection Structure
- Software Name (Query that finds all versions of this Software
- Software Current Version (Same as last collection, but add query statement to add version number)
- Software Deploy Test (Collection to Deploy to Computers in Test group that are Not the current version)
- Software Deploy Production (Collection to Deploy to all Computers not on current version)
WinSCP: This Query will find all computers with the WinSCP software installed:
– Installed Applications – Display Name is like %WinSCP%
WinSCP Current: To Create this Collection, Copy the WinSCP Collection and add Version
– Note, WinSCP has the Version number in the actual Display Name, so you only have do modify the Display Name.
WinSCP Deploy Production: This will be a collection of 1 Include and 1 Exclude:
WinSCP Deploy Test: This is identical to Production, but limited to your test group Collection
Now you have your Collections for WinSCP
I’m going to also give you an example for Notepad ++, as it’s slightly different to get the Version Collection:
NotepadPP Collection: Installed Application – Display Name = Notepad++
NotepadPP Current: Copy the NotepadPP collection, go into the Query and Add Installed Applications .Version is equal to 6.8.6 (Or whatever the current version is)
Then do the same for the Test & Production Collections as WinSCP
Now that you have your Collections, lets move on to the Applications
I’m going to build off of the previous posts I’ve created about creating deployments for WinSCP and Notepad++. You’ll need the Source Folder Structure in place already.
Lets start with the Example WinSCP, lets say a new version 5.7.6 was just released. The last version I had deployed was 5.7.3, I would update my collections to reflect the new version numbers, then on the Source Server, I would copy the 5.7.3 folder and rename it to 5.7.6
Copy \ Paste \ Rename
I would then download the new 5.7.6 version and place it in that folder, deleting the old installer version
If you’re using the method I described for WinSCP in my post, at this point your source files are complete, as the script is generalized to work with any .exe in that folder.
Now.. to ConfigMgr Console
Find your WinSCP 5.7.3, right click, Copy, now you’ll have your copy to modify
General Info, modify the Name & Version
Application Catalog, I don’t include the version number, so there is nothing to change
Move to the Deployment Types, and edit the Script Deployment Type you have:
Update the Content Tab: 
Program Tab stays the same, since we’re using scripts:
The only thing you need to worry about is Detection Method.
Since WinSCP has a longer version number for the file, we’ll have to figure that out. The easiest way I found is to simply install it on your test VM, and get the value:
This is also a goodtime to double check the script is working
:
Script worked, and software is installed on the Test VM.
At this point, you can point your detection method at your VM and get the info that way.
As you can see below, the Version Value number has updated
Then if you still have any 32bit machines, you can copy that value into the other detection method:
You can then repeat those steps for Notepad++
Copy the folder structure and replace the installer with the latest version
Copy the application and update it to the current version information
For the Deployment Type’s Detection Rule, I’m using a the DisplayVersion registry value, which make updating the Detection method very easy, as I already know what it’s going to be when I downloaded the new version:
here is the key: SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Notepad++
Now that you have your new Applications, distribute them, and deploy them to your Test Groups.
I typically Deploy it to a user test group first, so it becomes available in the application Catalog, I then use the catalog to update a few test machines manually before pushing, just to do a little quality assurance. I find from time to time I forgot to update the content path, or something silly. So running a test from the Catalog I’ve found to be quite helpful.
You can modify this process to fit your needs, change how you do your collections, etc. You don’t need to exclude the current version, I just like to so I can see the number going down as machines get updated, but it’s not necessary.
I use this process for many of the applications we have in our environment. Whenever possible, I create a installer script, which will work with any MSI or EXE that is in the same folder, for more complicated installs, that doesn’t always work, so you have to remember to modify the script slightly for each version too.
I also look for the easiest way to do a detection method, MSI methods are really nice to, as they are quick to update, just point at the new MSI, and done.
Cleanup – After a version is no longer deployed, I move it into an Archive Folder in the Console, I like to keep them around for awhile before blowing them away completely. I typically keep all of the installers, especially if they are MSI based. I’ve run into issues in the past where a specific version of Flash / Java was installed on a machine and I couldn’t update it. I was able to use the older MSI (same version that was installed on the machine) to fix the corrupt install, then uninstall it so I could install the new version. So yeah, I like to hang on to things. 
I’ll be presenting on this Topic Thursday Dec 10th 2015 at the Government IT Symposium in St. Paul.
Please leave feedback, comments, I’m always looking for ways to improve the process.