Alternative to win_msi

[Tai Kedzierski]

Hello

I am wanting to start maintaining a group of Windows hosts that badly need orchestration. One task is to update Java (major version) on all of them

I have found the `win_msi` module , but scrolling down I find that it is listed as deprecated - not only that, but the further explanation seems to have been clipped (incomplete pargraph)

http://docs.ansible.com/ansible/win_msi_module.html

I note though that the main list does not list it as deprecated (not marked with "D:")

http://docs.ansible.com/ansible/list_of_windows_modules.html

So my questions are:

• truly, is it deprecated and advised against?
• and if so, what is the new, recommended way to update Java on a bunch of Windows hosts ?

Thanking you

Tai

[J Hawkesworth]

I would recommend using win_package - that's what I use to maintain java versions in our playbooks.

For info, recent java versions like to upgrade themselves.  While this is laudable it may cause unexpected behaviours as clusters start running different java versions.  So I would strongly recommend checking the command line options for the java installer you are using.  Below are the command line arguments that we use on some systems:

    arguments: INSTALL_SILENT=1 AUTO_UPDATE=0 WEB_JAVA=0 WEB_ANALYTICS=0 /s /L C:\ansible\log\java-installation.log
# added install options based on options here: http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#table_config_file_options

Hope this helps,

Jon

[Jordan Borean]

There were plans to deprecate win_msi in the 2.3 release in favour of win_package but win_package was never hardened as a core module so it never became official. That being said win_package is the recommended of the 2 but there have been a few cases where I still favour win_msi over win_package due to the temperamental requirement over whether you need to specify a product is for some packages or not.

[Tai Kedzierski]

Thanks Jon

I'm inheriting these systems and not accustomed to Windows so the added notes are very welcome. I am surprised at the notion that systems set up with the same Java installer were to not remain generally in sync version-wise (or is this just a question of timing ?). But I guess that's why we find the need to orchestrate!

[Dag Wieers]

On Wed, 19 Apr 2017, Jordan Borean wrote:

> There were plans to deprecate win_msi in the 2.3 release in favour of win_package but win_package was never hardened as a core module so it never became official. That being said win_package is the recommended of the 2 but there have been a few cases where I still favour win_msi over win_package due to the temperamental requirement over whether you need to specify a product is for some packages or not.

Yes, and for that reason I don't think we're quite ready to deprecate
win_msi for v2.4.

I know we really want to, but win_package needs to be shipped with a
release and working for all use-cases, before we can start deprecating
win_msi IMO.

Or you risk ending up with a broken alternative, and the deprecated
option people were using.

--
Dag

[Dag Wieers]

On Wed, 19 Apr 2017, 'J Hawkesworth' via Ansible Project wrote:

> I would recommend using win_package - that's what I use to maintain java
> versions in our playbooks.
>
> For info, recent java versions like to upgrade themselves. While this is
> laudable it may cause unexpected behaviours as clusters start running
> different java versions. So I would strongly recommend checking the
> command line options for the java installer you are using. Below are the
> command line arguments that we use on some systems:
>
> arguments: INSTALL_SILENT=1 AUTO_UPDATE=0 WEB_JAVA=0 WEB_ANALYTICS=0 /s
> /L C:\ansible\log\java-installation.log
> # added install options based on options here:
> http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#table_config_file_options

Jon,

I think that example deserves to be part of the win_package documentation.

To draw the attention to a common issue, and to showcase using win_package
for Java installation, a common thing people tend to do :-)

Examples like this greatly improves the user-experience of the
documentation, and to a greater extent, Ansible.


Everyone else,

We do accept improvements to the documentation, so if you come across a
nice solution with the potential of being a great example to others, feel
free to edit the documentation (through the website, or GitHub). No prior
knowledge of git or internal processes required.


--
Dag