win_updates "state: searched" option does actually install updates

[anasaizg]

SUMMARY

win_updates module has the option to just search for updates and not install them. However, when used, the server actually updates and reboots.

ISSUE TYPE

• Bug Report

COMPONENT NAME

win_updates

ANSIBLE VERSION

ansible 2.10.14
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/my-envs/venv-windows/lib64/python3.6/site-packages/ansible
  executable location = /opt/my-envs/venv-windows/bin/ansible
  python version = 3.6.8 (default, Nov 18 2021, 10:07:16) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44.0.3)]

COLLECTION VERSION

Collection      Version
--------------- -------
ansible.windows 1.11.1

CONFIGURATION

OS / ENVIRONMENT

Target OS: Microsoft Windows Server 2016 Standard
Powershell version: 5
Connection Type: PSRP

STEPS TO REPRODUCE

- name: Windows updates - log to {{ansible_log}}
  ansible.windows.win_updates:
    category_names: "{{ category_updates |default('*') }}"
    state: searched
    log_path: "{{ ansible_log }}"
    reboot: yes
    reboot_timeout: 3600
  register: win_updates_result
  ignore_errors: yes

- debug:
    var: win_updates_result

EXPECTED RESULTS

Server looks for available updates and shows them. It does not update.

ACTUAL RESULTS

Server is updated and rebooted.

Thanks!

[jborean93]

Hmm this is alarming but I'm unsure how it is happening. We do an explicit check for $state -eq 'searched' here

ansible.windows/plugins/modules/win_updates.ps1

Lines 1392 to 1395 in 43cf617

	elseif ($State -eq 'searched') {
	$api.WriteLog("Search mode: exiting...")
	$exit = $true
	}

. It will exit early if searched before getting to the code to download then install the updates. Can you share your ansible_log for a run where this happens?

[anasaizg]

Hi Jordan

I attach a log of the task here win_updates.txt

There we can see it begins the reboot:

ansible.windows.win_updates: command result - rc: 0, stdout: 133105152494889840, stderr: 
ansible.windows.win_updates: last boot time: 133105152494889840
ansible.windows.win_updates: pre-reboot boot time check success
ansible.windows.win_updates: saving original connection_timeout of 600
ansible.windows.win_updates: rebooting server...
ansible.windows.win_updates: running command: $ErrorActionPreference = 'Continue'

if ($True) {
    Remove-Item -LiteralPath 'HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\AutoLogonChecked' -Force -ErrorAction SilentlyContinue
}

$stdout = $null
$stderr = . { shutdown.exe /r /t 2 /c 'Reboot initiated by Ansible' | Set-Variable stdout } 2>&1 | ForEach-Object ToString

ConvertTo-Json -Compress -InputObject @{
    stdout = (@($stdout) -join "`n")
    stderr = (@($stderr) -join "`n")
    rc = $LASTEXITCODE
}
<servername> PSRP: EXEC Set-StrictMode -Version Latest
$ErrorActionPreference = 'Continue'
if ($True) {
Remove-Item -LiteralPath 'HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\AutoLogonChecked' -Force -ErrorAction SilentlyContinue
}
$stdout = $null
$stderr = . { shutdown.exe /r /t 2 /c 'Reboot initiated by Ansible' | Set-Variable stdout } 2>&1 | ForEach-Object ToString
ConvertTo-Json -Compress -InputObject @{
stdout = (@($stdout) -join "`n")
stderr = (@($stderr) -join "`n")
rc = $LASTEXITCODE
}
If (-not $?) { If (Get-Variable LASTEXITCODE -ErrorAction SilentlyContinue) { exit $LASTEXITCODE } Else { exit 1 } }

At the end the result is:

changed: [servername] => {
    "changed": true,
    "failed_update_count": 0,
    "filtered_updates": {},
    "found_update_count": 0,
    "installed_update_count": 0,
    "invocation": {
        "module_args": {
            "accept_list": null,
            "category_names": [
                "*"
            ],


            "log_path": "C:/Temp/ansible-windows-update-servername-2022-10-26.log",
            "reboot": true,
            "reboot_timeout": 3600,
            "reject_list": null,
            "server_selection": "default",
            "skip_optional": false,
            "state": "searched",
            "use_scheduled_task": false
        }
    },
    "reboot_required": false,
    "updates": {}
}

It seems weird that it reboots even if the result is reboot_required: false. Could it be related to the invocation having a reboot: true that could override state: searched?

[nitzmahone]

Grr, state: searched...

At a glance it looks like the action needs an early bailout in the case of state: searched - I concur with Jordan that it's probably not actually installing updates, but because one of the updates says it needs a reboot and we don't bail out of the loop early, it thinks it needs one. It looks like check_mode properly prevents the reboot here, but it looks like we need to also check for state: searched there as well (or imply check_mode when state: searched?).

[jborean93]

Looking at your output it seems like the current problem here is caused by 2 different issues (which have been fixed). The first run the win_updates task failed with

PSRP STDOUT: {"task":"exit","result":{"action":null,"exception":{"message":"Surcharge introuvable pour « WriteLog » et le nombre d\u0027arguments « 5 ».","exception":"Surcharge introuvable pour « WriteLog » et le nombre d\u0027arguments « 5 ».\r\nAu caractère Ligne:772 : 13\r\n+ $api.WriteLog(\"Search warning {0} - Context {1} - HResult ...\r\n+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n + CategoryInfo : NotSpecified: (:) [], MethodException\r\n + FullyQualifiedErrorId : MethodCountCouldNotFindBest\r\n \r\n\r\n\r\nà \u003cScriptBlock\u003e, \u003cAucun fichier\u003e : ligne 772"},"reboot_required":false,"failed":true,"changed":false}}\r

This is the issue #411 which has been fixed by #414. On a failure the win_updates action plugin will do a reboot to try and get right of some bad states on the WIndows Update API before trying again.

On the 2nd round after the reboot it is failing to find the temporary path created by the action plugin which due to your host's use of TEMP profiles is the issue #417. This has been fixed with #422.

So by upgrading your ansible.windows to 1.12.0 you'll get these two fixes and hopefully things will go through smoothly. Now as to why it's rebooting with state: searched this isn't a bug per say. A reboot will occur in 2 scenarios:

• The module returned reboot_required
• There was a failure in the module - only happens for 1 cycle though a 2nd failure will do another reboot

Both times the action plugin will kick off a reboot, but only when reboot: true has been set and not in check mode. Because you did set reboot: true then it's going to reboot on the failure. So if you don't want a reboot to ever occur best not set reboot or be explicit and state reboot: false.

Now there is still a bug here, the 2nd failure around the temp folder should have cause an error and get returned back to the caller so they know what the problem actually was. I'll need to look into that a bit more to see what I can find out. Updating the docs around the reboot option is also a good idea to clarify when a reboot can happen.

TLDR: the immediate issue has been fixed and is in the ansible.windows 1.12.0 release.

[anasaizg]

Thanks Jordan and Matt, we updated the collection yesterday so I hope it will solve most of the issues we have. I will also make sure we don't have a reboot: true when state: searched