Ansible.windows.win_template stops working after upgrade

So here’s the issue:
I recently installed ansible on redhat linux . This came with ansible.windows 1.8.0. I used an ansible.windows.template to create a simple j2 like this

inputs.j2:
hello = {{ hello_variable }}

This is an ascii text file, which I have confirmed.

This is called from a role, and in the roles’ defaults/main.yml file I set this

main.yml (variables)
hello_variable: “hello world”

When running on 1.8 (ansible 2.11.*, python 3.6) this had no problems. The file was copied to a target host, and the variable was correctly substituted.

However, I updated to match the other system, updating ansible to ansible [core 2.19.3], ansible.windows 1.14, and python 3.11.

When I did this, the file is still being copied. However, the variable is no longer being substituted.

After a day of looking around and getting little help, I actually dove down into the source of the action plugin

            with self._templar.set_temporary_context(searchpath=searchpath, newline_sequence=newline_sequence,
                                                     block_start_string=block_start_string, block_end_string=block_end_string,
                                                     variable_start_string=variable_start_string, variable_end_string=variable_end_string,
                                                     trim_blocks=trim_blocks, lstrip_blocks=lstrip_blocks,
                                                     available_variables=temp_vars):
                resultant = self._templar.do_template(template_data, preserve_trailing_newlines=True, escape_backslashes=False)
                display.vvv(f"BDP Value of tempvars: {temp_vars}")
                display.vvv(f"BDP Value of template data: {template_data}")
                display.vvv(f"BDP Value of resultant: {resultant}")

I can see the hello_variable in the temp_vars, I can see the template data going in as written, but it comes out into resultant unchanged.

What else is interesting is that the other system , which I am matching (same version of ansible.windows, I have a slightly later version of ansible ) , it still runs as it should – it substitutes correctly with this code. But on my current system, it will not substitute the variable despite obviously being able to find it in temp_vars.

So I’m at a loss. Any ideas? Most likely, I’ve done something crazy in my environment and there’s nothing wrong with the template or variable declarations themselves (they do, after all , work on the other machine). I’m trying to figure out how to get it working on my system again; I’ve already tried re-installing ansible and rolling back to the earlier collections but this did not help.

Any suggestions?

Um… I answered my own question. After 12 hours of plugging away I stepped way, doodled on my tablet, then rolled forward to ansible.windows.3.2.0

And it works again.

So for my next trick, I suppose I’ll have to convince the other team to upgrade to 3.2.0 as well.

Sorry for the trouble! I suppose there’s no point in deleting this, though.

Be that as it may, if anyone has some insight as to EXACTLY what went wrong, what the mismatch might be, that could still be useful.

Respectfully,

Brian P.

2.19 introduced a big change in templating which required some fixes to the ansible.windows collection to support. While normally Ansible versions won’t affect too much about the remote execution of PowerShell modules contained in the collection some of the action plugins, like win_template, might have some incompatibilities. The collection does has a minimum version requirement ansible.windows/meta/runtime.yml at 5d33ef1521b4eec1015c3b9ee55698565cae0577 · ansible-collections/ansible.windows · GitHub which does get updated over time. Also official support for newer Ansible releases aren’t guaranteed until the release of that Ansible version.

Thank you. In this case, though, it’s not the minimum version thats’ the issue. I was attempting to use an older version of ansible.windows (1.14.0) against latest ansible (2.19).

The versioning is:

ansible [core 2.19.3]
config file = /etc/ansible/ansible.cfg
configured module search path = [‘/home/bpendell/.ansible/plugins/modules’, ‘/usr/share/ansible/plugins/modules’]
ansible python module location = /home/bpendell/.local/lib/python3.11/site-packages/ansible
ansible collection location = /home/bpendell/.ansible/collections:/usr/share/ansible/collections
executable location = /home/bpendell/.local/bin/ansible
python version = 3.11.13 (main, Aug 28 2025, 03:09:36) [GCC 8.5.0 20210514 (Red Hat 8.5.0-28.0.1)] (/usr/bin/python3.11)
jinja version = 3.1.6
pyyaml version = 6.0.3 (with libyaml v0.2.5)

So the 2.19 you’re speaking of is ansible itself? Is this NOT the released version? When I go to

I see notes on 2.19/ansible 12 but I see no indication this is not the latest released version. That is what “latest” means, does it not?

So the 2.19 you’re speaking of is ansible itself?

Yep, see your ansible [core 2.19.3] in the ansible --version output. That means you are running with Ansible 2.19.3. It is slightly confusing as PyPI has 2 packages, one being ansible and the other ansible-core. For historical reasons ansible is a bundle of Ansible (core) and a bunch of collections and has a different versioning scheme whereas ansible-core is just Ansible itself.

You can find the release versions at Releases and maintenance — Ansible Community Documentation and also how each ansible PyPI version relates to the ansible-core version. Right now 2.19 is the latest and 2.20 is coming soon.

1 Like