Tranquil IT Forum

Hello everyone,

Context:
WAPT version: 2.1 Enterprise
Server OS: Debian 11
Administration console OS: Win10pro
Package development workstation OS: Win10pro

We have some users who rarely shut down their workstations and therefore don't receive the necessary Windows updates.

We would like Windows updates to install automatically as soon as the workstation is online (Windows updates without restarting) at a set frequency, rather than when the workstation is shut down.

To do this, we configured a WAPT agent as follows:
[waptwua]
enabled=true
default_allow=true
install_at_shutdown=false
install_delay=7d
install_scheduling = 1d
download_scheduling = 1d

Updates appear as pending (although some had a DISCARDED status despite the default_allow=true parameter) but do not seem to install according to the declared frequency (they remain in pending status, despite a manual restart of the machine 3 weeks later to allow the full 7-day delay to pass).

Normally, this configuration will scan for updates daily, install the necessary updates daily (which should all be in pending status due to default_allow=true), allowing a 7-day delay after the update is published. Is that correct, or am I misunderstanding something?

What are the main risk categories (see WAPT documentation) associated with using the `install_scheduling = 1d` parameter, for example, if the user shuts down their computer while a pending Windows update is installing?

Basically, what would you recommend for a secure installation of Windows updates that doesn't depend on a computer restart, and in a way that is as transparent and automatic as possible (ideally, we wouldn't want to intervene in the WAPT console to apply Windows updates to computers)?


Windows updates via WUA when the computer shuts down take some time (in this regard, a percentage of these updates completed would make users less inclined to abruptly shut down their computers on Friday nights! (although this depends on various factors (operator pairing, reverse-proxy bandwidth, etc.)).

Does WUA support abrupt shutdowns (I think this must happen ) and allow for a clean restart?


Sincerely,

CR

In your case, `install_scheduling` seems the most suitable.
It's not recommended because installing updates during the day consumes CPU, which can be problematic for a user who's working and has a slow computer. However, if this isn't an issue for you, then no worries.

Otherwise, it will be problematic. (Note that the user will still need to restart their computer to complete the update correctly).

On the other hand, if you use `install_scheduling`, there's no need to use `download_scheduling` since `install_scheduling` performs a scan.

Regarding abrupt shutdowns, if WaptExit detects a Windows update in progress, it will stop the computer from shutting down to complete the update.
However, if a user suddenly shuts down their computer, then we obviously can't guarantee anything...

As for calculating the time, it's possible but difficult to implement because, as you mentioned, there are many parameters to consider.

Regarding the persistent DISCARDED status, it's strange; was the date correct?

Good morning,

My apologies for the late reply.
I have a test machine that remains powered on (W10 Virtual Machine) with the following WUA settings:

enabled=true
default_allow=true
install_at_shutdown=false
install_scheduling = 2h

The directive install_scheduling = 2h does not appear to be honored because:
- no trace of a scan command in the client's waptservice.log log file
- in the WAPT administration console, the date of the last scan is 2022-07-06T12:06:18.064877 and that of the last wsusscn2.cab file on the client is 2022-04-11T22:46:16, while the date of the last wsusscn2.cab file on the server is: 2022-07-12T12:28:21 (see attached file: wapt_wua_not_launched.png).

Do you have any leads to investigate the cause of the failure to trigger?

On the other hand, if a Windows update is in progress, and the user closes their session and/or shuts down their laptop and puts it to sleep, does the update in progress resume where it left off when it went to sleep?

sfonteneau wrote: ↑June 7, 2022 - 10:25 AM In your case, install_scheduling seems the most suitable.
It's not recommended because installing updates during the day consumes CPU, which can be problematic for a working user who has a slow computer. But if that's not an issue for you, no worries.

Otherwise, it will be problematic. (Note that the user will still need to restart their computer to complete the update correctly).

However, if you use install_scheduling, there's no need to use download_scheduling since install_scheduling performs a scan.

Regarding the abrupt shutdown, if waptexit detects a Windows update in progress, it will stop the computer from shutting down to complete the update.
However, if a user abruptly shuts down their workstation, then obviously we can't guarantee anything...

As for calculating the time, it's possible but difficult to implement because, as you mentioned, there are many parameters to consider.

Regarding the persistent DISCARDED statuses, we should look into it; it's strange. Was the date correct?

Hello,

Following your message last time, I looked at the code and indeed, the scan is mandatory for it to work, which wasn't very logical.

Basically, the installation only started if the previous status was pending, but if a scan wasn't run, it would never be pending.

In the latest version (wapt-2.2.2.12388-10e35aa7), I removed this, so the scan is no longer necessary since the installer will run a scan.

Could you update to see if it's better?

Simon

Hello Simon,

I will (normally) do the update tomorrow afternoon, I will check the behavior and give you feedback.

However, if a Windows update is in progress, and the user logs off and/or shuts down their laptop and puts it to sleep, does the update resume where it left off when it went to sleep? (I know, I'm being persistent, but there are always some users in a real hurry.) who are going to do it)?

Christophe.

sfonteneau wrote: ↑August 1, 2022 - 11:07 AM Hello

, Following your message last time, I looked at the code and indeed, the scan is mandatory for it to work, which wasn't very logical.

Basically, the installation only started if the previous status was pending, but if you didn't run a scan, it would never be pending.

In the latest version (wapt-2.2.2.12388-10e35aa7), I removed this, so the scan is no longer necessary since the installer will run a scan.

Could you update to see if it's better?

Simon

Hello,

After updating (to version 2.2.2), the scan and installation now run correctly at the desired frequency, thank you.
I still need to test the behavior when resuming from sleep mode (e.g., when a laptop is shut down) while installing a Windows update.

Regards.

croquebert wrote: ↑August 3, 2022 - 2:52 PM It remains to be tested the behavior on resumption when a PC has gone into sleep mode (portable closure...) while it is installing a Windows update.

Good morning

The answer is tricky, wapt asks the windows update service to install the cab (technically wapt does not launch the installation, it launches windows update and asks it to launch the installation.

So, the behavior in this case... upon restarting, I think everything will continue, but it needs to be tested.

Simon

Hello Simon,

Thanks for the feedback. I also think there's been a resumption of service, but I'll check it out sometime.
How do I edit the topic to mark it as resolved?

Sincerely.

sfonteneau wrote: ↑August 3, 2022 - 5:44 PM

croquebert wrote: ↑August 3, 2022 - 2:52 PM It remains to be tested the behavior on resumption when a PC has gone into sleep mode (portable closure...) while it is installing a Windows update.

Good morning

The answer is tricky, wapt asks the windows update service to install the cab (technically wapt does not launch the installation, it launches windows update and asks it to launch the installation.

So, the behavior in this case... upon restarting, I think everything will continue, but it needs to be tested.

Simon