Win11 24H2 Failure to Install - Windows 11 Pro - Install Unavailable on Workstation

daniel1

Team,

I have an Automation set-up to install the 24H2 update. It appears that the update downloads and then it also appears that its been triggered to install on reboot. However, after rebooting the computer, it still fails to apply the patch.

There are no error logs and the device does not even attempt to finalize the patch. When looking at the Windows Update page in the System panel it states - a patch is waiting to apply. When pushing the 24H2 patch again manually through Patch Management I am given the option to install the patch. Click it. Within a few minutes the patch is listed as "Installed" and yet the system is still on the prior system version "23…etc".

What am I doing wrong?

Thank you!

dragos.t

Hello @daniel1 ,

Hope you are having a great day.

Based on the description, it does not seem like you are doing something wrong.

I suggest that you open a ticket with our support team so they can investigate the issue on their end.

Contact Customer Support – Atera Support

We also have this article; it might provide you with some help about the issue if you would like to investigate from your end.

Patch Management: troubleshoot general Windows Update errors – Atera Support

The Troubleshoot General Windows Update errors section might offer some insight into the issue and the queries in Microsoft WUA API.

daniel1

@dragos.t I have tried multiple options. Just to add to the discussion: I had a configuration profile set to install after hours (it did not work), I had a configuration profile set to reboot after letting the local user know with a 5 minutes timeout, reboot after one warning, etc (this did not work). I had another configuration profile return the computer to the default windows settings - this device does not have a GPO applied by any other policy/Active Directory - and could then see the option to manually reboot (upon reboot) this patch still did not install correctly.

After returning the device back to its original Configuration policy (after hours reboot) it eventually did install 24h2 successfully. I did try some intermediate troubleshooting steps, including pausing update services, renaming the update folder, in an attempt to rebuild the update history profile - this was not successful at the time. This morning, the machine appeared to have updated overnight as was the goal with the original Configuration profile.

I'm not sure which of the tasks was successful or if the local machine was the culprit all along. I do have other machine in the environment that looks to have a similar issue.

daniel1

@dragos.t It appears that if I switched the "Configuration Profile" around I was able to kick off the update on the local machine. I changed the "Windows Update Settings" section by removing my selection from the "Let Automation Profiles Control…(recommended)" to move back to the less strict "Allow Windows Local Updates". This appears to have allowed the kick-off of the install process with a "Restart" prompt available in the Windows Settings - Windows Update tab.

There is something wrong with the order of operations for the 24H2 update in that it appears there are two different ways to apply it - via the Automation Profile - or manually by selecting the Patch in the Patch Management tool on the Client page. Which is the better or more preferred?

Secondly, the administration of the install of the patch/version update itself having both Windows 11 version update and restart selected in my Automation Profile - did not have the outcome I was expecting. Considering, my default Configuration profile was pretty clear - to my understanding - of when or how a reboot should occur. And what level of notification an end user might require.

dragos.t

Hello @daniel1,

We have checked this further, and it seems there was an issue from WUA API, the channel that we use to install updates.

For some reason, the 24h2 update appears in the Patch Management module, however, it was not possible to install it properly through that method. This would be an issue that appears to be on Microsoft's end.

Regarding your question, "Which is the better or more preferred?"
We recommend using the IT Automation profile option to install this type of patch. Just something to keep in mind is that recently, the settings for the Upgrades task were changed, and now we do not automatically reboot devices. This was done to mitigate the cases where the devices were getting restarted during working hours.

So, if you use an IT Automation profile, the device must get a manual reboot and in some cases, it might require multiple restarts. Additionally, the option "Reboot if needed" does not work with the Upgrade task, only with the "OS Patch Management" task.

Regarding the scenario that you presented, with Config policies, it is difficult to understand what happened without having access to the account.

If you still have issues installing the patch, I do recommend checking with our support team about it.

In case I missed an important part, let me know, and I will gladly respond back,.

daniel1

@dragos.t In the short term I am going to update the clients to use a "Configuration Profile" that put the control back to the local client. (kick of the update manually from the GUI). If we have to do the update manually and cannot rely on the reboot profile to complete the task. That seems like the easiest solution. I suppose we could create another Automation Profile so schedule a reboot the night of the Version Update Automation Profile - to happen sometime that evening - after hours. Just some ideas for anyone who stumbles upon this thread.