1 21/05/2026 10 min

Distribuzione del ruolo Distribution Point: cosa stai davvero preparando

Un Distribution Point in SCCM non è solo un server che “contiene file”. È il punto in cui il client recupera content, policy e pacchetti secondo regole precise di boundary, fallback e prestazioni. Se lo installi male, il sintomo non è quasi mai un errore chiaro in fase di setup: più spesso vedi download lenti, contenuti non disponibili, coda distribuzione ferma o client che insistono sul MP invece di usare il DP corretto.

Qui l’obiettivo è installarlo con PowerShell in modo ripetibile, tracciabile e reversibile. Il punto non è “fare clic più veloce”, ma portarsi dietro prerequisiti, validazioni e un rollback che non lasci ruoli sporchi o contenuti parziali.

Assumo un ambiente Configuration Manager corrente, server Windows supportato, accesso con privilegi adeguati sul sito e connettività verso il server di sito. Se usi HTTPS, PKI o boundary group complessi, devi considerare quei vincoli prima ancora del comando di installazione.

Prerequisiti che conviene verificare prima di toccare il sito

Un DP ben riuscito dipende più dai prerequisiti che dal cmdlet. Prima di avviare l’installazione, controlla tre aree: sistema operativo e ruoli Windows, rete e DNS, spazio disco e percorso content library.

Verifica che il server sia raggiungibile dal management point e dal site server, che il nome DNS risolva correttamente e che i firewall consentano il traffico richiesto da Configuration Manager. Se il server ospiterà anche il PXE, devi pianificare in anticipo UEFI, DHCP, porte e eventuali servizi WDS o l’uso del PXE responder integrato.

Controlla anche il disco destinato alla content library. Il problema classico è installare il ruolo su una VM con spazio sufficiente per il setup ma non per i contenuti reali. Il DP sembra “online” e poi collassa al primo content update serio.

Un controllo minimo lato OS può essere questo:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer
Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, Free
Resolve-DnsName dp01.contoso.local

Se uno di questi punti fallisce, non ha senso andare oltre: prima chiudi il gap, poi installi il ruolo.

Struttura del comando: installazione del Distribution Point via PowerShell

In SCCM la strada più pulita è usare il modulo di Configuration Manager dal server di sito o da una console con i cmdlet disponibili. La logica è semplice: prima ti posizioni sul drive del sito, poi aggiungi il server come site system server e infine abiliti il ruolo Distribution Point con i parametri necessari.

Il pattern tipico è questo: definisci il server, il sito, il drive del provider e le opzioni del ruolo. In ambienti reali conviene scrivere il tutto in uno script, non lanciare comandi sparsi in sessione interattiva. Così ti rimane traccia di ciò che hai passato al setup e puoi rifarlo senza ambiguità.

Esempio base:

Import-Module ConfigurationManager
cd XYZ:
$server = "DP01.contoso.local"
New-CMSiteSystemServer -SiteSystemServerName $server
Add-CMDistributionPoint -SiteSystemServerName $server -ClientCommunicationType HTTP

Questo è volutamente minimale. In produzione quasi mai ti basta: devi specificare storage, PXE, multicast, fallback e talvolta il comportamento della content library. La scelta dei parametri dipende dal ruolo che vuoi assegnare al server.

Installazione con opzioni esplicite: storage, PXE e comunicazione client

Se il DP deve servire contenuti in modo serio, specifica dove vuoi la content library e come vuoi gestire la comunicazione client. Lasciare tutto ai default può andare bene in laboratorio, ma in produzione tende a creare configurazioni opache.

Un esempio più concreto, con percorso dedicato per la libreria e supporto PXE disabilitato di default:

Add-CMDistributionPoint ` -SiteSystemServerName "DP01.contoso.local" ` -ClientCommunicationType HTTP ` -PrimaryContentLibraryLocation "D:\SCCMContentLib" ` -PrimaryPackageShareLocation "D:\SCCMPkgShare"

Se vuoi abilitare PXE, aggiungilo solo quando hai verificato che il server sia pronto a gestire l’avvio di rete e che non ci siano conflitti con altri servizi di provisioning. In molti ambienti il problema non è il DP in sé, ma la combinazione di PXE, DHCP e policy di rete.

