Configure your boundaries like a champ, distribute software from peers Kerim Hanif Senior Program Manager Microsoft Corporation Kerim.hanif@microsoft.com Jason Sandys Consultant Coretech blog.configmgrftw.com Jason@sandys.us j

Kerim Hanif Jason Sandys @kerimhanif @JasonSandys Survived 2 children 8 time MVP 20 years industry, 14 years MS 20+ years j Love cooking, travelling, scuba Glory glory Man United

AGENDA Boundary Group Improvements Client Peer Cache Distribution Points Software Update Points Caveats/Tips Future plans Client Peer Cache History Today Real word examples Q&A j

Boundary Group improvements - DP Allows you to create relationships between boundary groups Allows predictability to failover scenarios Works for Distribution Points 1610 onwards k

Default-Site-Boundary-Group<DBJ> New Concepts, changes 9/18/2018 10:18 PM Default-Site-Boundary-Group<DBJ> DPD1 DPD2 No more fast/slow distribution points “Default-Site-Boundary-Group” (per site) “Current” boundary group “Neighbor” boundary groups No more “allow fallback” setting per DP Configure relationships to achieve protection to your DPs Implicit fallback time for the Default-Site- Boundary-Group Can be overridden by explicit relationship Now clients will try next distribution point in ~10 min (used to be 2 hours) After upgrade NO new configuration is needed 120 min Redmond DPR1 DPR2 50 min 90 min k San Diego DPS1 DPS2 Bellevue DPB1 DPB2 © 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Site-Default-Boundary-Group<DBJ> Example Site-Default-Boundary-Group<DBJ> DPD1 DPD2 Client begins searching for content in its current boundary group Redmond. Tries each of these pool of valid content locations ~10 min in the order of: DPR1, DPR2, DPR1, DPR2, DPR1 If failed after 50 min adds Bellevue to its pool and keeps Redmond in case if it can find it in its fastest location. Tries ~10 min each in order of: DPR1, DPR2, DPB1, DPB2, DPR1, DPR2, DPB1…cont.. If failed after 40 additional min (total 90 min) adds San Diego still keeping the others, so the pool becomes: DPR1, DPR2, DPB1, DPB2, DPS1, DPS2, DPR1 ..cont.. If failed after another 30 additional min (total of 120 min), it adds Site-Default-Boundary-Group for its assigned site and continues until default timeout: DPR1, DPR2, DPB1, DPB2, DPS1, DPS2, DPD1, DPD2, DPR1, DPR2, DPB1, DPB2…cont.. NOTE: You can still use deployment settings to prevent 2, 3 (neighbor) or 4 (site default) from happening. 120 min Redmond DPR1 DPR2 50 min 90 min k San Diego Bellevue DPS1 DPS2 DPB1 DPB2

Caveats, Tips Now, intranet clients can favor Cloud DPs since they can be associated with boundary groups. Internet clients don’t make use of boundaries. MP only returns peer cache sources for the requesting client’s current boundary group, no neighbors. Clients that don’t fall under any boundary will always fall back to Default-Site- Boundary-Group. You can override implicit “Default-Site-Boundary-Group” fallback time by explicitly adding a relationship. k

How to override implicit relationship Even though no relationship it listed, all boundary groups have an implicit relationship to the Default-Site-Boundary-Group You can explicitly add Default-Site-Boundary-Group to a boundary group’s relationship tab and override this if needed Or change the “Default Behavior” tab to impact all boundary groups’ implicit relationships k

Update to current branch from sp2 or r2sp1 Default-Site-Boundary-Group<PS1> For each primary site Including unprotected DPs and Cloud DPs Original boundary group name-<Boundary Group ID> For boundary groups with slow DPs A fallback link of 0 fallback time added Secondary-Site-Neighbor--Tmp<SS1> For boundary groups with secondary site DPs Including secondary site unprotected DPs k

