Well, a few fields, not necessarily our own fields…
OK now listen up!
Quite a few of you lovely folks have been playing with the new ConfigMgr Peer Cache feature in your labs. Unfortunately, it seems, that even in this day and age, your Lab happens to contain ALL your production clients and servers… really!?
So, if you really want to deploy Peer Cache, which is, (and I will say this again a bit louder for the hard of hearing) a PRE-RELEASE FEATURE, you better follow this guide or you may end up having to revisit a) your resume and b) monster.com
Field Guide to ConfigMgr Peer Cache in ConfigMgr CB1610: Follow this and you might just stand a chance…
- DO NOT enable Peer Cache unless you have read all of the points below.
- Make sure that you understand, and have properly configured your site boundaries and boundary groups. It’s all changed y’know
- Understand that once you enable some ConfigMgr clients as Peer Cache sources, they are in effect acting like DPs so:
- Start small: don’t enable Peer Cache on all your clients straight away – and yes, some people have, yes you there, – go and stand in the corner please
- Providing they are still a Peer Cache Source and they have the content that is requested in their CCMCache, Peer Cache sources will ALWAYS be returned in a content lookup
- If a Peer Cache source is turned off – if takes 7.5 minutes to failover to the next content location in the list (which may also be turned off) This has happened folks! If your content lookup returns 20 Peer Cache source clients that are powered off – well do the math
- If you read the above, panic, and turn off Peer Cache. and your Peer Cache clients are turned off – it will take some time to update the ConfigMgr DB with this info and they will still be returned in a content lookup. So, your nightmare will continue for some time..
- If you are really really bricking your pants becasue it’s all gone terribly wrong and nothing is working – ping us, we can/will help but will mock you terribly 🙂
- It can take up to 24 hours to populate the Client Data Sources dashboard – so don’t for a second think that nothing is happening in Peer Cache land
- If you schedule a deployment with an ‘Available From’ time in the future, chances are that Peer Cache won’t work too well. It can’t start sharing content until it has completely downloaded ALL the content AND reported that fact back to the ConfigMgr site via the MP. So if you have a ton of clients all trying to do this at once – well you get the picture
- If you bump the Content Version (by adding some files and performing a ‘Update Distribution Points’ for instance) the Peer Cache client will not respond to requests for the new Content Version until it has the new version in the CCMCache
- If you run a Client Repair – you may well invalidate the Content Map in the ConfigMgr DB. Peer Cache clients need to report to the MP when content has been removed.
- If you ‘just delete shit’ from the CCMCache it may not be reported back up to the ConfigMgr site – again your Content Map will be outta whack. Use a script which uses the correct methods to remove content gracefully if you have to
- If you use the ConfigMgr BITS Policy, or any BITS policy to throttle your downloads (we did tell you not to – many times) You are also potentially throttling your Peer Cache Peer 2 Peer transfers between clients to the same speed. UPDATE – If the machines are on the same subnet – the priority is set to FOREGROUND, and not subject to policy. If the source and destination are on different subnets then BITS throttling policy will apply as it’s a LOW priority BACKGROUND job..
- If you have clients that move around between Boundary Groups a lot – it’s best to NOT have them configured as Peer Cache sources. Their Boundary Group info on the Site DB is not updated until the next time that they run HW/Inventory so the ‘could’ (i.e ‘will’) still serve up content to their OLD Boundary Group Peers.
- And finally. Always always always use BranchCache as a backup – it may save your sorry ass!
P.S The above may/may not be fake news and/or alternative facts, so don’t blame us if none of the above is of the slightest help whatsoever.
Love & Hugs, 2Pint