In SCCM una regola di distribuzione automatica non va trattata come un semplice automatismo “comodo”: è un meccanismo che decide cosa scaricare, quando distribuirlo e su quali gruppi spingerlo. Se la logica è scritta male, il risultato tipico è uno di questi tre casi: pacchetti che arrivano troppo presto, contenuti che si accumulano senza controllo oppure client che ricevono update non coerenti con l’anello di test. La differenza la fanno i criteri, la programmazione e il perimetro di destinazione.
La strada corretta è partire dal flusso reale: definisci la sorgente del contenuto, il tipo di distribuzione, il livello di approvazione e il target di raccolta. Solo dopo si passa alla regola. Se salti questi passaggi, finisci a correggere sintomi invece di governare il ciclo di rilascio.
Quando usare una ADR in SCCM
La Automatic Deployment Rule ha senso quando vuoi standardizzare il rilascio di aggiornamenti software o firmware in base a criteri ripetibili: classificazione, prodotto, severità, data di rilascio, supersedence, lingua, oppure un insieme di queste condizioni. In ambienti medi o grandi, la ADR riduce il lavoro manuale e, soprattutto, evita che il team scelga ogni volta criteri diversi a seconda della pressione operativa.
Non è la scelta giusta se stai gestendo un rilascio eccezionale, un hotfix delicato o un pacchetto con dipendenze particolari che richiedono validazione manuale. In quel caso conviene creare prima la distribuzione in modo controllato e solo dopo, se il pattern si ripete, trasformarla in regola.
Prerequisiti da verificare prima di creare la regola
Prima di aprire la console, conviene verificare tre punti: la sincronizzazione del catalogo, la salute dei componenti di distribuzione e la presenza della raccolta di destinazione. Se uno di questi tre elementi è debole, la regola può essere formalmente corretta ma praticamente inutile.
Le verifiche minime che faccio di solito sono queste:
- la sincronizzazione del Software Update Point è completata e non in errore;
- il punto di distribuzione ha spazio e contenuto coerente;
- la collection di test esiste ed è vuota o quasi vuota, così da non colpire subito un parco macchine ampio.
Se ti manca un dato, non forzarlo a intuito. Controlla i log lato server e i contatori della console: è meglio fermarsi due minuti che correggere una regola dopo aver spinto un set sbagliato di aggiornamenti.
Creazione della regola dalla console
Il percorso può cambiare leggermente in base alla versione di Configuration Manager, ma la logica resta la stessa. Entra nella console, vai nell’area di gestione degli aggiornamenti software e apri la sezione dedicata alle regole automatiche. Da lì avvii la creazione guidata.
- Apri la console SCCM e vai in Software Library.
- Espandi Software Updates e poi Automatic Deployment Rules.
- Avvia la creazione di una nuova regola.
- Assegna un nome descrittivo che includa finestra, anello o ambito, per esempio ADR-Win11-Pilot-Monthly.
- Seleziona il tipo di aggiornamento da includere: cumulative, security, definition o altro filtro coerente con il tuo processo.
- Definisci i criteri di ricerca: classificazione, prodotto, lingua, severità, supersedence e data di rilascio.
- Scegli la raccolta di destinazione, partendo idealmente da un gruppo pilota.
- Imposta la distribuzione verso un distribution point group o un gruppo di DP già validato.
- Definisci la pianificazione: sincronizzazione, valutazione e deployment.
- Salva e lancia un primo test controllato.
La parte più importante non è il click finale, ma il filtro della query. Se la query è troppo ampia, la regola diventa rumorosa; se è troppo stretta, rischi di non distribuire nulla e di accorgertene solo quando gli endpoint restano indietro di un ciclo.
Criteri che conviene impostare con attenzione
La qualità della distribuzione dipende quasi sempre dal filtro. I criteri più sensibili sono pochi, ma vanno usati con disciplina.
Classificazione e prodotto
Seleziona solo le classificazioni che ti servono davvero. In molti ambienti la tentazione è includere tutto ciò che sembra “sicurezza”, ma così si mescolano update con impatto diverso. Lo stesso vale per i prodotti: se gestisci più versioni di Windows o applicazioni Microsoft, distinguile in modo esplicito. Un filtro generico può trascinare dentro contenuti che il parco non usa più.
Supersedence
La gestione della supersedence è utile, ma va capita. Se la abiliti senza verificare il comportamento delle release precedenti, puoi ritrovarti con una catena di sostituzioni che rende difficile capire quale update stia davvero andando in distribuzione. In pratica: utile per alleggerire, pericolosa se non sai leggere il grafo dei rimpiazzi.
Lingua e data di rilascio
La lingua è spesso sottovalutata. In ambienti multilingua, lasciare aperto questo criterio può introdurre contenuti non necessari e aumentare il volume di distribuzione. La data di rilascio serve invece per evitare che la regola agganci update troppo vecchi o appena pubblicati, prima che abbiano avuto il tempo di stabilizzarsi nel catalogo.
Scelta della raccolta di destinazione
La collection non è un dettaglio amministrativo: è il confine operativo della regola. La pratica più sana è usare almeno tre anelli: test, pilot e produzione. Se non hai questa separazione, una ADR ben fatta ti aiuta poco perché non esiste un gradiente di rischio.
Un esempio concreto: se una nuova cumulative update deve arrivare a 20 macchine IT prima di finire su tutte le workstation, crea una collection dedicata a quelle 20 macchine e usa quella come destinazione iniziale. Solo dopo un esito positivo sposti il deployment verso un gruppo più ampio. Questo approccio riduce il blast radius e semplifica il rollback.
Se la collection è dinamica, controlla bene i membership rule. Una query troppo generica può includere device appena aggiunti al dominio o endpoint temporanei usati per test. In quel caso la regola non sbaglia per sé: sbaglia il perimetro.
Programmazione, deadline e finestre di manutenzione
La pianificazione in SCCM va pensata con due tempi distinti: quando la regola cerca i contenuti e quando i client li installano. Se lasci tutto immediato, perdi il controllo del ritmo di rilascio. Se ritardi troppo, accumuli backlog e rendi più difficile distinguere un problema della regola da un problema di finestra di manutenzione.
Le impostazioni che conviene allineare sono:
- orario di valutazione della regola;
- scadenza del deployment;
- rispetto delle maintenance window;
- comportamento fuori finestra, se previsto dal tuo standard interno.
Qui il consiglio pratico è semplice: inizia con una finestra prevedibile, non con un rilascio continuo. La prevedibilità è più utile della velocità quando stai verificando se la regola produce davvero il set di update atteso.
Distribuzione del contenuto: DP, gruppi e pre-staging
Una regola di distribuzione automatica non vive da sola. Deve appoggiarsi a un contenuto già distribuibile verso i Distribution Point corretti. Se il contenuto non arriva al DP, i client non scaricano nulla anche se la regola è perfetta.
Per ambienti con più sedi, ha senso usare gruppi di DP coerenti con il traffico e con la latenza. In presenza di collegamenti deboli o saturi, distribuire tutto ovunque è il modo più rapido per creare un problema di rete invece che un problema di patching.
Quando puoi, fai pre-staging del contenuto o almeno verifica che i package siano già presenti sul DP prima dell’orario di attivazione. Il controllo più semplice è la coerenza tra stato del contenuto nella console e presenza reale dei file nella share o nel path locale del DP, secondo l’architettura adottata.
Verifica operativa dopo la creazione
Dopo aver creato la regola, non fermarti allo stato “abilitata”. Devi verificare tre cose: che la query trovi davvero gli aggiornamenti, che il deployment venga creato e che il contenuto si propaghi ai punti giusti.
- Forza una sincronizzazione o attendi il ciclo previsto dalla tua configurazione.
- Controlla nella console che la regola abbia prodotto un deployment attivo.
- Verifica il numero di update selezionati e confrontalo con l’atteso.
- Controlla i log lato server, in particolare quelli dell’area Software Updates, per eventuali errori di query o di distribuzione.
- Su un client pilota, verifica la comparsa della policy e l’avvio della scansione aggiornamenti.
Se il numero di aggiornamenti selezionati è zero, non dare per scontato che il problema sia SCCM. Spesso il filtro è semplicemente troppo stretto o il catalogo non è ancora allineato. La differenza si vede confrontando la query della regola con i metadati effettivamente presenti nel catalogo sincronizzato.
Errori tipici che fanno perdere tempo
Il primo errore è usare la collection di produzione come test. Il secondo è creare una regola corretta ma senza un contenuto già disponibile sul DP. Il terzo è non distinguere tra update approvati e update solo rilevati: SCCM può vedere il contenuto prima che venga davvero reso disponibile ai client nel modo atteso.
Un altro punto ricorrente è la mancata corrispondenza tra nomenclatura e funzione. Se chiami una regola in modo vago, dopo qualche mese nessuno ricorda più perché esista, chi la mantenga o quali criteri usi. Nelle infrastrutture reali, la documentazione utile è quella che ti permette di capire al volo il perimetro operativo senza aprire dieci schermate.
Rollback e riduzione dell’impatto
Il rollback di una ADR non è complicato, ma va fatto con metodo. Se la regola è troppo aggressiva, la prima mossa è disabilitarla o spostarne la destinazione su una collection vuota di quarantena. Questo ti permette di fermare la propagazione senza cancellare il lavoro di configurazione.
- Disabilita temporaneamente la regola oppure rimuovi il deployment verso la collection ampia.
- Verifica che nessun nuovo deployment venga generato dopo il ciclo successivo.
- Conserva la configurazione per l’analisi, invece di ricrearla da zero.
- Rivedi i criteri uno alla volta: classificazione, prodotto, supersedence, lingua, data.
- Riapri il rollout solo dopo aver validato il comportamento sulla collection pilota.
Il blast radius va sempre tenuto presente: una regola sbagliata su una collection da 30 endpoint si corregge in fretta; la stessa regola su migliaia di client può saturare banda, aumentare ticket e complicare il supporto. Per questo il primo deployment deve essere sempre il più piccolo possibile, anche quando la pressione operativa spinge a fare il contrario.
Un modello pratico che funziona quasi sempre
Se vuoi una struttura semplice e robusta, usa questo schema: una ADR per il pilot, una ADR per il production ring e una collection separata per eccezioni o macchine in hold. In questo modo separi il ciclo di validazione dal ciclo di rilascio e riduci la confusione tra problemi di catalogo, problemi di distribuzione e problemi lato client.
La vera utilità di una regola automatica non è “fare tutto da sola”, ma rendere ripetibile un processo che altrimenti dipende dalla memoria operativa di chi è di turno. Quando la regola è costruita bene, il team smette di inseguire gli update e inizia a governarli.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.