1 04/05/2026 9 min

Importare aggiornamenti in SCCM senza sporcare la console

In SCCM, importare aggiornamenti non significa solo “scaricare qualcosa” e farlo comparire in console. Il punto vero è tenere allineati catalogo, prerequisiti, classificazioni, lingue, supersedence e distribuzione ai client. Se si salta un passaggio, il risultato tipico è un update presente ma non distribuibile, oppure distribuibile ma mai installato perché manca una dipendenza, una baseline o una maintenance window coerente.

La procedura corretta dipende dal tipo di contenuto: aggiornamenti software Microsoft, driver, hotfix, feature update, oppure pacchetti custom. Qui il caso più comune è l’importazione di aggiornamenti software in un ambiente Microsoft Configuration Manager, con approccio operativo da produzione: prima si valida la sorgente, poi si importa, poi si distribuisce in modo progressivo, e solo alla fine si allarga il blast radius.

Prima di importare: controlli che evitano mezz’ora di troubleshooting dopo

La maggior parte dei problemi nasce prima del click su “Import”. Se la sincronizzazione con il catalogo è sporca, se WSUS non è in salute, o se il server SCCM non riesce a raggiungere i repository Microsoft, l’importazione si traduce in errori poco leggibili e in una coda di cleanup manuale.

Verifica almeno questi punti:

  1. Il ruolo Software Update Point è attivo e sincronizzato.
  2. La console vede prodotti e classificazioni coerenti con ciò che vuoi importare.
  3. Lo spazio su disco sui path di content library e WSUS è sufficiente.
  4. Il server ha connettività verso i servizi Microsoft necessari.
  5. Hai definito una collection pilota per il test iniziale.

Se uno di questi punti è incerto, non andare avanti a tentativi. Prima raccogli evidenza: log, stato sync, e spazio libero. In SCCM, i log giusti contano più della console, perché la UI spesso ti mostra solo l’effetto finale dell’errore, non la causa.

Importazione da console: il flusso più pulito

Per gli aggiornamenti Microsoft, il percorso più lineare è la console di Configuration Manager. Il vantaggio è che l’oggetto importato viene subito gestito nel contesto corretto: metadata, classificazione, lingua, supersedence e distribuzione ai DP seguono le regole del sito invece di essere assemblati a mano.

Il flusso tipico è questo:

  1. Apri Software Library e vai su Software Updates.
  2. Avvia la sincronizzazione, se il catalogo non è già aggiornato.
  3. Individua l’update per KB, prodotto o classificazione.
  4. Verifica che siano presenti lingua, architettura e prerequisiti corretti.
  5. Importa o approva l’update secondo il modello di governance del sito.
  6. Crea o aggiorna il software update group.
  7. Distribuisci prima alla collection pilota.

La differenza operativa la fa la selezione iniziale. In ambienti grandi, non basta cercare per KB: conviene filtrare per prodotto e classificazione, altrimenti importi roba che poi resta fuori target per policy. Un errore frequente è includere versioni cumulative già supersedute, pensando che “più update” equivalga a “più copertura”. In realtà ottieni solo più rumore e più peso sulla content library.

Importazione da Microsoft Update Catalog: quando la console non basta

Ci sono casi in cui il contenuto va preso dal Microsoft Update Catalog e poi gestito in SCCM. Succede spesso per aggiornamenti fuori ciclo, hotfix specifici o pacchetti che non emergono bene nella normale sincronizzazione. Qui il rischio è importare il file sbagliato o il pacchetto giusto per la piattaforma sbagliata.

Approccio pratico:

  1. Identifica esattamente il KB e la build target.
  2. Scarica il pacchetto corretto per architettura e lingua.
  3. Confronta dimensione e nome file con la documentazione Microsoft.
  4. Importa il contenuto nella raccolta software update o nel meccanismo previsto dal tuo processo interno.
  5. Assegna il contenuto a un gruppo di aggiornamenti o a una deployment ring.

Se il pacchetto è un .msu o un .cab, non dare per scontato che sia direttamente installabile da SCCM senza verifica. Alcuni contenuti richiedono passaggi intermedi, altre volte vanno trattati come applicazioni o task sequence dependency. Il punto è semplice: il file giusto non è ancora il deployment giusto.

