Je hebt een nieuwe applicatie klaarstaan, de deployment is aangemaakt en je wacht vol vertrouwen af. En dan: niets. Of erger, de verkeerde machines krijgen de software. Herkenbaar? Software distribution in SCCM is op papier eenvoudig, maar in de praktijk zitten er genoeg valkuilen die je dag kunnen verpesten.
Wat software distribution in SCCM precies inhoudt
Software distribution is het proces waarbij je applicaties, pakketten of updates naar managed clients stuurt via Configuration Manager. Je definieert wat er geïnstalleerd moet worden, waar het naartoe gaat en wanneer dat gebeurt. Dat klinkt simpel, maar er zitten meerdere lagen onder.
SCCM maakt onderscheid tussen Applications en Packages. Applications zijn de modernere variant: ze ondersteunen detectiemethodes, dependencies en supersedence. Packages zijn de oudere aanpak, ideaal voor scripts of installers die geen MSI-structuur volgen. Welke je kiest, hangt af van wat je distribueert en hoeveel controle je nodig hebt over het installatiegedrag.
Collections: de basis van elke deployment
Alles draait om collections. Een deployment zonder de juiste collection is een deployment die ofwel niets doet, ofwel op de verkeerde machines belandt. Want wie heeft er nou niet een keer een verkeerde collection getarget en vervolgens een telefoontje gekregen van iemand wiens werkplek ineens een andere applicatie had.
Device collections en user collections gedragen zich anders. Device collections zijn deterministisch: machine X zit erin of niet. User collections zijn afhankelijk van wie er ingelogd is, wat ze minder voorspelbaar maakt voor software distribution. Gebruik device collections standaard, tenzij je bewust gebruikersgerichte deployments wilt doen.
Zorg dat je collections goed gesegmenteerd zijn. Een collection per afdeling, per locatie of per functiegroep geeft je veel meer controle dan één grote ‘alle werkstations’-collection. Dat kost vooraf tijd, maar bespaart je later een hoop hoofdpijn.
Distribution points en content distribution
Voordat een client iets kan installeren, moet de content beschikbaar zijn op een distribution point. Dit is het onderdeel waar veel mensen de fout in gaan: ze maken een deployment aan voordat de content volledig gedistribueerd is. Het resultaat is een client die de installer niet kan vinden en de deployment als mislukt rapporteert.
Check altijd de contentstatus in de console onder Monitoring > Distribution Status. Wacht tot de content de status ‘Success’ heeft op alle relevante distribution points voordat je de deployment activeert. Klinkt logisch, maar in de praktijk sla je deze stap over als je haast hebt.
Bij grotere omgevingen met meerdere locaties wil je ook nadenken over boundary groups. Die bepalen welk distribution point een client gebruikt op basis van netwerklocatie. Een client in Amsterdam moet niet zijn content ophalen van een distribution point in Utrecht als er lokaal eentje beschikbaar is.
Deployment types en installatie-instellingen
Binnen een Application definieer je een of meerdere deployment types. Elk deployment type beschrijft hoe de software geïnstalleerd wordt: welke installer, welke commandline-parameters, welke detectiemethode en welke requirements gelden. Requirements zijn handig om een deployment type alleen uit te voeren op machines die aan bepaalde criteria voldoen, zoals een specifiek besturingssysteem of een minimale hoeveelheid schijfruimte.
De detectiemethode is cruciaal. SCCM gebruikt die om te bepalen of een applicatie al aanwezig is op een machine. Zonder goede detectiemethode herinstalleert SCCM de software elke keer opnieuw, of rapporteert het onjuist dat de installatie mislukt is. Gebruik bij voorkeur een registry-check of bestandsversie als detectiemethode, niet alleen de aanwezigheid van een bestand zonder versiecontrole.
Commandline-parameters verdienen ook aandacht. Stille installatie, geen herstartprompt, logbestand aanmaken: dit stel je in per deployment type. Test die parameters altijd eerst handmatig op een testmachine voordat je de deployment breed uitrolt.
Required vs. Available: bewuste keuze
Bij het aanmaken van een deployment kies je tussen Required en Available. Required betekent dat de software automatisch geïnstalleerd wordt op basis van de deadline die je instelt. Available betekent dat de software in Software Center verschijnt en de gebruiker zelf kan installeren.
Voor standaardsoftware die op alle machines aanwezig moet zijn, gebruik je Required. Voor optionele tools of applicaties die medewerkers zelf kunnen kiezen, gebruik je Available. Het klinkt voor de hand liggend, maar in de praktijk zie je regelmatig Required-deployments voor software die eigenlijk optioneel is, met irritatie bij eindgebruikers als gevolg.
Let ook op de deadline-instelling bij Required-deployments. Een deadline midden op de dag kan leiden tot onverwachte installaties tijdens werktijd. Plan deadlines buiten kantooruren, of gebruik maintenance windows om te bepalen wanneer installaties mogen plaatsvinden op een device.
Monitoring en troubleshooting van deployments
Je hebt de deployment aangemaakt, de content staat op de distribution points en de deadline is verstreken. Nu wil je weten wat er gebeurd is. De Deployments-node onder Monitoring geeft je een overzicht per deployment, inclusief statistieken over succes, mislukking en nog uitstaande installaties.
Voor diepere analyse kijk je naar de logbestanden op de client. AppEnforce.log en AppDiscovery.log zijn je beste vrienden bij het debuggen van applicatie-deployments. AppEnforce.log laat zien wat er tijdens de installatie is uitgevoerd, AppDiscovery.log toont hoe de detectiemethode heeft geëvalueerd. Bij pakket-deployments is execmgr.log de plek om te zijn.
Op de siteserver zijn CAS.log en MP_Location.log nuttig als je vermoedt dat clients het distribution point niet kunnen vinden. Combineer serverside en clientside logging voor een volledig beeld. Raad plekken zoeken in de console zonder logbestanden erbij leidt zelden tot snelle antwoorden.
Veelgemaakte fouten bij software distribution
Laten we eerlijk zijn: de meeste problemen bij software distribution zijn vermijdbaar. Hieronder de meest voorkomende fouten:
- Content niet gedistribueerd voordat de deployment actief is, waardoor clients de installer niet kunnen downloaden
- Geen detectiemethode of een slechte detectiemethode, waardoor SCCM niet weet of de software al aanwezig is
- Verkeerde collection getarget, met als gevolg dat de deployment op de verkeerde machines terechtkomt
- Geen maintenance window ingesteld op productiesystemen, waardoor installaties overdag plaatsvinden
- Commandline-parameters niet getest, waardoor de installer een fout geeft die je had kunnen voorzien
- Boundary groups niet goed geconfigureerd, waardoor clients content ophalen van een distribution point aan de andere kant van het netwerk
- Supersedence niet ingesteld bij updates van een applicatie, waardoor oude versies blijven staan naast de nieuwe
Een it bedrijf dat SCCM beheert voor meerdere klanten, heeft dit soort fouten al lang geleden gestandaardiseerd weggewerkt via deployment templates en vaste checklists. Zelf kun je hetzelfde bereiken door een intern proces te documenteren voor elke nieuwe deployment: content checken, detectiemethode valideren, testmachine draaien, dan pas breed uitrollen.
Veelgestelde vragen over software distribution in SCCM
Wat is het verschil tussen een Application en een Package in SCCM?
Een Application ondersteunt detectiemethodes, dependencies en supersedence, wat het beter beheersbaar maakt voor moderne software. Een Package is de oudere methode en werkt goed voor scripts, batchbestanden of installers zonder MSI-structuur. Voor nieuwe deployments kies je bijna altijd voor een Application, tenzij de installer simpelweg niet in dat model past.
Waarom wordt mijn deployment niet uitgevoerd op de client?
Er zijn meerdere oorzaken mogelijk. Controleer eerst of de content beschikbaar is op het juiste distribution point. Kijk daarna of de client in de juiste collection zit en of de collection-membership al bijgewerkt is. Controleer vervolgens de logbestanden op de client, met name AppEnforce.log en execmgr.log. Een maintenance window dat de installatie blokkeert is ook een veelvoorkomende oorzaak die makkelijk over het hoofd wordt gezien.
Hoe stel ik een goede detectiemethode in?
Gebruik een registry-sleutel die door de installer wordt aangemaakt, of controleer de versie van een specifiek bestand dat na installatie aanwezig is. Vermijd detectiemethodes die alleen controleren of een bestand bestaat zonder versiecontrole, want dat geeft onbetrouwbare resultaten bij updates. Test de detectiemethode altijd handmatig op een machine waar de software al geïnstalleerd is en op een machine waar dat niet het geval is.