Als je ooit hebt zitten staren naar een client die gewoon niet wil communiceren met het juiste distribution point, terwijl je weet dat alles technisch goed zou moeten staan, dan is de kans groot dat boundaries en boundary groups de boosdoener zijn. Het is een van die onderdelen van SCCM die er op het eerste gezicht simpel uitziet — je gooit er een IP-range in, je maakt een group, klaar — maar in de praktijk een stuk genuanceerder werkt. Laten we dat eens netjes uitpakken.
Wat zijn boundaries eigenlijk, en waarom zijn ze niet genoeg op zichzelf
Een boundary is in essentie een netwerklokatie. Je vertelt SCCM: “als een client op dit IP-adres, in dit subnet, of in deze Active Directory site zit, dan weet ik waar die client thuishoort.” Dat klinkt helder. En dat is het ook, tot je beseft dat een boundary op zichzelf niets doet.
Serieus. Een boundary zonder boundary group is decoratie. SCCM gebruikt boundaries alleen wanneer ze aan een boundary group zijn gekoppeld. Die boundary group is het mechanisme dat bepaalt welke site systems — distribution points, management points, software update points — een client mag gebruiken. Pas dan wordt het interessant, en pas dan begrijp je waarom die ene client in het filiaal toch content bleef pullen van het hoofdkantoor terwijl je zwoor dat je alles goed had ingesteld.
Er zijn vier typen boundaries die je kunt aanmaken:
- IP subnet — klassiek, werkt altijd, weinig verrassingen
- Active Directory site — handig als je AD-sites netjes je netwerktopologie weerspiegelen
- IPv6 prefix — voor wie IPv6 serieus heeft uitgerold (beiden van jullie, hallo)
- IP address range — flexibel, maar pas op dat je geen overlap creëert met andere boundaries
Overlap is trouwens iets om op te letten. Clients die in meerdere boundaries vallen, horen bij alle bijbehorende boundary groups. Dat is niet per se een probleem, maar het kan onverwacht gedrag geven als je boundary groups niet goed zijn geconfigureerd.
Boundary groups: de echte configuratielaag
Hier wordt het interessant. Een boundary group heeft drie functies die je uit elkaar moet houden:
- Site assignment — bepaalt aan welke primary site een client wordt toegewezen
- Content locatie — bepaalt welke distribution points een client mag gebruiken
- Management point selectie — bepaalt welk management point een client benadert
Voor site assignment geldt: een boundary group die hiervoor wordt gebruikt, heeft die optie expliciet aan staan. Niet elke boundary group hoeft dat te doen. Als je een boundary group puur voor content distributie gebruikt, zet je site assignment gewoon uit.
De content locatie is waar de meeste sysadmins de meeste tijd mee kwijt zijn. Je koppelt distribution points aan een boundary group, en clients in de bijbehorende boundaries gebruiken die DP’s. Logisch. Maar wat als een client geen content kan vinden bij zijn eigen DP? Dan komt het fallback-mechanisme in actie — en dat is precies waar de volgende sectie over gaat.
Eén ding dat je niet moet vergeten: de default site boundary group. Die bestaat altijd, je kunt hem niet verwijderen, en hij bevat automatisch alle site systems die je niet expliciet aan een andere boundary group hebt gekoppeld. Hij fungeert als vangnet. Handig, maar ook een bron van verwarring als je niet doorhebt dat clients er soms onverwacht op terugvallen.
Fallback: de tijdslimiet die je moet kennen
Fallback is het mechanisme waarmee SCCM regelt wat er gebeurt als een client geen geschikte content kan vinden binnen zijn eigen boundary group. In plaats van gewoon te falen, mag de client na een bepaalde tijd uitwijken naar een neighbor boundary group of naar de default site boundary group.
Die tijdslimiet stel je zelf in, per relatie tussen boundary groups. Standaard staat die op 120 minuten voor neighbor groups en op 120 minuten voor de default group — maar dat is aanpasbaar. Je kunt ook instellen dat een bepaalde neighbor group nooit als fallback mag dienen, door de relatie op “never” te zetten.
Praktisch voorbeeld: je hebt een filiaal met een eigen DP. Die DP gaat offline. Wat wil je dan? Waarschijnlijk dat clients na een redelijke wachttijd uitwijken naar het hoofdkantoor, maar niet meteen — want misschien is de DP zo weer online. Je stelt de fallback-tijd in op, zeg, 60 minuten. Clients wachten een uur, en als de DP dan nog steeds niet bereikbaar is, pakken ze content van het centrale DP. Dat is precies het gedrag dat je wilt, en dat stuur je aan via de boundary group-relaties.
Wat je niet wilt: dat clients zonder enige configuratie gewoon altijd terugvallen op de default boundary group, omdat je vergeten bent neighbor-relaties in te stellen. Want dan trek je al het verkeer naar je centrale DP’s, ook als de lokale DP gewoon beschikbaar is. Dat heb ik meer dan eens zien gebeuren, en de WAN-beheerder is er nooit blij mee.
Veelgemaakte fouten en hoe je ze herkent
Laten we eerlijk zijn: boundaries en boundary groups zijn een van die configuratieonderdelen waarbij je pas begrijpt wat je fout hebt gedaan als je de symptomen ziet. Hier zijn de meest voorkomende problemen en wat ze veroorzaken.
Clients pullen content van het verkeerde distribution point
Bijna altijd een boundary-probleem. Controleer eerst of de client überhaupt in een boundary valt. Dat doe je via de LocationServices.log op de client — daar zie je welke boundary groups de client vindt en welke DP’s hij aangeboden krijgt. Als die log leeg is of alleen de default boundary group toont, weet je genoeg.
Site assignment werkt niet zoals verwacht
Controleer of de boundary group die je gebruikt voor site assignment ook daadwerkelijk die optie aan heeft staan. En controleer of de client in de juiste boundary valt. Klinkt voor de hand liggend, maar je zou verbaasd zijn hoe vaak het gewoon een typfout in een IP-range is.
Clients vallen altijd terug op de default boundary group
Dit betekent bijna altijd dat je geen neighbor-relaties hebt geconfigureerd, of dat de fallback-tijd te laag staat. Ga naar je boundary group-configuratie en kijk welke relaties er zijn. Als er geen zijn, is je fallback-gedrag volledig afhankelijk van de default group — en dat is zelden wat je wilt.
Overlap in boundaries
Als een client in meerdere boundaries valt die aan verschillende boundary groups zijn gekoppeld, krijgt die client alle bijbehorende DP’s aangeboden. Dat kan prima zijn, maar het kan ook betekenen dat een client een DP aan de andere kant van de wereld krijgt aangeboden. Gebruik de ContentTransferManager.log en LocationServices.log om te zien welke DP’s daadwerkelijk worden geprobeerd.
Een handig hulpmiddel: in de SCCM-console kun je bij een client rechtsklikken en “Start” → “Client Diagnostics” gebruiken om boundary-informatie op te halen. Niet altijd de meest uitgebreide output, maar het geeft je een snelle eerste indicatie.
Een schone boundary-structuur opzetten: zo pak je het aan
Als je van nul begint, of als je een bestaande omgeving wilt opschonen, is het slim om een vaste aanpak te hanteren. Geen rocket science, maar wel discipline.
Stap 1: breng je netwerktopologie in kaart
Welke locaties heb je? Welke subnetten horen bij welke locatie? Heb je AD-sites die dat al weerspiegelen? Als je AD-sites goed zijn ingericht, kun je die direct als boundary-type gebruiken — scheelt je een hoop handmatig werk.
Stap 2: maak boundaries aan per locatie
Eén boundary per subnet of AD-site, netjes benoemd naar de locatie. “HQ-10.0.1.0/24” is een stuk duidelijker dan “Boundary 1”. Toekomstig-jij zal je dankbaar zijn.
Stap 3: groepeer boundaries in logische boundary groups
Eén boundary group per locatie, met de bijbehorende boundaries erin. Koppel de lokale DP(‘s) aan die boundary group. Geef de boundary group een naam die de locatie duidelijk aangeeft.
Stap 4: configureer fallback-relaties
Bepaal voor elke locatie: als de lokale DP niet beschikbaar is, waar mag de client dan naartoe? Maak die relaties aan en stel een redelijke fallback-tijd in. Denk na over je WAN-capaciteit — een lage fallback-tijd betekent sneller verkeer over de WAN-link.
Stap 5: test met een paar clients
Verplaats een testclient naar een subnet, wacht tot de client zijn boundary group heeft opgepikt (dat duurt even, afhankelijk van de heartbeat discovery-cyclus), en controleer de LocationServices.log. Ziet de client de juiste DP’s? Mooi. Zo niet, terug naar stap 2.
Stap 6: documenteer
Ik weet het, niemand doet dit graag. Maar een simpele tabel met locatie → boundary → boundary group → DP’s → fallback-relaties bespaart je uren werk als je een half jaar later iets moet wijzigen en je niet meer weet waarom je bepaalde keuzes hebt gemaakt.
Boundaries en boundary groups zijn een van die configuratielagen die je één keer goed moet neerzetten, en daarna eigenlijk weinig meer aan hoeft te doen. Het is geen sexy onderwerp — niemand vertelt enthousiast over zijn boundary group-structuur op een vrijdagmiddag — maar een goed ingerichte omgeving merkt je pas als alles gewoon werkt. En dat is uiteindelijk precies waar het om gaat.