During our recent Windows 10 feature update deployment from 1809 to 20H2, we ran in to an issue on some clients where they reported back error 0XC190012E to ConfigMgr.

The error code its self is just a generic code and I couldn’t find it in either

Windows update error code list

Windows Update error code list by component – Windows Deployment | Microsoft Docs

or the Windows 10 upgrade errors doc

Get help with Windows 10 upgrade and installation errors (microsoft.com)

We first checked the temporary location that feature update deploys to c:\$Windows.~BT, to check if there was any issue in the compatibility xml file or in the setup logs under sources\panther, but there was no folders other than sources.

Since there was no files I though this might be a space issue so ran some remote WMI commands to check the disk space available. I used the below PowerShell using Get-WMIObject.

Get-WmiObject Win32_logicaldisk -ComputerName RemoteComputerName | Select-Object @{Name="Drive";E={$_.DeviceID}},
@{Name="Size(GB)";E={[math]::Round($_.size/1gb)}},
@{Name="Free Space(GB)";E={[math]::Round($_.freespace/1gb)}},
@{Name="%Free Space";E={"{0:N2}" -f (($_.freespace/$_.size)*100)}}

In this case it wasn’t disk space a there was over 100GB free.

There wasn’t much online about the error other than the usually run scf /scannow, diskcheck and run the update troubleshooter but none of these worked.

Then found this post on the Microsoft forms that pointed to an issue with the setupconfig.ini

Generic 0xc190012e trying to upgrade Windows 10 1909 to 20H2 – Microsoft Community

C:\Users\Default\AppData\Local\Microsoft\Windows\WSUS

We aren’t using any custom setting in the setupconfig.ini so there was no issue for me to remove this.

Once I removed the file and kicked off the feature update again it now completes without issue.

I don’t know how the setupconfig.ini file was created on only a few devices but it was a quick fix once we found the issue was the config file.

Recently we have been testing Windows 10 20H2 Feature update deployment using ConfigMgr. When the update was applying it was failing and the error in software center was 0xC1900208.

To check what the code means I usually use the below Microsoft Doc but unfortunately the below code was not showing.

Windows Update error code list by component – Windows Deployment | Microsoft Docs

The error is listed under below Windows 10 upgrade errors doc

Get help with Windows 10 upgrade and installation errors (microsoft.com)

Since the error was relating to incompatible app next I checked the feature update logs these are located under a hidden folder on the root of the C drive C:\$WINDOWS.~BT\Sources\Panther

I checked the Setupact.log and the compatdata XML.

In the compatdata XML there was an incompatibility with the version of McAfee DLP installed on the device. This device was not getting the latest version of DLP.

To try fix the issue I updated the version to the latest release which support Windows 1020H2 and tried the update again but it continued to fail with a different error code 0x80240020.

To get the update to work correctly I had to remove the following folders

C:\Windows\ccmcache

C:\$WINDOWS.~BT\

And delete all the files and folders under

C:\Windows\SoftwareDistribution\Download

I also ran the below three action from the configuration manager agent in the control panel:

Machine policy retrieval and evaluation cycle, Software updates deployment evaluation cycle and software updates scan cycle.

I waited around 5 minutes for the scan’s to complete and tried the feature update again and it installed without issue this time.

We recently started to roll out Windows 10 and started to see spikes on our WAN links caused by the increased size of updates. We looked at installing local DP’s on each site but this would add a lot of over head for managing these DP’s.

We then looked at using branch cache, I decided to do a post on enabling branch cache in SCCM.

First I need to check on clients if branch cache was enabled to do this run the below command.

netsh branchcache show status all

Once confirmed we need to enable branch cache in SCCM client settings this can be either enabled on an existing device policy or create a new policy I am going with a new policy.

Logon to SCCM Admin console > Administration > Client settings

Right click on client settings > Create Custom Client Device Settings

Give the policy a Name and select Client Cache Settings

set the below settings

• Change Configure BranchCache to Yes
• Change Enable BranchCache to Yes
• Configure the cache size settings (default is 10%)

Once the policy has been setup just need to deploy to the required collections that have the clients that branch cache needs to be enabled on.

As part of Windows 10 OS it does it’s own branch Cache while downloading updates and it will overwrite SCCM client settings. To disable this setting we can create a group policy and apply just to windows 10 OS’s.

Below is the location of the settings that need to be disabled

Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Delivery Optimization, set (Download Mode) to disabled

If the policy is not showing it is probable because the ADMX template for windows 10 has not been added.

The last part is to enable Branch Cache in SCCM for the distribution points by selecting the properties of the distribution point as given below.

To test that the policy has been applied, go to a client device and update the machine policy. Then run netsh command again and we should now see branch cache has been enabled.

netsh branchcache show status all

Just want to put this up in case anyone else run in to this issue. I had to test migrated WSUS and SUP role from my Primary site server to its own standalone server, so I could complete the same task in production.

After the migration all updates showed as unknown for all devices. I check the update deployment log and WUAHandler.log under c:\Windows\CCM and the update scan started but just sat at  the below log output

Assignment({968F78AA-AE13-495C-83D9-74920944C702}) already in progress state (AssignmentStateDetecting). No need to evaluate

When I checked the WUAHandler log I could see the below but the site never registered the new WSUS server.

CWuaHandler::SetCategoriesForStateReportingExclusion called with {GUDI } for bundles

I checked the general bits like the site status, component status and wsyncmgr.log all where green and working correctly. I then checked a few post online and most pointed to a Content version / MinSourceVersion miss match issue from the WSUS DB.

I checked this and my content version was the same as in MinSourceVersion so that was not the issue.  I then had a look at the Window update registry key on the clients to see if the new WSUS was registered. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

It wasn’t 😦

Finally had a look boundary (Should have done this first ) and turns out I was a bit forgetful and didn’t add the new site server to the boundary group’s so no client’s where able to see the new SUP server.

Once I added to all boundary groups and did an update scan cycle all updates started to show a few hours later and the WUAHanlder log now showed the WSUS connection.

yay it’s all fixed 🙂

Point to take away, always add new site servers to boundary groups first 🙂

 

I recently had an issue installing Windows updates on some servers running Windows Server 2012 R2. The server would install most updates but not the monthly update rollups or the security only updates.

I checked the event logs and saw event 0x800F0831

This didn’t give much information on why the update was failing so I checked the CBS log under C:\Windows\Logs\CBS and found the below error. This pointed to a missing or corrupted update for KB4343898 which in my case was the August 2018 monthly update rollup.

CBS Failed to resolve package ‘Package_1101_for_KB4343898~31bf3856ad364e35~amd64~~6.3.1.9’ [HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION]

CBS Mark store corruption flag because of package: Package_1101_for_KB4343898~31bf3856ad364e35~amd64~~6.3.1.9. [HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION]

Next step was to check to see if the update was showing on the server so I used the PowerShell command Get-hotfix to search for the update.

Get-hotfix | where {$_.hotfixid -like “KB4343898”}

If I check the package folder C:\Windows\servicing\Packages  I can see the update is referenced but not the package showing the error in the CBS log. 

I had this issue a few years back and the fix was to add the update using Dism and the update cab file. To extract the update run expand updatefile /f:* exportpath

expand C:\temp\windows8.1-kb4343898-x64.msu /f:* C:\temp\KB4343898Once the update is extracted use Dism to add the problematic update this should install the missing files.

Dism /online /Add-package:C:\temp\KB4343898\Windows8.1-KB4343898-x64.cab

Once completed reboot the server if required, then try the update again, it should now install without issue.