Every now and then we like to kick the tyres of ConfigMgr Peer Cache. Each release brings new features and tweaks, and 1806 is no exception.

The Big News – Fast Channel All The Way

The major (and undocumented at the moment) shift in this release is the move to using the ‘Fast Channel’ for communicating Boundary Group changes up to the site. Previously we relied on Heartbeat discovery to report changes to a client’s IP Address/Subnet etc – which could take a while.. This meant that Peer Cache was only really suitable for fairly ‘static’ clients that didn’t change location much. It even says that in the docs –

“The client’s last heartbeat discovery submission determines the current boundary of a peer cache source. A client that roams to a different boundary group might still be a member of its former boundary group for the purposes of peer cache. This behavior results in a client being offered a peer cache source that isn’t in its immediate network location. Don’t enable roaming clients as a peer cache source.”

Now however, clients report the current Boundary Group during the ‘Keep-alive’ check-in via the Fast Channel every 15 minutes. Awesome! But also, that keep-alive message is triggered instantly if the client changes location – I tested it by simply moving a VM to a different switch/subnet in my test setup – and you can see what happens in the CcmNotificationAgent.log

 

So you can see that there’s a ‘Sleep 7 seconds to restart’.. in there – which seems to be randomized so that you don’t get a storm of machines trying to connect back if there’s a network blip.

BUT! All is not well with the world..

What we see next is that the new IPAddress is reported – but the Boundary Group is still showing the OLD entry. The new Boundary Group is not reported for a further 15 minutes.

Obviously this is still better that waiting a day/week/month as per the ‘olden days’ of Peer Cache using Heartbeat Discovery, but I’m hoping that this can be ironed out with a wee hotfix.

The Fast Channel is also used to check if a Peer Source is online once it is returned via Content Lookup. This means that failover to the next Content Source is much more dynamic. Just be aware that you need Port 10123 open to utilize this. There’s a great blog from Anoop on that here: https://www.anoopcnair.com/video-guide-to-troubleshoot-sccm-cb-fast-channel-push-notification-issues/

 

In other News

The other Peer Cache enhancements for 1806 are pretty well documented but I will include them here as there are some caveats.

First up – we got ‘Allow peer downloads in this boundary group’

– Great if you want to test Peer Cache on a pilot BG before general rollout. Be aware though – that this setting also affects applying Group IDs for Delivery Optimization – if you are using that be careful.

Next is more interesting – ‘Only use Peers within the same subnet’

-So potentially making Peer Cache a bit more ‘BranchCache-like’ by restricting it’s scope to the local subnet. However, this still relies on accurate Peer Cache source information at the time of download, it does NOT check to see if the Peer Cache source is actually on the same subnet. So if your Peer Cache source machine happened to have moved to another BG and has not updated the server side of things (as happened in my testing) you will be pulling content from that Peer –  wherever it may be!

Nasty Bug UPDATE – In our testing here we found that checking this box does not restrict Peer Cache transfers to the same subnet. This is because the Peer Cache content lookup checks the IPv6 Subnet prefix as well as the IPv4 subnet info. Unfortunately, the IPv6 prefix returned by SCCM can (and will by default) return the prefix of the Teredo Tunnelling  Adapter – which is the same on all your Windows machines. Oops!  So potentially even with this box checked you can still get content coming from anywhere within the Boundary Group. Be aware that this will happen EVEN IF YOU ARE NOT USING IPv6 – it’s just enabled by default. The only way that I got around this was to disable the Teredo Adapter – which is not s great idea in itself. So our advice? Don’t use this feature until it gets fixed – probably the next CB release.

Partial Downloads Anyone?

Now this feature boggles my mind. You can read about it here – https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/client-peer-cache#bkmk_parts

If you could read it, get back to me and explain it I would be most grateful 🙂 Seriously?  I think it’s over complicated, relies on fallback (why?) and only applies to ‘Background’ downloads.

I can understand trying to overcome the limitation of having to download ALL content before any sharing can take place, but not sure that this is the right way to do it.. hey ho – time will tell.

Automation!

Just came across this great piece on automating the above settings – all hail the ConfigMgr PFE! https://www.linkedin.com/pulse/setting-new-options-peer-cache-boundary-groups-using-powershell/?published=t

In Summary

1806 is packed with really useful new stuff. LEDBAT! (need I say more)   But these Peer Cache enhancements are also a good step forward – particularly the Fast Channel comms side of things. Or at least they will be when it’s all working 🙂