Case of the non-offered Windows 10/11 feature upgrade when using Windows Update for Business
I’ve seen this problem with a couple of customers now that is using Windows Update for Business, when some machines were not offered Windows 10 20H1 (May 2020 update a.k.a. version 2004) nor Windows 10 20H2 although no policies should block it. Note: This also applies to Windows 11 feature upgrades.
The new Windows 10 feature update is not offered via Windows Update (for Business) even if you do a manual scan for update. And, no feature update deferrals are configured, nor any specific Windows 10 version set using the “set feature update” to use. Still the new Windows 10 version is not offered which is sort of mysterious!
Good old WindowsUpdate.log comes to the rescue! Get-WindowsUpdateLogs generated the log and then the fun began. To be honest it’s been some time since I last went into this log file, and after browsing some hundred lines of logs something interesting popped up:
which is followed by the data:
E:DchuIntelGrfxExists=1&IsContainerMgrInstalled=1&FlightRing=Retail&TelemetryLevel=1& HidOverGattReg=C%3A%5CWINDOWS%5CSystem32%5CDriverStore%5CFileRepository%5 Chidbthle.inf_amd64_fd8e0a54b983f85c%5CMicrosoft.Bluetooth.Profiles.HidOverGatt.dll& AppVer=10.0.18362.836&IsAutopilotRegistered=1&ProcessorIdentifier=Intel64%20Family%206 %20Model%20142%20Stepping%2012&DchuIntelGrfxVen=32902&OEMModel=Latitude%207200%202-in-1&UpdateOfferedDays=0&ProcessorManufacturer=GenuineIntel&InstallDate=1588155159& OEMModelBaseBoard=0PCKGK&BranchReadinessLevel=CB&DataExpDateEpoch_20H1=1611187200& IsCloudDomainJoined=1&Bios=2020&DeferFeatureUpdatePeriodInDays=0& IsDeviceRetailDemo=0&FlightingBranchName=&OSUILocale=en-GB&DeviceFamily=Windows.Desktop&QUDeadline=2& UpgEx_20H1=Green&WuClientVer=10.0.18362.836&IsFlightingEnabled=0&OSSkuId=4& GStatus_20H1=0&App=WU_OS&CurrentBranch=19h1_release&InstallLanguage=en-GB&DeferQualityUpdatePeriodInDays=0&OEMName_Uncleaned=Dell%20Inc.& InstallationType=Clien
The interesting parts is in DataExpDateEpoch_20H1=1611187200 and if looking up that UNIX timestamp, it appears as though the installation would be performed on January 21, 2021 at midnight.
The variable for DataExpDateEpoch_20H1 or DataExpDateEpoch_20H2 is indicating that the feature update will not be offered until the date is reached.
The evidence is true for a specific model as all of the specific model are blocked with the same timestamp. The problem is seen with multiple vendors, Dell, and Lenovo at least.
The explanation for this behavior is that Microsoft are blocking upgrades due to model, driver of firmware issues. Instead of downloading the entire package, starting the setup, and then finding out of a compatibility issue is not optimal. What is better is to block the feature update from being offered at all and that is (likely) what is going on here.
This is described and can be followed up in detail by using Update Compliance which now holds the SafeGuard information!
As it turns out, it also seems that if whatever underlying problem is fixed on Microsoft’s end, the feature update can be offered before the expiration date occurs.