Upgrade DP3 (S) (AF) DP3 (S) (AF) DP2 (F) (NF) 9/18/2018 10:18 PM Upgrade DP3 (S) (AF) DP3 (S) (AF) DP2 (F) (NF) BG1-<Boundary Group ID> BG1 DP1 (F) (AF) DP1 (F) (AF) DP4 (S) (NF) 120 k Default-Site-Boundary-Group<RED> AF: Allow fallback NF: No fallback allowed S: Slow F: Fast DP5 (AF) Cloud DP © 2014 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Upgrade (Secondary Site) DP1 (AF) DP1 (AF) Secondary-Site-Neighbor-Tmp<SEC> SBG1 DP2 (NF) k AF: Allow fallback NF: No fallback allowed DP3 (AF)

Boundary Group improvements - SUP Allows you to create relationships between boundary groups Allows predictability to failover scenarios Works for Configuration Manager 1702 onwards J

Software Update Points Today Default Site Boundary Group Software Update Points Today DP Default SUPs are hierarchy based, can’t be assigned to a boundary group Clients can choose any SUP in hierarchy No affinity can be created with a boundary group 120 min SUP Default Redmond BG DP Redmond SUP Redmond SUP Bellevue j 20 min Bellevue BG DP Bellevue

Default Site Boundary Group After Upgrade Default Site Boundary Group DP Default SUP Default SUP Bellevue SUP Redmond Everything continues to work as it was before upgrade We move all SUPs to the “Default Site Boundary Group” since we don’t know which boundary they should be associated with Clients continue using their existing SUPs Fallback time remains to be 2 hours 120 min Redmond BG DP Redmond j 20 min Bellevue BG DP Bellevue

Default Site Boundary Group After Admin Edits Default Site Boundary Group DP Default SUP Default We recommend all admins to move SUPs to their desired location and assign them to the boundary groups ConfigMgr clients needs to be upgraded (to 1702) to take advantage of the boundary group affinity Clients still continue to use their existing SUP Clients will move to new SUP under two circumstances: They can’t reach and timeout on their existing SUP Admins manually select “Client Notification -> Switch to next software update point”. This can be done collection based 120 min Redmond BG DP Redmond SUP Redmond j 20 min Bellevue BG DP Bellevue SUP Bellevue

MP_Location.log j

Client Peer cache History Peer Cache is an OS-independent, 100% native ConfigMgr solution to accomplish peer-to-peer content sharing “in” and “across” subnets. Extension of the existing “Windows PE Peer Cache” solution Now ConfigMgr full client can share its content cache to its peers. Absolutely no goal to compete with partners (internal and external) j

Configuration Peer Cache Source PCs Collection New York MP I am a now a Peer Cache Source Here is my network, boundary info Here is what I currently have in my cache Redmond Primary SQL k Boston

Content location Order (INTRANET Client) Client on DP Peer in the same subnet DP in the same subnet Peer in the same AD site DP in the same AD site Peer in the same boundary group DP in current boundary group DP in neighboring boundary group DP in Default Site Boundary Group Windows Update Internet Facing DP Cloud DP J

New York Boundary Group You need to install “Contoso.exe” here are all the locations where it is available. Client1 [BOUNDARYGROUP] Client2 [BOUNDARYGROUP] DP2 [NEIGBORBOUNDARYGROUP] Client2 MP Redmond New York Boundary Group Contoso.exe Redmond BG Primary DP2 Contoso.exe Client1 j This is an example where there are no DPs in the boundary group NY, the only DP is in the neighbor boundary group So when the client in NY wakes up and asks the MP what it needs to do (this is a regular request) MP now sends peer sources along with DPs as a response Client then decides where to get the content from If there are peers in its current boundary group, it will get the content from them. It will randomly select which one if there are more than one with the same content. Contoso.exe What do you have for me?

