# Querying Registry and Using Output

**URL:** <https://forum.ansible.com/t/querying-registry-and-using-output/26305>\
**Category:** Ansible Project\
**Created:** [December 15, 2017, 4:43pm UTC](https://forum.ansible.com/t/querying-registry-and-using-output/26305 "2017-12-15T16:43:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Heather\_Luna](https://avatars.discourse-cdn.com/v4/letter/h/5e9695/32.png) [@Heather\_Luna](https://forum.ansible.com/u/Heather_Luna)\
**Post date:** [December 15, 2017, 4:43pm UTC](https://forum.ansible.com/t/querying-registry-and-using-output/26305/1 "2017-12-15T16:43:55Z")

</div>

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?

Thank you

---

<div class="post-metadata">

**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\
**Post date:** [December 16, 2017, 12:55am UTC](https://forum.ansible.com/t/querying-registry-and-using-output/26305/2 "2017-12-16T00:55:55Z")

</div>

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](http://docs.ansible.com/ansible/latest/win_package_module.html).

Thanks

Jordan

---

<div class="post-metadata">

**Author:** ![Heather\_Luna](https://avatars.discourse-cdn.com/v4/letter/h/5e9695/32.png) [@Heather\_Luna](https://forum.ansible.com/u/Heather_Luna)\
**Post date:** [December 17, 2017, 6:00am UTC](https://forum.ansible.com/t/querying-registry-and-using-output/26305/3 "2017-12-17T06:00:27Z")

</div>

Hey Jordan,

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!

Heather

---

<div class="post-metadata">

**Author:** ![jborean](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jborean/32/1525_2.png) [@jborean](https://forum.ansible.com/u/jborean)\
**Post date:** [December 17, 2017, 8:46pm UTC](https://forum.ansible.com/t/querying-registry-and-using-output/26305/4 "2017-12-17T20:46:26Z")

</div>

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.

Thanks

Jordan
