Tips for Detection Method?

[Kops]

I am looking to improve my skills in the detection method area for deploying our standard applications (SQL server, Visual Studio, Chrome, Office products, etc). Currently my approach is to install the application, sort of poke around in /programfiles directory and look for a file that looks related to the application. Then, I'll uninstall the application and see if that file still exists.

 

Seems to me like there must be a better way, what works for you?

[shawn]

What I like to do is to install the application and then go to "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" in the registry and see if there is an entry for the windows installer code for the application. If there is you can use that for the detection method. Click on each key and look for the DisplayName entry to match to your application name. Also make sure to check Wow6432Node if it's a 64 bit system.

 

When you find your application copy the entire key name and use that for the detection method. So your detection method might be {26BFF1F1-5C03-4C55-9C7C-FD65889AFA70}. In the detection rule settings, choose Windows Installer.

 

Not all applications use this especially if they are an exe based installer but i've found that most do.

 

If there is an easier way than this I would like to know also.

 

Thanks,

 

Shawn

[wilbywilson]

Well, if you use the MSI (when available), it should create its own detection method when you're going through the application build wizard. If you're building an application from an EXE file, then you'll need to create your own method. In those cases, I generally try to detect the presence of the main .exe (chrome.exe for instance), and the file version for that particular release. That way, you can be sure it's detecting the exact Chrome version that you're trying to deploy, and not some potential old/outdated chrome file. And if you uninstall the program, that .exe should definitely be removed from the machine.

 

That seems to be working pretty well for me. I did run into one instance where I had an x86 and x64 version of an app, and the main .exe for that program ended up in the same path on the end user machine, regardless if it was an x86 or x64 machine. Of course, that detection rule didn't work so great, since it though the clients had both the x86 and x64 version of the software installed. In that case, I added a second piece to each detection rule, where it looked for a text file that was specific to the x86 application, and likewise for the x64 application.

[Peter33]

I am usually just running a simple powershell command to ge the Product ID which will be the SoftwareCode property in the output.

gwmi -namespace root\cimv2\sms -class sms_installedsoftware -filter "productname like '%part of the name here%'"

If there is no valid value in the Softwarecode property, for example when the Setup is a freeware installer like "Inno Setup" (PDFmaker etc.), go for the registry like Shawn mentioned it and chose the DisplayVersion property. In your detection rule (registry) make sure to use "Version" instead of "string" and "greater than or equal to" instead of "equal". This will save you some trouble when you are using "supersedence" while testing the new applications.

[Kops]

Thanks for the responses guys, seems that everyone has a bit of a different method. I was mainly referring to .EXE installers, as the .MSI ones are pretty straight forward. This came about as I was looking to do this for a SQL Server 2012 deployment, but am interested for other apps too.

 

I looked around in the registry as Shawn suggested - and was able to find some value here, especially for some other more simple applications we deploy. The difficulty with SQL is there there are multiple entries for SQL Distributed Replay, Database Engine Services, Data Quality Services, etc... I am guessing that I can key off any of these as a detection method, so I will try this

 

Wilbywilson seems to be taking the same approach I am currently, I am guessing this is a fairly common method as well.

 

Peter33 has an interesting suggestion. I am very interested in using Powershell as much as I can, I think its a great language that all systems admins should know and am trying to use it as often as I can. I ran this command looking for Chrome (see attached for sample output) and a few other apps and it worked great! With SQL, as with the registry method, there were TONS of entries. I am guessing that any of these could work, but will require some testing.

 

Thanks again for the input