Closed thehcma closed 3 years ago
thehcma
commented
3 years ago Fwiw, the same issue is described here:
And the (unsatisfactory) workaround mentioned there (i.e., have an interactive RDP session with the same user) also seems to work for me.
jborean93
commented
3 years ago This HRESULT value represents WU_E_PT_ENDPOINT_UNREACHABLE
There is no route or network connectivity to the endpoint.
The fact that the error indicates it happened when searching for updates would indicate you either have a WSUS server configured and it's not available or it's trying to contact the public Windows Update server and this is restricted in that environment.
Can you share more information about your environment?
thehcma
commented
3 years ago This HRESULT value represents WU_E_PT_ENDPOINT_UNREACHABLE
There is no route or network connectivity to the endpoint.
The fact that the error indicates it happened when searching for updates would indicate you either have a WSUS server configured and it's not available or it's trying to contact the public Windows Update server and this is restricted in that environment.
Can you share more information about your environment?
- Is this a brand new host
No, it is not.
- How is it provisioned
Every instance of this problem I have hit (a few tens so far) is a VM running on a VMWare hypervisor (on prem). All of them are hosts where manually running Windows update works reliably.
- Do you have WSUS set up in your environment
No
- Have you configured any WSUS servers in the registry
No
- Do you have any proxies configured, or should there be
No
A bit more info, if I repeat the operation, it fails consistently.
If prior to running the playbook, I open and RDP session with the host using the same credentials as used by the playbook, the task succeeds and the updates are installed. Obviously, opening an RDP session prior to running the playbook defeats (to some extent) the purpose of using an Ansible playbook to patch the host.
The serverfault link I posted earlier goes into a longer description of the problem and it includes some speculation on what might be behind this.
thehcma
commented
3 years ago This HRESULT value represents WU_E_PT_ENDPOINT_UNREACHABLE
On this, I think the error reported (endpoint unreachable) might be a red herring because, as I mentioned in my prior comment, a subsequent run (while holding an RDP session to the host) makes the task succeed.
jborean93
commented
3 years ago The really hard part with these issues is that we are effectively calling a black box and we are at the mercy of what errors are reported back to us. This particular error happens at https://github.com/ansible-collections/ansible.windows/blob/117dbf7d607b60016c8a3f9b42a88659c0e31d6c/plugins/modules/win_updates.ps1#L109-L115
It's essentially a COMException from the call $searcher.Search("IsInstalled = 0") and the docs for this method is located at https://docs.microsoft.com/en-us/windows/win32/api/wuapi/nf-wuapi-iupdatesearcher-search. There is nothing on that page would indicate why this particular error HRESULT is returned. This is all a black box implementation and we don't have access to the source code behind the COM implementation so we cannot determine why this particular error is reached. The only thing we can try to do is derive the meaning behind this HRESULT based on the header files.
In regards to the speculation on the serverfault page there are a few comments on there so let's go through them one by one
Doh! Associate asked me to verify if it works after logging on...So deploy, login then logout, run the playbook. Sure enough it worked!
Confirms that the workaround you've described also works to fix this problem
Thinking it may be this: docs.microsoft.com/en-us/windows/security/threat-protection/… will update after further testing.
The link talks about Log on as a batch job. All admins should have this but I'm not sure how it's fully related to the problem. The win_updates module uses 2 mechanisms to bypass the network logon problem
ansible_become_user and ansible_become_pass to your own account to run it as an INTERACTIVE logon for that user (this may be a workaround for you)use_scheduled_task: yesThe problem that this tries to fix is that some calls in the WUA COM API will not work for a network logon. It will straight up fail with an access is denied error
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:1
+ $dl = $session.CreateUpdateDownloader()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessExceptionBy either using become or the scheduled task we now run our code in an interactive or batch logon bypassing this arbitrary restriction on the COM side. While maybe these problems are related they are definitely not the same.
I am probably getting the details wrong but this is not a new problem to doing Windows Updates over Powershell. The win_updates module relies on New-Object -ComObject Microsoft.Update.Session; when done over winrm unfortunately Windows filters out the security token needed to make use of this object. Ansible's win_updates is supposed to then use a scheduled task instead. We should look into why yours isn't doing so.
Yep as per my comments above we use 2 different mechanisms for this. But even if that wasn't working I would expect the search to complete normally but error further down in the module. What makes this even more puzzling is that this restriction our code is trying to bypass happens after we search for updates. On a plain vanilla PSRemoting session outside Ansible I am perfectly able to run the following code
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$searcher.Search("IsInstalled = 0") # This is where the module fails for youi have had this issue before. Not sure about a fix but a work around was to configure auto login for the ansible user. Reboot the instance. Run the update, then remove the auto login.
Just another confirmation that creating an interactive logon also works to bypass this problem.
Trying to find more information about this particular HRESULT brings up a few pages but none are really helpful
Ultimately all these issues point to some proxy or bad WSUS configuration but none of those scenarios apply to your situation. It also doesn't explain how creating an interactive logon fixes the problem. At this stage here is what I would try
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$searcher.Search("IsInstalled = 0") - win_updates:
become: yes
become_method: runas
vars:
ansible_become_user: '{{ ansible_user }}'
ansible_become_pass: '{{ ansible_password }}'- win_updates:
use_scheduled_task: yes
nathanealg
commented
3 years ago I have been having this issue for a few months. I stumbled by accident the solution. For me that when ansible connects via ssh or winrm it does not have any winhttp settings or proxy settings and as our internet is behind a proxy the machines do not know how to get to the WSUS/microsoft update sites.
I found that putting a task in to set the winhttp settings (which I believe is global) and putting this command in:
This fixed my issues and I am now able to run windows updates across the estate without issue.
And then when I have finished install updates or definitions I run the following to remove that setting:
This also means I didnt have to configure become or scheduled tasks in my yml file.
I hope this helps.
jborean93
commented
3 years ago @nathanealg thanks for the info, the proxy setup would make a bit more sense as to why an interactive user needed to be logged on first to apply them. As a side note you might be interested in community.windows.win_http_proxy to configure this.
If you are still coming across the issue it would be great if you could confirm that setting use_scheduled_task: yes also works for your environment. Without further info from @thehcma it's hard to track down what might be the problem in their environment.
nathanealg
commented
3 years ago Thanks @jborean93, tested my script with use_scheduled_task and that works fine. Updates applied. All this done via ssh.
The community.win_http_proxy works perfectly as well.
Our WSUS is not on our local network, its hosted externally. Its seems that when behind a proxy it just needs that little tweak to get things working. This makes sense as .net classes webclient does not know about proxy settings and rely on winhttp instead.
Found this: https://www.woshub.com/using-powershell-behind-a-proxy
agibson2
commented
3 years ago Is the user the built-in admin or another local user? If it is a local admin that is not a domain admin or a built-in admin account then winrm usually needs this fix to disable remote restrictions for winrm. I believe a domain admin doesn't need this fix. It requires a reboot.
SUMMARY
The execution of the win_updates task (observed reliably when hitting a Windows 2012 R2 Standard - the same also occurs with Windows 2016 - version 1607) fails as follows:
ISSUE TYPE
COMPONENT NAME
The
win-updatestaskANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
Completion of the task without errors.