Prendere confidenza con i log giusti

Quando l’import fallisce o sembra completarsi ma l’update non compare come atteso, i log sono il riferimento più affidabile. In un ambiente SCCM standard, i file più utili dipendono dal punto del flusso che stai osservando: sincronizzazione, catalogo, distribuzione contenuto, o installazione lato client.

Controlla almeno questi percorsi, adattandoli alla tua installazione:

  • C:\Program Files\Microsoft Configuration Manager\Logs\Wsyncmgr.log per la sincronizzazione degli update.
  • C:\Program Files\Microsoft Configuration Manager\Logs\wsusctrl.log per il controllo del ruolo WSUS/SUP.
  • C:\Program Files\Microsoft Configuration Manager\Logs\PatchDownloader.log per il download del contenuto.
  • C:\Windows\CCM\Logs\UpdatesDeployment.log sul client per la fase di deployment.
  • C:\Windows\CCM\Logs\WUAHandler.log per il dialogo con Windows Update Agent.

Se il problema è lato server, cerca errori di download, certificati, proxy, o accesso negato. Se il problema è lato client, guarda detection, evaluation e installazione. Non mischiare i due livelli: spesso si perde tempo a inseguire il client quando la root cause è una sync incompleta sul server.

Importare aggiornamenti con PowerShell: utile quando il processo va standardizzato

In ambienti con governance seria, la console non basta. Serve una procedura ripetibile, con controlli e output verificabili. PowerShell è la strada naturale per automatizzare parti del processo, soprattutto se devi estrarre update, creare gruppi, o verificare proprietà prima della distribuzione.

Un esempio pratico è l’uso del modulo ConfigurationManager sul server o su una workstation amministrativa con accesso al sito:

Import-Module ($env:SMS_ADMIN_UI_PATH.Substring(0, $env:SMS_ADMIN_UI_PATH.Length - 5) + '\ConfigurationManager.psd1')
cd XYZ:
Get-CMSoftwareUpdate -ArticleID 5030211 | Select-Object ArticleID, LocalizedDisplayName, IsSuperseded, IsExpired

Questo non importa ancora nulla, ma ti fa già fare il controllo più importante: stai guardando l’oggetto giusto? Se l’update risulta superseded o expired, non ha senso spingerlo in produzione salvo casi particolari di compatibilità. Se il titolo non coincide con il KB atteso, fermati e ricontrolla il catalogo.

Per creare un gruppo di aggiornamenti e aggiungere l’update selezionato, il flusso può essere simile al seguente:

$u = Get-CMSoftwareUpdate -ArticleID 5030211
New-CMSoftwareUpdateGroup -Name 'Patching-Pilot-2025-05'
Add-CMSoftwareUpdateToGroup -SoftwareUpdateGroupName 'Patching-Pilot-2025-05' -SoftwareUpdate $u

Il valore non è tanto il comando in sé, quanto la tracciabilità. Se automatizzi, salva sempre l’input usato: KB, title, build, timestamp, e collection target. In caso di errore, ti serve poter risalire a cosa è stato importato e con quali parametri.

Distribuzione corretta: prima pilot, poi broad

Il punto più delicato non è importare, ma distribuire. In SCCM, un update può essere tecnicamente corretto e comunque creare problemi se lo mandi a tutta la flotta senza un test di compatibilità. Le eccezioni più comuni sono driver particolari, software legacy, e update che interagiscono con agent o middleware specifici.

Usa sempre una sequenza a cerchi concentrici:

  1. Collection pilota con macchine rappresentative.
  2. Collection secondaria con un sottoinsieme più ampio.
  3. Distribuzione globale solo dopo verifica di installazione e stabilità.

Definisci in anticipo la metrica di successo. Per un update, le metriche utili sono: percentuale di installazione riuscita, error rate, numero di reboot pendenti, e tempo medio di compliance. Se dopo il pilot vedi aumento di errori 0x87d00664, 0x80070005 o installazioni bloccate in pending reboot, non allargare il deployment prima di capire il motivo.

