# Why is package management so convoluted with Ansible and Windows? **URL:** \ **Category:** Ansible Project\ **Tags:** windows\ **Created:** [July 17, 2016, 10:12pm UTC](https://forum.ansible.com/t/why-is-package-management-so-convoluted-with-ansible-and-windows/22036 "2016-07-17T22:12:52Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Bob\_Tanner](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Bob\_Tanner](https://forum.ansible.com/u/Bob_Tanner)\ **Post date:** [July 17, 2016, 10:12pm UTC](https://forum.ansible.com/t/why-is-package-management-so-convoluted-with-ansible-and-windows/22036/1 "2016-07-17T22:12:52Z")
Can someone send me some links about why it’s so convoluted to get Ansible manage of software packages on Windows? Even with all the flavors of package managers on the Linux side of things Ansible does a great job. Moving into the Ansible manage of Windows world things just seem so convoluted. I don’t do much Admin in Windows so I might just be clueless. But I’ve spent hours trying to figure out how to uninstall package (Quicktime in this instance). Is that just the nature of Windows? Windows software packing? Lack of my knowledge? Some answers I would like to get. win\_msi vs win\_package Is this like .deb vs .rpm? If I have a .msi I know that’s win\_msi, but what if I got a .exe? Is that a win\_package install? What if that .exe is self-extracting zip, do I use win\_msi? win\_package? Write tasks to run it (to unzip) and then see if I need to use win\_msi or win\_package? I do not even know what to search for. I’m struggling with the questions to ask. And Google results for “Windows Sucks” aren’t helpful. Any info I can read about this would be helpful. Thanks. ---
**Author:** ![Mike\_Fennemore](https://avatars.discourse-cdn.com/v4/letter/m/45deac/32.png) [@Mike\_Fennemore](https://forum.ansible.com/u/Mike_Fennemore)\ **Post date:** [July 18, 2016, 7:54am UTC](https://forum.ansible.com/t/why-is-package-management-so-convoluted-with-ansible-and-windows/22036/2 "2016-07-18T07:54:32Z")
With regards to package management the win\_msi module seems to have been built purely for msi files whereas win\_package is built with the option of other install files (exe etc). Also the win\_msi module is a core module whereas the win\_package is an extras module developed by the community. As an additional you mentioned package managers for Linux. The rough equivalent for Windows is Chocolatey, which has its own win\_chocolatey module which is version useful for deployment. ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [July 19, 2016, 9:32am UTC](https://forum.ansible.com/t/why-is-package-management-so-convoluted-with-ansible-and-windows/22036/3 "2016-07-19T09:32:43Z")
I have a few ideas about why package management is a pain on windows. The first is that there is an assumption baked into a lot of aspects of windows that there is someone sitting in front of the screen. If you like windows is a ‘workstation operating system’. The computer is right there in front of the user - its the original embodiment of ‘personal computing’. So many installers expect someone to be sitting there hitting Next or answering questions. A fair bit of windows software of course needs licensing too, which is another case where asking the user to provide some information at installation time is (not unreasonably) expected. Another aspect of it is the registry which doesn’t really have a linux equivalent. Its a sort of (hierarchical) database without transaction support (again another manifestation of the there’s-one-user-who-is-sitting-in-front-of-the-machine thinking: why would you need transactions when _the_ user can only really do 1 thing at a time). The registry means you need to use apis to get things fully installed, whereas in the linux world a lot of the time you are just putting files in place (and running things). Doing without the registry I think makes managing packages simpler and more reliable. Uninstallers seem to get less testing than installers so I’ve found removing stuff from windows can be particularly tricky and on occasion I’ve given up trying to use the interfaces around the windows installer service (win\_msi, win\_package and using raw to call msiexec.exe) and removed the files using win\_file and cleaned up the registry using win\_regedit. (java jdk 7 believe it or not). Regarding win\_msi and win\_package, generally I’d recommend trying win\_package first as for the most part it is more capable (handling .exe installers as well as .msi ones, and using the product id for idempotency checking, and can collect remote files from a url to install). In the end, you just have to try things (in a vm you can revert back to a snapshot preferably) in windows as installers are just a lot less standardized. I have some stuff which came in self extracting .exes which I just unzipped and used ‘raw’ to run the installer for (having found the necessary command line switches to make it run unattended / silently). Its not always pretty, but personally I’d much rather have a functioning playbook that lets me reproduce the same installation on whatever machines than waste more time endlessly running windows installers manually. Windows is just fundamentally a different thing I guess. Hope this helps a bit, Jon