In SCCM non esiste un unico gesto che “annulla” tutto: bisogna distinguere tra la rimozione del deployment dal client, la disinstallazione del contenuto già applicato e il ripristino del comportamento atteso dopo il ciclo successivo di valutazione. Se l’obiettivo è togliere una patch distribuita tramite Configuration Manager, il punto di partenza è sempre capire se si tratta di un aggiornamento software, di un package/script, oppure di un deployment che ha già prodotto modifiche permanenti sul sistema.
Capire cosa vuoi davvero annullare
Nel linguaggio operativo di SCCM, “patch” può voler dire cose diverse. Se hai distribuito un aggiornamento Windows tramite Software Updates, puoi rimuovere il deployment dal collection e, se l’aggiornamento lo consente, disinstallarlo dal client. Se invece hai usato un package, un task sequence o uno script, l’effetto potrebbe non essere reversibile in modo automatico e va gestito con un rollback dedicato.
Il caso più comune è quello di un aggiornamento cumulativo o di sicurezza installato sui client. Qui la sequenza corretta è: verificare il KB, capire se è disinstallabile, sospendere o rimuovere il deployment per evitare che torni a installarsi, quindi eseguire la disinstallazione sul client interessato e controllare che il sistema non tenti di riapplicarlo al successivo ciclo di scansione.
Verifiche preliminari su console e client
Prima di toccare la console, conviene raccogliere tre dati: il nome esatto del deployment, il KB o identificativo dell’aggiornamento, e il collection target. In console, apri la sezione Software Library e verifica se la distribuzione arriva da Software Updates oppure da Applications o Packages. Questo cambia completamente il rollback.
Dal lato client, conferma che l’aggiornamento sia effettivamente presente. Un controllo rapido si può fare con PowerShell, ad esempio cercando il KB installato tra gli hotfix noti dal sistema:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20Se il KB non compare, il problema non è la disinstallazione ma la valutazione del deployment, la supersedence o un altro canale di installazione. Se compare, annota il numero KB e verifica se esiste un parametro di rimozione supportato dal pacchetto Microsoft corrispondente. Non tutti gli update sono disinstallabili: alcuni cumulativi o componenti di piattaforma non lo sono in modo pulito.
Rimuovere il deployment in SCCM per bloccare la riapplicazione
La prima mossa sicura è impedire che la patch torni a installarsi. In console, vai sul deployment dell’update e rimuovi l’associazione al collection oppure imposta lo stato su non più disponibile, a seconda del tipo di oggetto. Se il deployment è pilotato da una maintenance window o da una deadline, valuta anche la sospensione temporanea del target collection per evitare nuovi tentativi durante il rollback.
In termini operativi, il test minimo è semplice: dopo la modifica, il client non deve più vedere l’aggiornamento come “required” alla successiva policy retrieval. Se l’oggetto resta applicabile, il rischio è che la disinstallazione venga annullata dal ciclo successivo o che il client reinstalli la patch alla prima scansione utile.
Se vuoi una verifica lato client, forza un ciclo di policy e controlla gli ultimi eventi del client SCCM. Un approccio tipico è avviare il machine policy retrieval e poi osservare il comportamento del software update scan. La verifica corretta non è “la console dice tutto bene”, ma “il client non riceve più il comando di installazione”.
Disinstallare un aggiornamento Windows dal client
Quando l’aggiornamento è disinstallabile, il comando più diretto è wusa.exe con il parametro di uninstall. È la strada classica per molti KB, soprattutto su client Windows e server recenti. La sintassi di base è la seguente:
wusa.exe /uninstall /kb:5000000 /quiet /norestartSostituisci 5000000 con il KB reale. Il parametro /quiet evita finestre interattive, mentre /norestart impedisce il riavvio automatico. Questo è utile in produzione, ma significa che il sistema potrebbe restare in stato intermedio finché non pianifichi il reboot. Il blast radius è limitato al singolo host, ma l’impatto applicativo può essere alto se il servizio dipende dal riavvio per completare il rollback.
Se non vuoi procedere in modo silenzioso, puoi omettere /quiet per osservare eventuali prompt o errori. In alternativa, usa PowerShell per verificare lo stato del sistema prima e dopo l’operazione:
Get-WindowsPackage -Online | Where-Object {$_.PackageState -eq 'Installed'}Non tutti gli aggiornamenti gestiti da SCCM passano da wusa.exe. Alcuni componenti sono package CBS, altri sono feature update o cumulative che richiedono procedure diverse. Se wusa restituisce che l’update non è installato o non è disinstallabile, la verifica successiva è leggere il log del Windows Update Agent e del client SCCM per capire se il KB è stato applicato da un canale differente.
Quando la patch è stata distribuita come application o package
Se in SCCM non stai parlando di un aggiornamento software ma di un package, uno script o un’application model, il rollback va gestito in modo diverso. In questi casi la disinstallazione può essere un comando definito dall’installer originale, un PowerShell script inverso, oppure un MSI con property di uninstall. La console da sola non basta: serve sapere quale comando è stato usato per l’installazione iniziale.
Per gli MSI, il controllo di base è l’ProductCode e il comando di rimozione è spesso questo:
msiexec /x {PRODUCT-CODE-GUID} /qn /norestartQui il rischio operativo è più alto rispetto a una semplice patch Windows, perché puoi rimuovere componenti applicativi con dipendenze non banali. Prima di eseguire la disinstallazione, controlla se l’application in SCCM ha una detection method che la farà tornare “installed” o “required” al ciclo successivo. Se sì, devi correggere anche la detection o sospendere la deployment type, altrimenti il client potrebbe reinstallarla.
Log da leggere per capire perché il rollback non funziona
Se la rimozione fallisce o il client tenta di reinstallare la patch, i log da guardare sono pochi ma decisivi. Su SCCM client, i più utili sono UpdatesDeployment.log, WUAHandler.log, ScanAgent.log e, se coinvolta un’application, AppEnforce.log. Su Windows Update, anche CBS.log e il registro eventi di sistema possono chiarire se il pacchetto è bloccat o da un prerequisito mancato.
Un pattern tipico è questo: il client riceve la policy corretta, rileva ancora l’update come richiesto, prova a installarlo o a mantenerlo installato, e il rollback viene annullato. In quel caso il problema non è il comando di disinstallazione, ma il fatto che il deployment è ancora vivo oppure la detection continua a leggere uno stato incoerente.
Se vuoi una verifica rapida, cerca nel log la stringa del KB o l’ID del deployment e controlla se la sequenza mostra “required” dopo la rimozione. Se il client continua a ricevere il deployment, la correzione sta lato console, non lato endpoint.
Sequenza operativa consigliata in produzione
Il metodo più sicuro è lavorare in questo ordine: prima blocchi la riapplicazione, poi disinstalli, poi verifichi. Saltare il primo passaggio è l’errore più comune, perché lascia il client libero di reinstallare la patch al primo ciclo utile. Saltare la verifica finale è l’altro errore classico: il rollback sembra riuscito, ma il sistema resta in uno stato che verrà corretto dal deployment successivo.
wusa.exe /uninstall /kb:... o msiexec /x .... L’esito atteso è codice di ritorno coerente e assenza dell’update tra gli hotfix installati.UpdatesDeployment.log, WUAHandler.log e, se serve, CBS.log. L’esito atteso è nessun nuovo tentativo di reinstallazione.Controlli finali e rollback del rollback
Dopo la disinstallazione, il controllo finale non è solo “l’update non si vede più”. Devi verificare che l’host sia tornato nello stato previsto: servizi avviati, applicazione raggiungibile, nessun errore ricorrente nei log e nessun nuovo evento di enforcement da SCCM. Se il client è in una collection con maintenance window, verifica anche che non ci siano policy residue che forzino una reinstallazione al prossimo scan cycle.
Se qualcosa va storto, il rollback del rollback dipende dal caso. Per una patch Windows, significa normalmente riapplicare l’update o ripristinare il sistema da backup/snapshot se il componente rimosso ha rotto la piattaforma. Per un package o un’application, il rollback può essere un reinstall, un revert della versione precedente o il ripristino del file/configuration set. Non improvvisare: se il componente toccava servizi critici o database locali, il blast radius va considerato alto e il ripristino deve essere validato con un test funzionale minimo.
Assunzione operativa: il caso trattato qui è un ambiente Windows gestito da SCCM/Configuration Manager con patch distribuita a un singolo host o a un collection limitato; se la distribuzione è massiva, il rollback va prima testato su un gruppo pilota.
Quando non conviene insistere con la disinstallazione
Ci sono casi in cui insistere sul rollback della patch è la scelta sbagliata. Se l’aggiornamento ha corretto una vulnerabilità critica e il problema che stai vedendo è un effetto collaterale applicativo, spesso è più prudente mitigare l’applicazione o cambiare la configurazione del servizio invece di togliere il patching di sicurezza. Allo stesso modo, se l’update è parte di una catena di prerequisiti, la disinstallazione può rompere dipendenze più ampie di quanto sembri dal solo KB.
In pratica: prima osserva, poi blocca la riapplicazione, poi disinstalla solo se il pacchetto è supportato e il rischio è accettabile. In SCCM la differenza tra una correzione rapida e un disastro operativo sta quasi sempre nel controllo della policy e nella verifica del tipo di update, non nel comando finale.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.