Aggiornamento SCCM bloccato su Windows Server 2012 e 2012 R2

Quando un aggiornamento SCCM si pianta su Windows Server 2012 o 2012 R2, il problema raramente è “SCCM in sé”. Quasi sempre il blocco nasce in uno di questi punti: prerequisiti del sistema operativo non allineati, componenti legacy che non parlano più il linguaggio richiesto dalla console o dal client, TLS 1.2 non abilitato dove serve, WMI sporca, oppure un collo di bottiglia su WSUS e distribuzione contenuti. Se l’aggiornamento è fermo da ore, non conviene guardare solo il wizard: va ricostruito il percorso completo, dal server di site fino al client o alla console che sta tentando l’upgrade.

Il punto vero: dove si blocca l’aggiornamento

“Aggiornamento bloccato” è una descrizione troppo larga. In pratica, su 2012 e 2012 R2 il blocco si manifesta di solito in uno di questi scenari:

1. L’update è visibile ma resta in stato Downloading, Installing o Prerequisite check failed nella console SCCM.
2. Il client non riceve policy o resta su una versione vecchia anche dopo il deployment del client package.
3. Il server con ruolo SCCM o WSUS non completa il cambio di versione perché manca un prerequisito OS o una libreria TLS/.NET.
4. La console si aggiorna a metà e poi si ferma per problemi di permessi, proxy, certificati o repository WMI danneggiato.

La prima domanda utile non è “perché non va?”, ma “in quale layer si ferma?”. In ordine pratico: DNS e connettività, edge/proxy, server SCCM, WSUS, WMI, database SQL, client. Se non identifichi il layer, rischi di fare tentativi a vuoto e allungare il fermo.

Prerequisiti che su 2012/2012 R2 saltano più spesso

Su questi sistemi il problema più frequente è l’accoppiata tra stack vecchio e requisiti moderni. SCCM, specialmente nelle versioni più recenti, tende a dare per scontati componenti che su 2012/2012 R2 non sono sempre presenti o non sono configurati correttamente.

I casi tipici sono:

• TLS 1.2 non abilitato per sistema operativo, .NET e WinHTTP.
• .NET Framework non allineato alla versione richiesta da console o prerequisiti del site server.
• Ruoli IIS/WSUS incompleti o con feature mancanti.
• WMI corrotta o repository incoerente dopo update precedenti.
• Spazio disco insufficiente su `C:` o su `%windir%` durante l’espansione del pacchetto di upgrade.

La verifica minima va fatta prima di cambiare qualcosa. Esempio: se il server non parla TLS 1.2 verso il repository o il sito di distribuzione, l’update può restare fermo senza un errore intuitivo in console. In quel caso il sintomo è “non scarica” o “non valida prerequisiti”, ma la causa è a livello di protocollo, non di SCCM workflow.

Verifiche rapide che danno subito un segnale

Prima di toccare la configurazione, fai una raccolta minima di evidenze. L’obiettivo è capire se il blocco è lato transport, lato servizio o lato repository.

1. Controlla lo stato dell’update nella console SCCM: se c’è un messaggio in Monitoring o Updates and Servicing Status, annota il testo esatto.
2. Verifica i log del site server, in particolare `CMUpdate.log`, `ConfigMgrSetup.log`, `hman.log`, `distmgr.log` e `wsyncmgr.log` se il problema tocca la sincronizzazione o il download.
3. Se il problema è sul client, controlla `ccmsetup.log`, `ClientLocation.log`, `LocationServices.log`, `PolicyAgent.log` e `WUAHandler.log`.
4. Controlla che il server abbia spazio libero sufficiente e nessun errore disco o OOM nel Visualizzatore eventi.
5. Verifica il handshake verso i punti di download o verso WSUS con un test HTTP/HTTPS semplice.

Comandi utili per una prima scansione:

netsh winhttp show proxy
powershell -Command "[Net.ServicePointManager]::SecurityProtocol"
powershell -Command "Test-NetConnection -ComputerName <server-sccm> -Port 443"
powershell -Command "Test-NetConnection -ComputerName <wsus-server> -Port 8530"

Se `Test-NetConnection` fallisce, il problema non è ancora SCCM: è connettività, firewall o endpoint non raggiungibile. Se invece la connettività è ok ma il log mostra retry continui, il sospetto si sposta su TLS, certificati, proxy o permessi sul percorso di download.

