While reading one of my feeds I came across this article at bleepingcomputer that Microsoft released microcode updates for Intel processors. Strangely they are not released via WSUS (SUP) and required to be manually installed. Looking in WSUS there are several from January 2020 that is expired. but nothing after. The Update Catalog showed the January ones, as well as May 2020 and the new September ones.
I'm surprised they are not released via WSUS. On all my Linux distros you just install the intel-microcode package or grab the microcode updates from Intel directly. Here is a good article on Windows and microcode updates. With that in mind, I decided to package them up in ConfigMgr for distribution.
I chose to do it via an Application so I can make use of requirements and detection. The first step is to grab all the files and put them into a source folder. I sourced them all from the update catalog per the KB links below. I do not have any 32-Bit or ARM64 however including that architecture should be really easy. Below are the links to the KB articles.
- KB4558130: Intel microcode updates for Windows 10 2004
- KB4497165: Intel microcode updates for Windows 10 1909 and 1903
- KB4494174: Intel microcode updates for Windows 10 1809
- KB4494451: Intel microcode updates for Windows 10 1803
- KB4494452: Intel microcode updates for Windows 10 1709
- KB4494453: Intel microcode updates for Windows 10 1703
- KB4494175: Intel microcode updates for Windows 1607
- KB4494454: Intel microcode updates for Windows 1507
Now just create the Application. I called it 'Microsoft Windows 2020-09 Intel Microcode Update' with a Deployment type for each build of Windows 10. There was no update for 1511. While I do not have all of these builds in this environment I packaged them up anyway just in case one shows up.
The application is pretty normal. I set it to a 60-minute max runtime with estimated at 10. For Software Center, I did grab an Intel icon from an installer executable. For each Deployment type, I set up the first one and copied and changed what was relevant for each build. For the install program I used:
wusa.exe KBARTICLE.msu /quiet /norestart
For example:
wusa.exe windows10.0-kb4494174-v4-x64_65556e377474fa69daaf659936a3a7571cecd94b.msu /quiet /norestart
and (optionally) for the uninstall program I used:
wusa.exe /uninstall /kb:4558130 /quiet
Under the detection method, I used Sarah Lean's method and have a single line PS1. This will need to be specific to each deployment type as it calls out that specific KB.
get-hotfix | Where-Object {$_.HotFixID -match "KBARTICLE"}
I had some fun working on the requirements. This environment has some AMD processors so I didn't want to let it install on those and I did not want to do a custom Collection so I chose to handle this via the requirements within the application for each Deployment type. I did it this way so I can update this application with newer microcode updates as well as add newer builds such as 20H2 (2009?) easily.
Global Conditions to the rescue.
I already had a couple of them set up so just had to figure out how to determine the CPU Vendor. You can find this in the registry at HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\VendorIdentifier. It will list either AMD or Intel. I would assume along with others such as ARM-based however, I do not have any of that currently. For wintel it will show the following:
- AuthenticAMD
- GenuineIntel
For the 'OS Architecture 64-Bit' requirement, this is a global condition as well. You create an expression-based Global Condition and for the clause choose all the 64-Bit OS entries that ConfigMgr knows about. This one needs to be kept up to date as new OS's come out such as Windows Server. I use it for many things in Applications such as calling a 32-Bit or 64-Bit installer based on the Operating System in use.
Finally, for the Windows 10 Build Number requirement, this is also a Global Condition. Like the CPU one, this pulls from the registry. You can get the build number via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentBuild. It will show 18683 for 1909 for example. This will be specific to each build. While I have them memorized you can cross-reference the build to the marketing name via Microsoft or even Wikipedia. Newer builds have a ReleaseID entry however I always use CurrentBuild.
As shown in my Deployment Type screenshot above, the microcode for 1903 also applies to 1909 since they both share common code and 1909 is "upgraded" via an enablement package. So for these two versions, it is not an equals, but a 'one of' operator for its requirement. It could have been done via separate entries.
Now your all set. Just advertise it to a Windows 10 collection. Additionally, you can advertise this to the Windows 10 based servers such as Windows Server 2016 and 2019 since they share code with 1607 and 1809 respectively.
