[RESOLVED] WAPTWUA on 24H2

[sfonteneau]

So, a message for those who might not be reading this:

The Windows Update problems on 24h2 are resolved thanks to this:
https://learn.microsoft.com/en-us/windo ... ber-update

With 24h2, you need to install the kb5048667 cab (the December cab) via a WAPT package:
https://catalog.sf.dl.delivery.mp.micro ... 0c9f93.msu

Note that the Microsoft Windows website is currently still providing the ISO containing the bug because the kb5048667 cab is not integrated...

For those currently on version 2.6, make sure you have the latest version of WAPT 2.6.0.16714 because certain bugs in Windows Update had indeed been identified and are now fixed.

[smandel]

Hello,

despite manually installing the December cumulative update, several workstations remain stuck in WAPT.
The update doesn't appear as installed in the WAPT console, and consequently, no other updates are installing.
I tried uninstalling and reinstalling the WAPT agent, but the result is the same; the KB still appears as uninstalled in the console.
I tried running "sfc /scannow," but without success.
Do you have any idea how to resolve this issue?

Thank you.

[sfonteneau]

Hello

, actually the problem isn't solved.

I have the impression that the copytocache function is broken on a 24h2 server

(https://learn.microsoft.com/en-us/windo ... ledupdates).

It's the cumulative CAB files that are no longer working... (we're working on it).

[sfonteneau]

Good morning

We found a workaround...

The new CAB cumulative update 24h2 has changed. The download URLs now directly provide an MSU file from Microsoft.

This had never happened before.

We were able to perform a quick test. When installing a CAB package, if it contains an MSU file, then we directly run the following command:

Code: Select all

wusa.exe "{msufile}" /quiet /norestart

Rather than using Microsoft's traditional API. We had to guess this because Microsoft hasn't communicated about it.

I'll look into releasing a patch (either as a package or as a single release)

Microsoft KB support recommends installing MSUs via wusa/dism: https://support.microsoft.com/en-us/top ... BD=Catalog

[sfonteneau]

Hello everyone,

Code: Select all

# -*- coding: utf-8 -*-
from setuphelpers import *

def install():
    pass

def audit():
    t = WAPT.waptwua()

    stored_updates = t.stored_updates()
    stored_updates_localstatus = t.stored_updates_localstatus()

    do_install={}

    for u in stored_updates_localstatus:
        if u['allowed']:
            if not u['installed']:
                do_install[u['update_id']]=None

    for u in stored_updates:
        if not u['update_id'] in do_install:
            continue
        kbids = u['kbids'][0]
        for f in u['download_urls']:
            end_filename = f.split('/')[-1]
            if not  str( 'kb' + kbids) in end_filename.lower():
                continue
            if not end_filename.endswith('.msu'):
                continue
            msupath = makepath( WAPT.packages_cache_dir,end_filename)
            print(msupath)
            if isfile(msupath):
                with EnsureWUAUServRunning():
                    run('wusa.exe "{}" /quiet /norestart'.format(msupath), accept_returncodes=[0, 3010, 2359302, -2145124329], timeout=1800)
    return "OK"

I've put together a small package for a quick patch for Windows 11 24h2 machines. The UUP bundle is missing certain .cab files that are normally included, and these files are replaced by .msu files. This is probably related to the fact that the Windows Update engine has been broken several times in recent months (at least the October and November updates), and Microsoft prefers to rely on a separate .msu file to fix everything.

So, when you have an MSU file in the download URLs, you directly launch the wusa.exe command. This deviates from using the Windows Update API, which doesn't normally work with MSU files, but it updates the machine, and the Windows Update engine doesn't seem to be malfunctioning afterward (as has often been the case since the release of version 24h2). However, for MSU files, you need to use wusa.exe or dism.exe, or a cmdlet to integrate this type of file.

I would like an official communication from Microsoft, but well... In fact there is an implication in the announcement of the January 2025 KB [1], but they just say to do it this way, not that it is the only way to do it (you can check that in the announcements of previous versions they did not say this).

We'll see about integrating this patch directly into Wapt

[1] https://support.microsoft.com/en-us/top ... BD=Catalog

[smandel]

Hello,

thank you for the package template!
That helps... but there are still many 24H2 instances where the update installs, but in WAPT it shows as "ERROR" and no other updates install.
I have to create packages for all the updates that won't install...

[sfonteneau]

Hello,

thank you for the package template!
That solves the problem... but there are still many 24H2 instances where the update is installed, but in WAPT it shows as "ERROR" and no other updates install.
I have to create packages for all the updates that won't install...

We have a nightly build which should soon be a release that includes this patch.

However, in some cases the engine really doesn't want to install it... sometimes it works better with DISM directly.
Sometimes you need to install the previous cab...

[smandel]

Hello,

I'm experiencing a strange issue this morning...
All agents are trying to download updates from Windows Update even though they were successfully downloaded from the WAPT server.
The agents are correctly configured not to check Windows Update...

Thank you.

[sfonteneau]

Is the Windows Update service running?

We recently discovered that we need to add additional registry keys:

"DisableDualScan"=1 and
"DoNotConnectToWindowsUpdateInternetLocations"=1.

We are currently working on a project provided by Microsoft called Upsync:
https://github.com/microsoft/update-ser ... c/releases

. Within this project, we noticed the "DualScan" requirement.

We added it to the latest version of WAPT...

[smandel]

The problem seems to continue occurring in 2.6.0.16937...
The Windows Update service is disabled on the machines.