La causa più comune: TLS 1.2 assente o non forzato correttamente

Su Windows Server 2012 e 2012 R2, molte installazioni si bloccano perché il sistema usa ancora impostazioni vecchie per Schannel, WinHTTP o .NET. SCCM moderno, WSUS e alcuni endpoint Microsoft rifiutano connessioni che non negoziano TLS 1.2. Il risultato è subdolo: l’update sembra scaricare, ma in realtà fallisce la connessione o la validazione dei prerequisiti.

La verifica più utile è controllare sia la parte OS sia la parte .NET. Un controllo rapido della configurazione TLS lato registro può essere fatto così:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client"
reg query "HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto
reg query "HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v SchUseStrongCrypto

Se i valori non esistono o risultano disabilitati, il blocco è plausibile. Non basta però “attivare TLS 1.2” in modo generico: va fatto con criterio, perché tocchi un’area che impatta anche altri servizi sul server.

WMI e repository: il blocco silenzioso che sembra un problema SCCM

Un altro classico su 2012/2012 R2 è WMI sporca. SCCM si appoggia pesantemente a WMI per inventario, discovery, compliance e gestione client. Se il repository è incoerente, la console può restare parzialmente aggiornata, i client possono non ricevere policy e alcuni check di prerequisito falliscono senza una causa evidente in GUI.

La verifica minima è questa:

winmgmt /verifyrepository
winmgmt /salvagerepository

Se `verifyrepository` segnala inconsistenza e `salvagerepository` la corregge, hai trovato un problema reale. Dopo la correzione, va verificato il servizio `Windows Management Instrumentation` e poi rieseguito il ciclo SCCM. Se invece il repository continua a risultare corrotto, non forzare interventi più aggressivi senza backup e finestra di manutenzione: il blast radius include il management layer del server.

WSUS e content distribution: quando il collo di bottiglia è fuori dal site server

Molti ambienti considerano SCCM e WSUS come due mondi separati, ma nella pratica il blocco dell’aggiornamento passa spesso da lì. Se il software update point non sincronizza, il catalogo resta incompleto; se il content library non distribuisce, il pacchetto resta in pending; se il boundary group è errato, il client non trova il punto di distribuzione giusto.

Controlli rapidi:

1. Verifica `wsyncmgr.log` per errori di sincronizzazione o timeout.
2. Verifica `distmgr.log` per problemi di distribuzione contenuti.
3. Controlla `ContentLibraryTransfer.log` se il pacchetto si ferma durante copia o replica.
4. Controlla i boundary group se il client non scarica da un DP raggiungibile.

Un errore frequente è vedere un update “approvato” ma non effettivamente disponibile ai client perché il contenuto non è ancora arrivato al distribution point corretto. In quel caso il fix non è sul client, ma sul flusso di distribuzione.

Procedura pratica di diagnosi in ordine di probabilità

Se devi arrivare a una conclusione veloce, usa questo ordine. È il più efficiente quando non hai tempo per una caccia lunga ai log.

1. Primo sospetto: TLS/proxy/connettività. Falsifica in 5 minuti con `Test-NetConnection`, controllo proxy WinHTTP e verifica handshake HTTPS verso WSUS o endpoint di download.
2. Secondo sospetto: WMI/repository o servizi SCCM malati. Falsifica con `winmgmt /verifyrepository`, stato servizi (`services.msc` o `Get-Service`) e ricerca di errori nei log citati.
3. Terzo sospetto: content distribution/WSUS/boundary group. Falsifica controllando i log di distribuzione e la presenza del contenuto sul DP corretto.

Questa sequenza evita di fare il classico errore: riavviare servizi a raffica senza sapere se il problema è a monte. Riavviare `SMS_EXECUTIVE` o `WMI` può sbloccare temporaneamente, ma se il problema è TLS o contenuti mancanti il blocco torna subito.

Correzione consigliata: approccio reversibile e con impatto limitato

La regola è semplice: prima correggi il layer più basso che hai dimostrato guasto, poi verifichi, poi sali di livello. Su un ambiente SCCM che gestisce 2012/2012 R2, l’ordine corretto di solito è questo:

