Configure Branch Cache SCCM 1810

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 look at installing local DP 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

BC1

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 SettingsBC2

Give the policy a Name and select Client Cache SettingsBC6

set the below settings

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

BC3

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 disabledBC5

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.BC4

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 allBC7

SUP Migration WUHandler Error CWuaHandler::SetCategoriesForStateReportingExclusion

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

sup2

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.

sup3

yay it’s all fixed 🙂

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

 

Windows Updates Fail Error Code 0x800F0831 Server 2012 R2

I recently had and 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 0x800F0831Up2

This didn’t give much information on why the update was failing so I checked the CBS log 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. Up3

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”}Up4

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. UP6

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\KB4343898Up5Once 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.cabUp7

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