New York Boundary Group You need to install “Contoso.exe” here are all the locations where it is available. Client1 [BOUNDARYGROUP] Client2 [BOUNDARYGROUP] DP1 [BOUNDARYGROUP] DP2 [NEIGHBORBOUNDARYGROUP] Client2 MP DP1 Redmond New York Boundary Group Contoso.exe Contoso.exe Redmond BG Primary DP2 Contoso.exe Client1 J This is an example where there are DPs in the current boundary group NY So the MP returns that DP’s name along with peer sources But if both DP and peer is available in the current boundary group the logic is that they have the same priority. So DP is NOT higher priority then a peer source. In this case it will again randomly select a source to pull from, it may very well select DP or Client2 as well as Client1, I just used Client1 as an example here. Contoso.exe What do you have for me?

New York Boundary Group Subnet 2 You need to install “Contoso.exe” here are all the locations where it is available. Client1 [BOUNDARYGROUP][Subnet1] Client2 [BOUNDARYGROUP][Subnet2] DP1 [BOUNDARYGROUP][Subnet1] DP2 [NEIGHBORBOUNDARYGROUP] Subnet2 MP Client2 Redmond Contoso.exe New York Boundary Group Redmond Primary DP2 Contoso.exe DP1 Subnet1 Client1 Contoso.exe J This is an example where there are DPs in the current boundary group NY So the MP returns that DP’s name along with peer sources But if both DP and peer is available in the current boundary group the logic is that they have the same priority. So DP is NOT higher priority then a peer source. In this case it will again randomly select a source to pull from, it may very well select DP or Client2 as well as Client1, I just used Client1 as an example here. Contoso.exe What do you have for me?

New York Boundary Group You need to install “Contoso.exe” here are all the locations where it is available. Cloud DP [BOUNDARYGROUP] DP2 [NEIGHBORBOUNDARYGROUP] Cloud DP MP Contoso.exe Redmond New York Boundary Group Redmond BG Primary DP2 Cloud DP (Association) Contoso.exe K This is an example where there are DPs in the current boundary group NY So the MP returns that DP’s name along with peer sources But if both DP and peer is available in the current boundary group the logic is that they have the same priority. So DP is NOT higher priority then a peer source. In this case it will again randomly select a source to pull from, it may very well select DP or Client2 as well as Client1, I just used Client1 as an example here. What do you have for me?

Content location Order (Internet Client) Fallback based on failures NOT boundaries Windows Update Internet Facing DP Cloud DP K

Client data sources dashboard K

What’s new in 1702 Peer Cache Boundary Groups Rejection Peer cache sources can reject serving clients if they are busy Is in low battery mode. CPU load exceeds 80% at the time the content is requested. Disk I/O has an AvgDiskQueueLength that exceeds 10. There are no more available connections to the computer. Boundary Groups Software Update Points are added J

Reports 1610 1702 Client data sources Peer cache source content rejection Peer cache source content rejection by condition Peer cache source content rejection details Check known issues here: https://docs.microsoft.com/en-us/sccm/core/plan- design/hierarchy/client-peer-cache K

Reports K

future Boundaries Client Peer Cache Management Points State Migration Points Client Peer Cache Support for Window express files Support for O365 delta files Fixes for the reporting issues K

Real world Upgrade example – It Just Worked Datacenter A Site System A MP, DP, SUP ~100 Remote DPs Fallback Primary Site Server Datacenter B Site System B MP, DP, SUP

Client Peer Cache – Product team stress test 1 500 250 9 Primary Site Server Actually used as a Source Most number of times used Total clients* Application deployment, no content pre-caching * All Peer Cache Sources (Not recommended, 10%, 20% is recommended)

Client Peer Cache – Product team stress test 1 500 2 12 Primary Site Server Hours between available and deadline times Most peer sources at one time Total clients* Application deployment, no content pre-caching * All Peer Cache Sources (Not recommended, 10%, 20% is recommended)

Deadline Randomization is Peer Cache’s Friend   Activation Randomization Deadline Randomization Applications Packages … Enabled 2 hours (by default *) Software Updates DISABLED by default ** * Only changeable directly in the Site Control File ** Changeable in Client Settings