1. Abilita TLS 1.2 dove serve, ma solo dopo aver confermato che il blocco è su connessione o download.
2. Ripara WMI solo se il repository è incoerente o i log puntano chiaramente a query fallite.
3. Riallinea WSUS, boundary e distribution point se il contenuto non arriva al client.
4. Solo alla fine, valuta un repair dell’installazione SCCM o un upgrade del site/server, se l’ambiente è già fuori supporto operativo per il tuo target.

Se devi intervenire sul registro per TLS, fallo con backup e finestra di rollback. Un esempio di salvaguardia minima è esportare prima le chiavi interessate:

reg export "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel" C:\Temp\schannel-backup.reg
reg export "HKLM\SOFTWARE\Microsoft\.NETFramework" C:\Temp\dotnet-backup.reg

Il rollback, in questo caso, è il re-import dei file `.reg` esportati e il riavvio controllato dei servizi coinvolti. Il blast radius è limitato al server dove applichi la modifica, ma l’effetto può propagarsi su console, client e aggiornamenti se quel server è site server o WSUS point.

Esempio di intervento su un blocco tipico

Scenario realistico: un site server su Windows Server 2012 R2 mostra un update SCCM in stato di download infinito. I log indicano retry HTTPS verso un endpoint Microsoft e la console non mostra errori chiari. `Test-NetConnection` passa, ma i log riportano failure di negoziazione sicura.

Intervento minimo:

1. Verifica e salva i log di `CMUpdate.log` e `ConfigMgrSetup.log` per avere un punto di ritorno.
2. Controlla lo stato TLS 1.2 lato Schannel e .NET.
3. Applica la correzione necessaria solo sul server interessato.
4. Riavvia i servizi coinvolti, non tutta la macchina, se la modifica è limitata a componenti applicativi.
5. Rilancia il check dell’update e osserva se il passaggio da Downloading a Installing avviene entro pochi minuti.

Se non cambia nulla, non insistere sulla stessa ipotesi. Passa al layer successivo: WMI, poi WSUS/content, poi permessi e proxy. Il vantaggio di questo ordine è che ogni step produce un’evidenza verificabile, non una sensazione.

Cosa controllare sui client Windows Server 2012/2012 R2

Se il problema non è il site server ma il client, la diagnosi cambia poco, solo il punto di osservazione. Sul client guarda se il servizio `ccmexec` è attivo, se il client riceve policy e se il download del pacchetto avviene dal DP corretto. Un client che non aggiorna può essere sano “di facciata” ma bloccato da vecchie policy, WMI locale o certificati.

File da controllare:

• `C:\Windows\CCM\Logs\ccmsetup.log`
• `C:\Windows\CCM\Logs\ClientLocation.log`
• `C:\Windows\CCM\Logs\PolicyAgent.log`
• `C:\Windows\CCM\Logs\WUAHandler.log`

Se il client è dietro proxy o usa WinHTTP configurato male, il problema può essere identico a quello del server: il download non parte o si interrompe senza un messaggio utile in GUI. Anche qui, prima si misura la connettività, poi si tocca la configurazione.

Quando fermarsi e pianificare un change più grosso

Ci sono casi in cui il fix rapido non basta. Se il site server è su una versione di Windows ormai al limite rispetto alla tua versione SCCM, se i log mostrano errori ripetuti di compatibilità o se il sistema è pieno di workaround accumulati, la soluzione corretta non è “aggiungere un’altra eccezione”. In quel caso serve un change controllato: aggiornamento del sistema operativo, revisione dei prerequisiti, pulizia dei ruoli e allineamento della versione SCCM a un livello supportato.

Il criterio pratico è questo: se hai già corretto connettività, TLS, WMI e distribuzione contenuti ma l’update continua a fallire, non sei più davanti a un semplice incidente. Sei davanti a una base tecnica che va riallineata.

Checklist finale operativa

Prima di chiudere il caso, verifica questi punti in modo esplicito:

1. L’update SCCM cambia stato nella console e i log confermano il passaggio successivo.
2. I test `Test-NetConnection` verso i target necessari sono positivi.
3. WMI non segnala repository incoerente.
4. WSUS e distribution point hanno sincronizzato e distribuito il contenuto.
5. Le modifiche fatte sono documentate e reversibili con backup o export dei settaggi toccati.

Assunzione: il problema è stato affrontato su un server o client Windows Server 2012/2012 R2 in ambiente SCCM con accesso ai log applicativi e possibilità di fare modifiche reversibili su TLS, WMI o distribuzione contenuti.