1 15/04/2026 10 min

Installare un Distribution Point (DP) SCCM su Windows 10 si può fare, ma va trattato per quello che è: una soluzione utile per laboratori, test o ambienti di piccole dimensioni, non la scelta classica per produzione. Il punto non è solo “far partire il ruolo”, ma farlo in modo coerente con rete, storage, firewall e aspettative del client SCCM. Se il DP viene esposto male, il risultato è semplice: content download lento, errori PXE o policy che sembrano corrette ma non distribuiscono nulla.

Qui il focus è pratico: cosa serve prima, come installare il ruolo, quali verifiche fare subito e dove si rompe più spesso. L’obiettivo è avere un DP funzionante e diagnosticabile, non una procedura da wizard cieco.

Quando ha senso usare Windows 10 come Distribution Point

Un DP su Windows 10 ha senso quando devi validare un sito SCCM, fare demo, supportare un punto remoto temporaneo o creare un nodo di distribuzione leggero in un contesto non critico. In questi scenari il vincolo principale non è la scalabilità, ma la semplicità operativa. Il compromesso è evidente: Windows 10 non è pensato per ospitare ruoli server in modo robusto, quindi devi aspettarti limiti su hardening, lifecycle e supportabilità.

Se stai progettando una infrastruttura stabile, il riferimento resta Windows Server. Se invece vuoi un DP per prove controllate, Windows 10 può andare bene purché tu tenga sotto controllo versioni, permessi, spazio disco e raggiungibilità di rete.

Prerequisiti minimi prima di aprire il wizard

Prima di installare il ruolo, verifica questi punti. Sono banali, ma sono anche quelli che fanno perdere più tempo quando vengono dati per scontati.

  1. Il client Windows 10 deve essere in dominio e gestito dal site SCCM. In ambienti lab puoi usare account locali, ma appena entra in gioco Kerberos o autenticazione verso il management point, il dominio semplifica tutto.

  2. La macchina deve avere spazio disco reale. Per un DP piccolo, considera almeno 100 GB liberi come base, di più se distribuisci immagini, application package o update content. Il contenuto SCCM cresce in fretta e il problema emerge tardi, quando il DP è già pieno.

  3. Firewall e porte devono essere coerenti. Il DP deve essere raggiungibile dai client sulla porta HTTP o HTTPS in base alla tua configurazione. Se usi IIS con HTTPS, il certificato deve essere valido e con nome coerente con il FQDN del DP.

  4. Nome host e DNS devono essere corretti. SCCM si appoggia molto alla risoluzione del nome. Un record DNS sbagliato o un alias non allineato produce errori che sembrano di contenuto ma sono di naming.

  5. Il server SCCM deve essere sano. Se il site ha problemi di component status, replication o boundary group, il DP non risolve il problema a valle.

Controllo rapido lato client:

hostname
ipconfig /all
nslookup dp01.contoso.local
Test-NetConnection dp01.contoso.local -Port 80
Test-NetConnection dp01.contoso.local -Port 443

Se uno di questi test fallisce, non ha senso proseguire con l’installazione del ruolo prima di aver chiuso il gap. Un DP “installato” ma non raggiungibile è solo rumore operativo.

Installazione del ruolo da console SCCM

La via più pulita è il Configuration Manager Console. Dal punto di vista operativo, riduce errori di sintassi e ti fa allineare il ruolo con il site in modo più sicuro rispetto a una configurazione manuale del solo IIS.

  1. Apri la console SCCM e vai in Administration → Site Configuration → Servers and Site System Roles.

  2. Seleziona il computer Windows 10 che ospiterà il DP. Se non è già presente come site system, aggiungilo come server del site system.

  3. Avvia Add Site System Roles e conferma il nome host corretto.

  4. Seleziona il ruolo Distribution point.

  5. Decidi il protocollo: HTTP per ambienti di test o HTTPS se vuoi allinearti a un modello più rigoroso. In HTTPS verifica prima il certificato, altrimenti il wizard parte e la distribuzione fallisce dopo.

  6. Abilita solo le opzioni che ti servono davvero: multicast, PXE, prestaged content, unknown computer support. Ogni spunta aggiunge complessità e superficie di errore.

  7. Completa il wizard e attendi la configurazione del ruolo.

