Stel je voor: duizenden clients verspreid over tientallen locaties, allemaal netjes in Configuration Manager. Klinkt overzichtelijk — totdat de helft van je content niet aankomt, je boundary groups een eigen leven gaan leiden en je je afvraagt waarom die ene site in Groningen weigert mee te werken. Grote, gedistribueerde netwerken zijn een ander beestje dan een platte LAN-omgeving. Dit is hoe je SCCM daar goed op inricht.
Waarom gedistribueerde netwerken een aparte aanpak vragen
Een klein netwerk vergeeft veel. Eén distribution point, alles in één subnet, en SCCM vindt zijn weg wel. Maar zodra je meerdere fysieke locaties hebt — met trage WAN-verbindingen, firewalls ertussen en gebruikers die verwachten dat hun software gewoon werkt — wordt elke verkeerde keuze in je infrastructuur voelbaar. Content die over een 10 Mbit-lijn wordt geduwd in plaats van van een lokale DP gehaald. Clients die geen boundary group kunnen matchen en terugvallen op een site die honderden kilometers verderop staat. Dat soort dingen.
De kern van het probleem is bijna altijd hetzelfde: de SCCM-infrastructuur is niet meegegroeid met de netwerkinfrastructuur.
Boundary groups: de basis die je écht goed moet hebben
Boundary groups zijn het fundament van alles in een gedistribueerde omgeving. Je definieert welke IP-ranges of subnetten bij welke locatie horen, en koppelt daar distribution points en management points aan. Klinkt simpel. Is het ook — als je het goed doet.
De meest voorkomende fout is dat mensen boundaries aanmaken maar vergeten ze aan een boundary group te koppelen. Of ze koppelen wél een DP aan de group, maar vergeten het fallback-gedrag te configureren. Dan krijg je clients die netjes in een boundary zitten, maar toch content ophalen van een DP aan de andere kant van het land. Want SCCM is niet telepathisch.
Wat je wilt:
- Elke locatie heeft een eigen boundary group met een lokale DP
- Fallback naar een centrale DP is geconfigureerd, maar met een vertraging van minimaal 60 minuten
- Overlappende boundaries zijn bewust geconfigureerd, niet per ongeluk
Distribution points strategisch plaatsen
Niet elke locatie heeft een volwaardige server nodig. Voor kleinere filialen kun je prima werken met een pull distribution point of zelfs met BranchCache — zeker als je Windows 10 of 11 clients hebt die content onderling kunnen delen. Dat scheelt enorm op je WAN-bandbreedte.
Voor grotere locaties met veel clients en regelmatige deployments is een lokale DP gewoon de enige verstandige keuze. Reken maar uit: een patchcyclus waarbij 200 clients elk 500 MB ophalen over een trage verbinding. Dat wordt een vervelend gesprek met je netwerkbeheerder.
Een pull-DP haalt content op van een andere DP in plaats van rechtstreeks van de site server. Dat verplaatst de distributielast en is ideaal als je een centrale DP als bron wilt gebruiken zonder dat die server voor elke locatie afzonderlijk content moet pushen.
Software distribution en content management op schaal
Als je eenmaal je DP-structuur op orde hebt, is het zaak om je content slim te beheren. Distribueer niet alles naar alle DPs. Dat klinkt voor de hand liggend, maar je ziet het toch regelmatig: een package dat alleen relevant is voor de financiële afdeling in Amsterdam, maar netjes op alle 15 distribution points staat.
Gebruik distribution point groups om dit te stroomlijnen. Maak groepen per regio of per type locatie, en distribueer packages naar die groepen. Zo houd je controle zonder dat je per DP handmatig moet bijhouden wat er staat.
Houd ook je content library in de gaten. Op drukke DPs kan die flink groeien, en verouderde content die niemand meer nodig heeft slokt gewoon schijfruimte op. Een regelmatige cleanup — via de built-in Content Library Cleanup Tool — is geen overbodige luxe.
Collections en targeting in grote omgevingen
Grote omgevingen betekenen ook grote aantallen collections, en dat is waar het snel misgaat. Want wie heeft er nou niet een keer een deployment uitgerold naar een te brede collection, met als resultaat een helpdesk die overstroomt met telefoontjes van gebruikers die “ineens iets op hun scherm kregen”?
Discipline in collection-beheer is essentieel. Een paar vuistregels:
- Gebruik limiting collections bewust — niet alles hoeft direct onder “All Systems” te hangen
- Geef collections duidelijke namen die ook over een jaar nog begrijpelijk zijn
- Evalueer regelmatig welke collections nog actief gebruikt worden en welke je kunt opruimen
- Gebruik collection-variabelen voor locatiespecifieke instellingen in plaats van aparte packages te bouwen
Netwerkprotocollen en WAN-optimalisatie begrijpen
Als je echt wilt begrijpen waarom content soms traag of helemaal niet aankomt, helpt het om te snappen hoe de onderliggende protocollen werken. SCCM gebruikt standaard HTTP of HTTPS voor content distribution, en de manier waarop TCP-verbindingen zich gedragen over een hoge-latency WAN-verbinding is niet altijd intuïtief. Op Wikipedia vind je een toegankelijke uitleg over het TCP-protocol die helpt begrijpen waarom grote files over trage verbindingen zo anders presteren dan je op basis van bandbreedte alleen zou verwachten.
In de praktijk betekent dit: zorg dat je throttling-instellingen op je DPs realistisch zijn. Een DP die overdag mag stoken op 80% van de beschikbare bandbreedte klinkt genereus, maar als die bandbreedte gedeeld wordt met VoIP en andere bedrijfskritische applicaties, ga je klachten krijgen.
Monitoring en troubleshooting in een gedistribueerde omgeving
Tot slot: je kunt nog zo’n mooie infrastructuur bouwen, als je niet monitort wat er gebeurt, weet je pas dat er iets mis is als een gebruiker belt. Gebruik de ingebouwde statusberichten in SCCM en kijk regelmatig naar je component status en site status in de console.
Voor dieper troubleshooting zijn de logfiles je beste vrienden. Op een client is ccmexec.log je startpunt. Op de DP-kant kijk je naar distmgr.log en pkgxfermgr.log voor content distribution issues. En als een client geen content kan vinden, is locationservices.log op de client de plek waar je de oorzaak bijna altijd terugvindt.
Tot slot
Gedistribueerde netwerken en SCCM kunnen prima samen — maar dan moet je infrastructuur kloppen. Boundary groups, slimme DP-plaatsing, nette collections en actieve monitoring zijn geen nice-to-haves. Ze zijn het verschil tussen een omgeving die zichzelf runt en één waarbij jij elke week brand aan het blussen bent. En dat laatste is leuk voor een keer. Niet als structureel bedrijfsmodel.