Wuauserv's halt to updating group strategies

[sterobo]

Hello,

A significant number of computers using Waptwua are experiencing a WUA error with the code 0x8024001e : "Operation didn't complete because the service or system was being shut down."

These are most often computers that are up-to-date, haven't been restarted, and where the WUA status should be OK.

It seems that the wuauserv service, which is reactivated and started during WUA tasks, stops and disables itself during these tasks if a Group Policy update occurs, thus causing this error.

Furthermore, it also appears that Wapt itself stops and disables the service during GPO updates (the service status doesn't change if Wapt isn't present).
Since WUA is applied in my case by a configuration package, are there any precautions to take to avoid this behavior?


Wapt v2.6.1.17472

[sterobo]

The same problem appears to be occurring on wapt 2.6.1.17765

[sterobo]

Good morning,

To be more precise, the problem occurs for me in the circumstances I mentioned (updating group strategies during a Waptwua operation)

The error appears to be reproducible in:

• launching a waptwua operation (scan or install)
• running gpupdate on the machine (locally, not via wapt)
• observing the result of the waptwua operation

In parallel, the wuauserv service can be monitored, for example with:

Code: Select all

$currentstatus = $null
$currentstartType = $null
while($true){
    $service = Get-Service -Name wuauserv
    $status = $service.Status
    $startType = $service.StartType
    If(
        $currentstatus -ne $status -or
        $currentstartType -ne $startType
    ){
        Write-Host "$(Get-Date -Format "HH:mm:ss.fff") $startType | $status"
        $currentstatus = $status
        $currentstartType = $startType
    }
    Start-Sleep -Milliseconds 200
}

Updating group policies causes the service to stop and be disabled, and therefore, I suspect, causes error 0x8024001e in waptwua if it is running.
Removing the wapt agent means that a gpupdate has no effect on the wuauserv service.

[sfonteneau]

Hi Steven,

I'm not able to reproduce this problem here with the sequence you mentioned.

If I remember correctly, the wsus GPO is always enabled alongside waptwua.

Can you confirm this? If so, I'm wondering if it's the GPO that's overwriting a wapt configuration and restarting waptwua.

The GPO engine should be saying: "

The value shown here: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer

is not the expected value. I need to reset the GPO value and restart the wua service." That seems most likely to me. -

Simon

[sterobo]

Hi Simon,

Thanks for your reply.
WUServer isn't defined by GPO. Currently, this value (localhost) seems to be defined solely by the WAPT agent.
Some minor WU elements are still defined by policy (active time, for example), and some wapt-get.ini elements are defined by preference.
Could a modification of wapt-get.ini via GPO cause this problem?
I'll run another test without these elements...

[dcardon]

Hi Steven,

When the wapt-get.ini file is modified, the agent reconfigures itself (but doesn't restart) to take the new configuration into account. The reconfiguration should be queued for an event, and it shouldn't interrupt the currently running waptwua application. But looking at the code, it's possible that it's behaving this way... We'll take a closer look.

If disabling the GPO that modifies wapt-get.ini resolves the issue, then we should probably investigate the above possibility.

Best regards,

Denis

[sterobo]

Good catch! After several tests, it does indeed seem to stem from the preference elements in the GPO's INI file.

If a preference element is defined, the wapt-get.ini file is always modified (even if the preference is in update mode), and indeed, I don't observe a restart of the waptservice when the GPOs are refreshed.

And when the preference elements targeting wapt-get.ini are disabled, I can no longer reproduce the problem.

I'll have to find another way to handle the changes to repo_url and wapt_server when objects are moved...

Thank you very much for your help, Simon and Denis!