Supersedence, expirations e cleanup: il punto che si dimentica sempre

Importare aggiornamenti senza gestire supersedence e scadenza è un modo elegante per riempire il database e complicare le ricerche. In ambienti maturi, il ciclo di vita dell’update va chiuso: ciò che è superseded va marcato correttamente, ciò che non serve più va rimosso secondo policy, e il contenuto distribuito va ripulito quando non è più richiesto.

Osserva almeno questo comportamento:

  • Gli update recenti devono risultare attivi e distribuiti solo dove serve.
  • Gli update superseduti non devono continuare a essere il target principale dei deployment nuovi.
  • Il content library non deve crescere senza controllo dopo ogni ciclo mensile.

Se il cleanup è assente, la console diventa lenta e la manutenzione diventa fragile. Non è un problema estetico: è un problema operativo che si traduce in più tempo per trovare l’oggetto giusto e in maggior rischio di errore umano.

Verifica finale: cosa deve essere vero prima di considerare chiuso il lavoro

Dopo l’importazione, la verifica non si limita a “vedo l’update in console”. Devi controllare che il contenuto sia coerente dal server al client.

  1. L’update è presente nel gruppo previsto.
  2. Il deployment è assegnato alla collection corretta.
  3. Il content status sui distribution point è green o comunque coerente con il piano di rollout.
  4. Il client pilota riceve la policy e vede l’update come disponibile.
  5. L’installazione completa genera un esito verificabile nei log client.

Un controllo rapido lato client può essere fatto anche da PowerShell, per verificare la presenza di aggiornamenti e la gestione dell’agent Windows Update, ma il punto resta sempre lo stesso: non fidarti di un singolo pannello. Incrocia console, log e comportamento reale del client.

Se stai lavorando in produzione, l’ultima verifica utile è una finestra di osservazione dopo il deployment: niente aumento anomalo di errori, niente saturazione dei DP, niente reboot storm, niente code insolite in CCM. Se qualcosa si muove fuori baseline, metti in pausa l’estensione del rollout.

Rollback pratico quando l’update importato crea problemi

Il rollback in SCCM non è sempre “annulla” in un clic. Dipende da dove sei arrivato. Se il problema è solo il deployment, la misura più sicura è disattivare o limitare l’assegnazione alla collection pilota. Se il problema è il contenuto distribuito, puoi revocare la distribuzione o rimuovere il software update group dal piano di rollout. Se il problema è un update già installato e incompatibile, la strategia diventa diversa e va valutata con attenzione, perché entra in gioco il rischio applicativo e di reboot.

Rollback minimo e reversibile:

  1. Disabilita il deployment verso la collection ampia.
  2. Lascia attivo solo il pilot per raccogliere evidenza.
  3. Controlla i log server e client per capire se il problema è di import, distribuzione o installazione.
  4. Se necessario, sospendi la sincronizzazione del ciclo corrente prima di importare altro contenuto.

Il blast radius è semplice da definire: più alta è la collection target, più alto è il rischio. Per questo il pilot non è una formalità, ma il punto di sicurezza che ti evita di scoprire un problema su migliaia di endpoint.

Procedura operativa sintetica da riusare ogni mese

Se vuoi una sequenza che regga anche sotto pressione, usa sempre lo stesso schema:

  1. Valida sincronizzazione e salute del SUP.
  2. Identifica update, KB, build e supersedence.
  3. Importa solo il contenuto necessario.
  4. Metti l’update in un gruppo di test.
  5. Distribuisci alla collection pilota.
  6. Controlla log, compliance e reboot pending.
  7. Espandi solo dopo evidenza positiva.

Questa è la parte che fa davvero la differenza in una community IT: non importare “più in fretta”, ma importare in modo ripetibile, verificabile e reversibile. In SCCM, la qualità del processo pesa più della singola operazione. Se il processo è chiaro, l’import degli aggiornamenti diventa una routine; se è confuso, ogni patch Tuesday si trasforma in troubleshooting.

Assunzione: ambiente Microsoft Configuration Manager on-prem o ibrido, con Software Update Point già configurato e accesso amministrativo alla console e ai log del sito.