Gli aggiornamenti non riusciti sono una sfida ricorrente per il patch management , spesso causati da problemi di rete, blocchi di sistema o conflitti di servizio. Se non risolti, i mancati aggiornamenti del sistema operativo possono causare prestazioni instabili e rendere gli endpoint vulnerabili alle minacce.
L’automazione di tentativi di reinstallazione delle patch aiuta a minimizzare i rischi, a ridurre l’MTTR e a migliorare i tassi di successo degli aggiornamenti senza sovraccaricare i tecnici con elevati volumi di ticket.
Passi per automatizzare i tentativi di reinstallazione delle patch per mitigare i fallimenti degli aggiornamenti
La correzione automatica dei malfunzionamenti delle patch riduce la necessità di una frenetica diagnostica manuale, garantendo la conformità delle patch su tutti gli endpoint. Questo, a sua volta, riduce il carico di lavoro dei tecnici e fornisce visibilità sui modelli di errore ricorrenti grazie ai registri.
📌 Casi d’uso: Sfrutta gli script PowerShell per elencare i tentativi di aggiornamento passati ed estrarre i codici di errore, consentendo agli script di riprovare, fare marcia indietro o interrompersi. Grazie alle attività pianificate, alle piattaforme RMM e all’implementazione di GPO, i tecnici possono automatizzare la reinstallazione delle patch per gli aggiornamenti non riusciti o mancanti.
📌 Prerequisiti:
- Sistemi operativi supportati: Windows 10/11 o Windows Server 2016 o successivo
- Permessi: privilegi di amministratore o di sistema
- Fonte di aggiornamento: WSUS, Intune o Windows Update
- Opzionale: piattaforme RMM come NinjaOne
💡 Nota: alcuni passaggi possono variare a seconda delle impostazioni predefinite o attive del sistema per ogni ambiente.
Fase 1: Identificare le patch non riuscite utilizzando gli script di PowerShell
Un’efficace riparazione automatica degli errori delle patch inizia con un rilevamento proattivo. I seguenti script interrogano la cronologia degli aggiornamenti e i risultati di un endpoint, restituendo le voci problematiche per una visione più chiara.
Ordinare le patch non riuscite utilizzando il modulo PSWindowsUpdate
Questo script legge le ultime 200 voci della cronologia degli aggiornamenti, quindi filtra le installazioni riuscite, e mostrando solo quelle non riuscite.
| Import-Module PSWindowsUpdate # Retrieve failed updates |
⚠️ Importante: Saltare l’installazione di PSWindowsUpdate causerà errori, poiché questo modulo PowerShell non è integrato in Windows per impostazione predefinita. (Vedi ⚠️ Cose da tenere in considerazione)
Metodo alternativo per ordinare le patch non riuscite tramite il Registro eventi di Windows
Questo script esegue un’interrogazione dei registri del client di Windows Update, alla ricerca di voci con segnali di errore comuni, come gli ID 20, 25 e 31.
| Get-WinEvent -LogName “System” | Where-Object { $_.ProviderName -eq “Microsoft-Windows-WindowsUpdateClient” -e $_.Id -in 20, 25, 31 # Common failure event IDs } |
Fase 2: Riproduzione delle patch non riuscite con la logica di PowerShell
Una volta che gli aggiornamenti falliti vengono visualizzati su un endpoint, puoi utilizzare gli script PowerShell per tentare nuovamente di applicare le patch in modo automatico. Facendo così eliminerai le operazioni manuale per le patch, consentendo una bonifica su scala una volta rilevato un errore di patch.
Esempio di script PowerShell per tentare nuovamente l’installazione degli aggiornamenti falliti
Questo script si basa su $failedUpdates come visto nella fase 1, eseguendo un loop attraverso gli aggiornamenti falliti enumerati per la reinstallazione.
| foreach ($update in $failedUpdates) { Write-Output “Retrying: $($update.Title)” Install-WindowsUpdate -KBArticleID $update.KBArticleID -AcceptAll -AutoReboot -IgnoreReboot -ErrorAction Continue } |
Esempio di script che include la gestione degli errori
| try { Install-WindowsUpdate -KBArticleID $update.KBArticleID -AcceptAll -ErrorAction Stop } catch { Write-Output “Retry failed for: $($update.KBArticleID) – $_” } |
⚠️ Importante: utilizza la gestione degli errori per evitare che gli script falliscano silenziosamente. (Fai riferimento alla sezione ⚠️ Cose da tenere in considerazione. )
Fase 3: Utilizzare il registro dei log per i tentativi di reinstallazione e il monitoraggio
Sfrutta il Registro di sistema per memorizzare il conteggio dei tentativi di reinstallazione e i KB non riusciti per eseguire rapidamente le interrogazioni locali. Questo aiuta a fornire un’identificazione persistente anche quando un endpoint viene disconnesso durante le interruzioni di WSUS o RMM.
Esempio di script PowerShell per tenere traccia dei tentativi di reinstallazione e dei timestamp dei risultati nel Registro:
| New-Item -Path “HKLM:\SOFTWARE\Org\PatchRetry” -Force Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\PatchRetry” -Name “LastRetry” -Value (Get-Date).ToString(“u”) Set-ItemProperty -Path “HKLM:\SOFTWARE\Org\PatchRetry” -Name “FailedKBs” -Value ($failedUpdates.KBArticleID -join “, “) |
Esempio di script PowerShell per verificare lo stato delle patch tramite il Registro:
| Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Org\PatchRetry’ |
Fase 4: Automatizzare i tentativi con attività pianificate o con NinjaOne RMM
Pianifica gli script sugli endpoint per verificare regolarmente la conformità e reinstallare automaticamente le patch sui dispositivi non conformi. Con NinjaOne, i tecnici possono creare condizioni composte, garantendo la riapplicazione di patch dopo un’esecuzione non riuscita.
Creare un’attività pianificata ricorrente utilizzando uno script .ps1 preesistente tramite CMD:
| schtasks /create /tn “RetryFailedPatches” /tr “powershell.exe -File C:\Scripts\PatchRetry.ps1” /sc daily /st 02:00 /ru SYSTEM |
💡 Suggerimento: Salva lo script di ripetizione trovato alla fase 2 come file .ps1 e indirizza il comando per interrogare il suo percorso.
Aggiorna automaticamente i valori del Registro di sistema e monitora il successo o il limite di tentativi tramite script PowerShell
| $retryCount = (Get-ItemProperty -Path “HKLM:\SOFTWARE\Org\PatchRetry”).RetryCount if ($retryCount -gt 3) { # escalate or log for technician } |
Fase 5: Usare GPO per garantire impostazioni di aggiornamento compatibili con il tentativo di ripetizione
I tentativi automatici di patch funzionano meglio quando Windows Update si comporta in modo prevedibile. I tecnici possono distribuire le GPO per pre-scaricare i contenuti degli aggiornamenti, pianificare le installazioni e inviare nuovamente i riavvii all’interno delle configurazioni di base.
⚠️ Attenzione: è best practice testare le GPO in locale prima di distribuirle. (Fai riferimento alla sezione ⚠️ Cose da tenere in considerazione. )
- Apri la Console di gestione dei Criteri di gruppo (gpmc.msc), quindi vai a:
Configurazione del computer > Modelli amministrativi > Componenti di Windows > Windows Update
- Configura i seguenti criteri:
| Impostazioni | Configurazione consigliata | Definizione |
| Configura gli aggiornamenti automatici | Seleziona la casella di controllo accanto a Download automatico e installazione programmata. | Pre-scarica automaticamente gli aggiornamenti e li installa in base a un programma prestabilito. |
| Specifica la posizione del servizio di aggiornamento Microsoft Intranet | Seleziona Abilita e inserisci l’URL HTTP(S) del server WSUS preferito nei seguenti campi:
| Specifica il server WSUS da cui Aggiornamenti automatici recupererà gli aggiornamenti. |
| Nessun riavvio automatico per le opzioni di installazione di aggiornamenti automatici pianificati | Configura il criterio come Abilitato. | Disabilita il riavvio automatico se qualcuno ha effettuato l’accesso, evitando interruzioni a metà sessione. |
| Richiesta di riavvio con le installazioni programmate | Configura il criterio come Disabilitato. | Smette di chiedere agli utenti di riavviare a metà sessione dopo un aggiornamento pianificato. |
- Dopo aver collegato la GPO a una OU, inserisci il seguente comando PowerShell su un endpoint di destinazione: gpupdate /force
⚠️ Cose da tenere in considerazione
| Rischi | Potenziali conseguenze | Possibilità di tornare alla configurazione precedente |
| Salta l’installazione del modulo PSWindowsUpdate | L’utilizzo dei cmdlet di Windows Update senza il modulo PowerShell richiesto provoca errori. | Carica il modulo PSWindowsUpdate digitando Import-Module PSWindowsUpdate in un prompt di PowerShell. |
| Non includere la gestione degli errori negli script | Gli script falliscono silenziosamente se non si ha una gestione adeguata degli errori così i tecnici si troveranno ad indovinare cosa è andato storto. | Sfrutta la gestione degli errori di PowerShell negli script per migliorare la documentazione quando si verificano errori. |
| Distribuzione di GPO non testati | Le GPO non testate possono contenere configurazioni errate che possono avere un grave impatto sugli endpoint una volta distribuiti. | Testa le GPO localmente in un ambiente controllato prima di distribuirlo su tutta l’organizzazione. |
Considerazioni sull’automazione dei tentativi di reinstallazione delle patch per gli aggiornamenti falliti
Quando automatizzi i tentativi di reinstalazione delle patch, è fondamentale garantire una transizione fluida tra le fasi, poiché un intoppo può potenzialmente causare errori. L’impiego delle seguenti considerazioni guida gli script a decidere correttamente quale passo compiere, migliorando le percentuali di successo dei tentativi.
Applicazione dei limiti di riprova
I limiti di ripetizione all’interno del Registro aiutano a prevenire i cicli di ripetizione infiniti e lo spam di ticket. Imposta incrementi per ogni esecuzione per aumentare il tempo di backoff per ogni istanza non riuscita. Una volta raggiunto il numero massimo di tentativi, i limiti di reinstallazione interrompono l’esecuzione degli script e fanno emergere il problema una volta.
Riavvio del servizio Windows Update
I malfunzionamenti delle patch possono verificarsi quando Windows Update (wuauserv) non è raggiungibile e un rapido riavvio del servizio spesso risolve il problema. A questo proposito, ti consigliamo di riavviare Windows Update prima di fare un altro tentativo di riprova.
- Esempio di script PowerShell per riavviare wuauserv: Restart-Service -Name wuauserv
Soluzione per i dispositivi offline
I dispositivi offline possono facilmente esaurire i limiti di rieinstallazione, facendo sì che gli script li saltino del tutto. Attraverso le piattaforme RMM, come NinjaOne, i tecnici possono impostare una condizione di risultato dello script per ritentare o riavviare durante le ore meno affollate.
Convalida delle fonti di patch
Prima di tentare una reinstallazione, gli script devono verificare se la loro fonte di patch è raggiungibile, poiché le fonti non raggiungibili causano fallimenti. Se la sorgente non funziona dopo la convalida, crea un breve backoff, ma non considerarlo come un tentativo fallito. Se una singola KB non funziona, sospendila e procedi con le altre patch, quindi riprova in un momento successivo.
Quick-Start Guide
NinjaOne offre diverse funzionalit per automatizzare il patch management e ridurre gli interventi manuali:
1. Patch Intelligence AI
– Valuta automaticamente i rischi delle patch ogni sei ore – Può spostare le patch tra gli stati approvato, manuale e rifiutato in base al feedback della comunità – Contribuisce a ridurre i rischi derivanti da patch potenzialmente problematiche
2. Strategie di approvazione e di riprova
Livelli multipli di approvazione delle patch: – Sovrascrittura a livello di dispositivo – Sovrascrittura dei criteri – Approvazioni/rifiuti preventivi globali – Può approvare automaticamente le patch dopo un determinato numero di giorni (fino a 30 giorni per gli aggiornamenti, 365 giorni per gli aggiornamenti delle funzionalità) – Consente l’approvazione o il rifiuto manuale delle patch in base al numero KB o all’ID patch
3. Distribuzione ad anello
– Distribuzione scaglionata delle patch per ridurre al minimo i rischi – Creare gruppi di dispositivi per diversi anelli di distribuzione – Testare le patch su un piccolo sottoinsieme di dispositivi prima di una distribuzione più ampia
4. Pianificazione delle patch e ripetizione dei tentativi
– Ti consigliamo di separare i cicli di scansione e aggiornamento di almeno un’ora – I cicli di scansione vengono eseguiti prima dei cicli di applicazione – Opzioni di riavvio e notifiche configurabili
Risoluzione dei problemi di automazione degli script di riprova delle patch
Problema 1: Nessuna attività di reinstallazione
La logica di ripetizione non viene eseguita senza l’elevazione corretta e non mostra alcuna attività di ripetizione. Come soluzione, verifica se lo script viene eseguito come SYSTEM o se ha i privilegi più elevati. Inoltre, convalida la sintassi dello script e verifica che tutti i percorsi di riferimento esistano.
Problema 2: Aggiornamento non trovato
Verifica se l’aggiornamento mancante è disponibile dalla fonte specificata. Considera fonti alternative come Windows Update invece di Windows Server Update Services (WSUS) per evitare di bruciare i tentativi di riprova con interrogazioni inutili.
Problema 3: Gli aggiornamenti falliscono costantemente
Combina i tentativi di reinstallazione con le informazioni generate dai registri di Windows Update, questo ti consentirà di individuare gli errori nelle patch non riuscite.
- Esempio di script PowerShell per interrogare i registri di Windows Update:
Import-Module PSWindowsUpdate
Get-WindowsUpdateLog
Problema n. 4: Riavvio del ciclo
A volte gli aggiornamenti richiedono il riavvio del dispositivo prima di essere applicati, lo spegnimento non ha lo stesso effetto. Una volta perso, è facile cadere nel circolo vizioso di riapplicare le patch senza alcun cambiamento apprezzabile. Per evitare questo problema, verifica se un endpoint richiede un riavvio e confermalo, quindi prova nuovamente ad aggiornarlo.
Servizi NinjaOne che semplificano l’automazione della reinstallazione delle patch
NinjaOne aiutaad automatizzare le query sulle patch e la correzione per garantire la conformità e ridurre la necessità di interventi manuali. Ecco alcune delle funzionalità di NinjaOne che puoi sfruttare per semplificare l’automazione dei tentativi di patch su scala.
- Attività programmata dei criteri. Utilizza le funzionalità di automazione programmata di NinjaOne per impostare i ritiri tra i gruppi di dispositivi entro intervalli specificati.
- Dashboard del patch management. La dashboard di NinjaOne ordina i dispositivi con patch non riuscite, riuscite e in sospeso per una migliore visibilità. I tecnici possono anche generare facilmente rapporti personalizzati sulle patch attraverso la dashboard.
- Condizioni composte. Crea trigger di automazione personalizzati, come la generazione di notifiche, l’attivazione di script o l’escalation di casi, in base alle condizioni dei risultati degli script.
- Distribuzione remota degli script. Esegui gli script in remoto su scala, consentendo un’automazione coerente per la reinstallazione delle patch non riuscite in tutto l’ambiente.
Automatizza la riparazione dei guasti delle patch per massimizzare il tempo di attività
Dall’interrogazione della cronologia degli aggiornamenti all’applicazione dei criteri di base, questa guida fornisce ai tecnici solide strategie di base per l’automazione. Con NinjaOne che gestisce il monitoraggio, l’implementazione degli script e la pianificazione, la logica del patch retry può essere automatizzata all’interno di un pannello unico centralizzato.
Il consolidamento delle strategie di automazione all’interno di una piattaforma centralizzata rende proattivo il quadro generale dell’automazione, consentendo di porre rimedio rapidamente ai problemi rilevati. Ciò contribuisce a ridurre i tempi di inattività, a diminuire il volume dei ticket e a garantire una conformità uniforme delle patch su tutti gli endpoint.
Argomenti correlati:
- Come utilizzare PowerShell per automatizzare gli aggiornamenti delle funzionalità di Windows 11
- Che cos’è il patch management di Windows? Panoramica e come fare
- Che cos’è la conformità delle patch?
- I segreti per un patching indolore su larga scala
- Le migliori pratiche di patch management per migliorare la conformità e la sicurezza