Se vuoi capire cosa sta succedendo mentre il wizard lavora, controlla i log lato site server. I nomi più utili sono distmgr.log, smsprov.log e, sul client che ospita il DP, smsdpprov.log o i log collegati alla configurazione del ruolo. Non serve memorizzarli tutti: basta sapere dove cercare quando il DP risulta “installed” ma non distribuisce contenuti.

Quando usare PowerShell o IIS manuale

In generale il DP va creato dalla console SCCM, non montato a mano con IIS. Il motivo è semplice: SCCM deve conoscere il site system, registrare il ruolo e pubblicare i contenuti nel modo corretto. Toccare IIS senza passare dal site rischia di creare un server che risponde in HTTP ma non è un Distribution Point valido per il management point.

PowerShell torna utile per verifiche e automazione, non come sostituto del provisioning del ruolo. Puoi usarlo per testare porte, stato del servizio, membership di gruppi o presenza di feature Windows. Per esempio:

Get-Service -Name ccmexec, smsdpprov -ErrorAction SilentlyContinue
Get-WindowsFeature | Select-String -Pattern IIS
Get-NetFirewallRule | Where-Object {$_.DisplayName -like '*HTTP*' -or $_.DisplayName -like '*IIS*'}

Su Windows 10 non aspettarti la stessa esperienza di Windows Server. Alcune feature sono presenti ma il contesto di supporto è diverso. Per questo conviene limitarsi alle opzioni strettamente necessarie.

Verifiche subito dopo l’installazione

Il momento giusto per scoprire un problema non è quando il primo client prova a scaricare un package. Appena il ruolo risulta installato, fai queste verifiche.

  1. Stato del ruolo nella console: il server deve risultare con il ruolo Distribution point attivo e senza warning evidenti.

  2. Reachability HTTP/HTTPS: da un client nella stessa boundary, prova la connessione al DP.

  3. Log del site server: cerca errori di provisioning o di registrazione ruolo nei log SCCM.

  4. Spazio disco: verifica che il content library non stia saturando il volume destinato al DP.

  5. Servizi SCCM: controlla che i servizi coinvolti siano in esecuzione e stabili.

Test di reachability base:

curl -I http://dp01.contoso.local/sms_dp_smspkg$/

Se usi HTTPS, il test deve restituire un TLS valido e non un certificato autofirmato non attendibile dai client. Un errore qui non è cosmetico: gli endpoint SCCM possono sembrare presenti ma non scaricare nulla.

Content library, boundary group e distribuzione reale dei pacchetti

Un DP non serve a niente se il contenuto non viene distribuito correttamente. Dopo l’installazione del ruolo devi lavorare su tre elementi: content library, distribuzione del package e boundary group.

  1. Distribuisci un package di test piccolo, meglio se un file innocuo con dimensione contenuta.

  2. Assegna il DP al boundary group corretto. Senza boundary, il client può vedere il site ma non scegliere il punto di distribuzione giusto.

  3. Monitora la console nella sezione di monitoring per vedere se il content status passa da in-progress a success.

  4. Controlla lato client la cartella cache e i log di download. Il client deve effettivamente recuperare il contenuto dal DP e non da un altro punto di fallback.

Un errore tipico è considerare completata l’installazione del DP quando in realtà manca l’associazione ai boundary group. Il server è pronto, ma i client non lo useranno mai. Qui il sintomo non è un crash: è silenzio.

Hardening minimo e rischi da non ignorare