Un esempio di estensione con PXE, da valutare con attenzione:

Add-CMDistributionPoint ` -SiteSystemServerName "DP01.contoso.local" ` -ClientCommunicationType HTTP ` -EnablePxe $true ` -PxePassword ""

La password non va mai scritta in chiaro in script condivisi o repository non protetti. Se serve automazione, usa un meccanismo di segreti gestito fuori banda o chiedi il valore in modo interattivo e poi redigilo nei log. Il punto non è essere eleganti: è evitare di lasciare credenziali in giro.

Script operativo consigliato: installazione idempotente e verificabile

In pratica conviene costruire uno script che controlli prima l’esistenza del server nel sito, poi aggiunga il site system e infine il ruolo solo se mancante. Così eviti duplicazioni e riduci gli errori da rerun.

Schema operativo:

  1. Importa il modulo Configuration Manager.
  2. Passa al drive del sito.
  3. Verifica che il server non abbia già il ruolo DP.
  4. Aggiungi il site system server se assente.
  5. Aggiungi il Distribution Point con i parametri richiesti.
  6. Controlla lo stato di provisioning nei log e nella console.

Esempio di controllo preliminare:

$server = "DP01.contoso.local"
$existing = Get-CMDistributionPoint -SiteSystemServerName $server -ErrorAction SilentlyContinue
if ($existing) { Write-Host "DP già presente"
} else { Write-Host "DP assente, pronto per l'installazione"
}

Se vuoi evitare sorprese, fai anche un controllo della reachability del server e della risoluzione DNS prima del cmdlet di installazione:

Test-Connection DP01.contoso.local -Count 2
Resolve-DnsName DP01.contoso.local

Se il nome risolve ma il ping fallisce, non è automaticamente un problema: in alcuni ambienti ICMP è bloccato. Quello che conta davvero è la connettività verso le porte usate da SCCM e la presenza di errori nei log del site server.

Validazioni post-installazione: non fidarti solo della console

La console mostra il ruolo, ma non ti dice se il DP è realmente operativo. Dopo l’installazione devi verificare almeno quattro cose: provisioning completato, content library presente, log coerenti e distribuzione contenuti funzionante.

I log da guardare dipendono dalla versione, ma in genere ti interessano quelli del site server e del server di ruolo, oltre ai log di distribuzione contenuti. Se non hai un riferimento preciso, cerca i file log relativi a distribution point, distmgr e site system install. La cosa importante è trovare l’errore al primo passaggio fallito, non aspettare che la console si aggiorni da sola.

Controlla anche lo stato del ruolo nella console, in particolare i campi di provisioning e lo stato di comunicazione. Se il DP compare ma resta in stato intermedio per troppo tempo, il problema è quasi sempre a monte: permessi, connettività, disco o un prerequisito mancato.

Un check utile lato PowerShell è interrogare la presenza del ruolo e l’associazione del server al site system:

Get-CMSiteSystemServer -SiteSystemServerName "DP01.contoso.local"
Get-CMDistributionPoint -SiteSystemServerName "DP01.contoso.local" | Select-Object ServerName, IsPXE, ClientCommunicationType

Se il comando restituisce oggetti corretti ma i client non scaricano contenuti, il problema spesso non è l’installazione del ruolo ma boundary group, fallback o content distribution non completata.

Boundary group e content location: il punto dove molti si fermano troppo presto

Installare il DP non basta. Devi anche fare in modo che i client lo scelgano. Se il boundary group non include quel DP o se il fallback è disabilitato, i client continueranno a cercare un’altra sorgente e sembrerà che il ruolo non funzioni.

In pratica, dopo l’installazione, verifica che il DP sia associato ai boundary group corretti e che i contenuti siano distribuiti ai package point giusti. Un contenuto non distribuito non è un problema del DP: è un problema di content management.

Se vuoi controllare rapidamente la distribuzione, puoi usare la console oppure interrogare gli oggetti di content status. L’obiettivo è vedere che i pacchetti necessari siano in stato OK e che non ci siano errori di transfer o hashing.

