Good Day,
I am trying to deploy some updates to my test-pc specifically MS18-FEB. The status is failed and when I check the event viewer it says
Windows update could not be installed because of error 2149842999 "" (Command line: ""C:\Windows\system32\wusa.exe" "D:\Windows6.1-KB947821-v34-x64.msu" ")
operating System of the test-pc is windows 7.
Is it possible that the BigFix can determine if the updates is not supported by the processor Architecture anymore?
This answer seems related: https://social.technet.microsoft.com/Forums/windows/en-US/e96201ce-8670-4493-96b3-305b45003c2f/kb2561285-stopped-installing-with-error-2149842967?forum=w7itprosecurity
“The June 2016 patch update 3159398 is superseding or not allowing this Hotfix from installing on Windows 7 computers.”
Could that be the issue?
Not sure why the CPU architecture would be the cause of it not installing, but if it is somehow, then it would be possible to exclude a certain CPU from being applicable to an update, but that seems unlikely to be the issue unless it applies to all Intel CPUs or something odd like that.
Actually, yes, this is a thing. Windows 7 is blocking updates on “the newest silicon” in another bid to force Windows 10 upgrades.
That decimal return code equates to 0x80240037, which brings us to
Quote:
This error occurs because new processor generations require the latest Windows version for support. For example, Windows 10 is the only Windows version that is supported on the following processor generations:
Intel seventh (7th)-generation processors
AMD “Bristol Ridge”
Qualcomm “8996"
Because of how this support policy is implemented, devices that run the following Windows versions and that have a seventh generation or later generation processor may no longer be able to scan or download updates through Windows Update or Microsoft Update:
Windows Server 2012 R2
Windows 8.1
Windows Server 2008 R2
Windows 7
In that case, we may need to come up with relevance to exclude these newer processor generations from being applicable.
CC: @AlanM @dexdexdex
I’d almost rather leave them as-is. If the updates become non-relevant, customers might think they are protected when in fact they are not.
I think leaving the fixlet relevant and failing on deployment is probably the right way to go.
It’s probably worth having a new “Product Unsupported” warning fixlet created though, like there are for XP and 2003 and earlier.
That is an interesting point. It would be possible to have relevance that is only run when the item is deployed as an action that would cause it to not attempt to install, but have it still appear as applicable.
That is a very good idea.
You may have a point on these. But this will leave us management operator confused. because during the deployment , we will get a “Failed” Status after restarting the terminals. Then become relevant the next scanning and leave us on loop.
May we have a fixlet that will check first if the processor is on 7th Gen?