Mettere un DP su Windows 10 significa accettare una superficie d’attacco più ampia rispetto a un server dedicato. Il minimo sindacale è limitare le esposizioni e non lasciare servizi inutili attivi.

  • Disabilita ciò che non usi: PXE, multicast e supporto unknown computer solo se davvero necessari.

  • Usa HTTPS se il modello lo richiede: aumenta il controllo sull’identità del server, ma introduce il tema certificati e rinnovi.

  • Riduci i privilegi: il computer account e gli account di gestione devono avere solo le autorizzazioni necessarie nel contesto SCCM.

  • Monitora il disco: il contenuto replicato può saturare il volume e trasformare il DP in un collo di bottiglia.

Se il DP è esposto oltre la LAN o in una rete poco fidata, il rischio non è solo operativo ma anche di sicurezza. In quel caso devi valutare se il modello di deployment regge davvero su Windows 10 o se è il caso di spostare il ruolo su un host più adatto.

Problemi comuni e come riconoscerli in fretta

Quando qualcosa non va, la diagnosi rapida parte quasi sempre dal layer sbagliato. Meglio seguire una sequenza semplice: rete, servizio, contenuto, boundary, client.

  1. DNS errato: il client risolve un nome diverso o un vecchio IP. Verifica con nslookup e confronta il record con l’indirizzo reale.

  2. Firewall o porta chiusa: il server risponde in locale ma non da remoto. Verifica con Test-NetConnection.

  3. Certificato non valido: in HTTPS il DP sembra attivo ma i client non si fidano del certificato o del nome soggetto.

  4. Boundary group mancante: il client è sano ma non seleziona il DP perché non appartiene al boundary corretto.

  5. Content non distribuito: il package non è stato realmente copiato sul DP, quindi il client riceve errori di download.

Log utili da controllare: lato site server distmgr.log, lato client SCCM i log di download e policy, lato DP i log relativi alla distribuzione del contenuto. Se non sai dove guardare, il primo passo è sempre confermare che il nome host del DP e la porta siano corretti prima di inseguire problemi applicativi.

Rollback e rimozione del ruolo

Se il DP su Windows 10 non è più necessario o introduce instabilità, il rollback deve essere semplice: rimuovi il ruolo dalla console SCCM, verifica che il content status si svuoti e poi pulisci eventuali residui solo dopo aver confermato che nessun client dipende più da quel punto di distribuzione.

  1. Rimuovi il ruolo Distribution point dal server nella console SCCM.

  2. Controlla che i package non risultino più assegnati a quel DP.

  3. Verifica che i client abbiano un altro DP valido nel boundary group.

  4. Solo dopo, valuta la disinstallazione delle componenti accessorie o la pulizia del contenuto locale.

Prima di fare cleanup manuale, conserva uno snapshot o almeno un inventario dei file e delle impostazioni toccate. Su un host usato come DP, cancellare contenuto a mano senza sapere cosa è ancora referenziato dal site è il modo più rapido per creare un problema nuovo.

Checklist finale operativa

  • Il server Windows 10 è raggiungibile per nome e IP.

  • Il ruolo Distribution point risulta installato nella console SCCM.

  • I client nel boundary corretto scaricano davvero il contenuto.

  • Il disco del DP ha margine sufficiente e non mostra saturazione.

  • I log SCCM non riportano errori continui di registrazione, certificato o content transfer.

Se vuoi un criterio pratico per capire se la configurazione è buona, usa questo: un client nuovo nella boundary corretta deve riuscire a trovare il DP, risolverne il nome, scaricare un piccolo package di test e completare l’installazione senza interventi manuali. Se uno di questi passaggi si rompe, il problema non è “SCCM in generale”, ma uno dei livelli che hai configurato sopra.

In sintesi: Windows 10 come Distribution Point SCCM è una scelta da usare con giudizio. Funziona bene quando il contesto è piccolo, controllato e ben osservato. Appena aumentano scala, criticità o requisiti di sicurezza, conviene spostarsi su un host più adatto e trattare il DP come componente infrastrutturale vero, non come estensione del desktop.