Osservazione pratica: in ambienti grandi il disallineamento più frequente è tra il ruolo installato e la disponibilità effettiva del contenuto. Il server risponde, ma il package non è ancora arrivato o è fallito durante la distribuzione. Questo genera ticket confusi, quindi conviene separare mentalmente “DP installato” da “content servito”.

Problemi tipici e lettura rapida del sintomo

Se il setup fallisce subito, il colpevole più probabile è un prerequisito mancante: permessi insufficienti, nome server non risolvibile, spazio insufficiente o firewall bloccante. Se il ruolo si installa ma resta in provisioning, guarda i log del site system e la raggiungibilità del server da parte del site server.

Se i client non scaricano contenuti, controlla prima boundary group e poi availability del package. Se il problema riguarda PXE, separa il ramo di troubleshooting: il DP può funzionare per content delivery e fallire solo per boot image e provisioning di rete.

Un errore frequente è confondere un problema di DNS con un problema di SCCM. Se il server cambia IP, se il record non si aggiorna o se ci sono alias incoerenti, il site server può continuare a puntare al nome giusto ma raggiungere l’host sbagliato o non raggiungerlo affatto.

Altro classico: disco quasi pieno. La content library cresce in fretta, e quando il volume si satura il comportamento degrada senza un evento unico e pulito. Qui la metrica da guardare è lo spazio libero reale sul volume della libreria, non quello della VM nel pannello hypervisor.

Rollback pulito: togliere il ruolo senza lasciare residui inutili

Se l’installazione è stata fatta male o hai scelto il server sbagliato, il rollback deve essere semplice e tracciabile. Prima rimuovi il ruolo Distribution Point dal server, poi verifica che il site system server non resti registrato se non ti serve più.

Il principio è questo: prima fai il rollback del ruolo, poi pulisci ciò che è stato creato in modo esplicito. Non cancellare directory a mano se non hai verificato che il ruolo sia stato disinstallato e che la content library non sia condivisa con altri servizi.

Verifica dopo la rimozione che il server non compaia più come DP nella console e che non ci siano più riferimenti nei log di provisioning. Se avevi previsto un percorso dedicato per la libreria, puoi rimuoverlo solo dopo aver confermato che non contiene dati utili o che questi siano stati migrati altrove.

Se il server ospitava anche altri ruoli, il blast radius del rollback è maggiore. In quel caso il rollback va limitato al solo ruolo SCCM, senza toccare IIS, WDS o altre dipendenze che non fanno parte della modifica.

Script finale di esempio con controlli minimi

Uno script operativo sensato non deve essere lungo per forza, ma deve essere leggibile e verificabile. Questo esempio mostra la sequenza minima da adattare al tuo ambiente:

Import-Module ConfigurationManager
cd XYZ: $server = "DP01.contoso.local"
$dp = Get-CMDistributionPoint -SiteSystemServerName $server -ErrorAction SilentlyContinue if (-not $dp) { New-CMSiteSystemServer -SiteSystemServerName $server Add-CMDistributionPoint ` -SiteSystemServerName $server ` -ClientCommunicationType HTTP ` -PrimaryContentLibraryLocation "D:\SCCMContentLib" ` -PrimaryPackageShareLocation "D:\SCCMPkgShare"
} Get-CMDistributionPoint -SiteSystemServerName $server | Select-Object ServerName, ClientCommunicationType, IsPXE

Questo non sostituisce la verifica della console o dei log, ma ti dà un punto di partenza ripetibile. Se aggiungi PXE o HTTPS, fallo in un secondo passaggio, non insieme al primo bootstrap del ruolo.

Decisione pratica: quando usare PowerShell e quando fermarsi

PowerShell è la scelta giusta quando vuoi ripetibilità, automazione e tracciamento. È meno adatto se stai facendo una modifica una tantum su un ambiente che non conosci e non hai ancora validato prerequisiti, naming e storage. In quel caso la console può aiutare a leggere meglio lo stato corrente, ma non deve sostituire i controlli tecnici.

La regola pratica è semplice: prima osserva, poi installa, poi verifica. Se una delle tre fasi manca, il rischio è ritrovarti con un DP “installato” ma non realmente utile ai client. In SCCM la differenza tra presente e operativo è tutto il lavoro che fai intorno al ruolo, non il cmdlet in sé.