I’m new to Ansible and trying to figure out the best way to account for:
If software version of Splunk = 6.4.1 trigger certain task sequence that includes an uninstall of the software
It felt like I needed to grab the uninstall string for Splunk from the registry to use with the win_package module as well as the software version number for Splunk
Also, if Splunk is not installed - trigger another task sequence.
Are there any other modules that could find this information without a deep dive into the registry with win_reg_stat? Some of the programmatic things a colleague and I were doing were extremely entailed and we don’t have a full solution yet. Is there any way to leverage gather_facts?
If it is just one software you want to uninstall use win_package with the product id, e.g.
name: ensure Splunk x.y is uninstalled
win_package:
product_id: ‘{CF2BEA3C-26EA-32F8-AA9B-331F7E34BA97}’ # note this ID will be unique to the Splunk version
state: absent
IIRC correctly Splunk uses an MSI to install so you shouldn’t need any arguments to uninstall but if it is an EXE you need to find out what the uninstall arguments are. The only thing you need is the product ID for the version, this is a once off process and you can find it in the registry, see the documentation for more details http://docs.ansible.com/ansible/latest/win_package_module.html.
There’s actually a few scenarios I need to account for - uninstalling, new installs, and upgrades where I’ll need to know the version of the Splunk software which seems to only be visible in the UninstallString values of the Registry. It’s just such a deep dive into the registry and can get confusing within the role.
I’m going to use win_package and reference the Splunk uninstall string for the uninstall scenario.
Thanks - it’s nice to know there’s some support on the Windows side of Ansible!
No worries, unfortunately package management in Windows is in a pretty poor state as there is no first class manager like yum or apt. Chocolatey is pretty good and I would recommend using it if possible as it abstracts a lot of the information away to the point where you can just mention the package name and what state you want it to be but unfortunately some companies policies are not to trust external repositories.
Every msi installer and most installers (if they are designed properly) will create a key in HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall or HKLM:Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall when on a 64-bit OS and the software is 32-bit. The value of this key is either a guid that is unique to the software and version or in the case of an executable is a string that is unique per software. These paths can be queries for the information you are looking for and the benefit of win_package is that you only need to supply the unique key of the package and in the case of an exe installed package the arguments to run the UninstallString silently.
Unfortunately there are vendors out there who have packaged their software incorrectly and don’t follow this standard and there is not much you can do but to put in some manual workarounds for these.