Come risolvere l'avviso prerequisito .NET in SCCM

Il punto chiave: SCCM non sta “rompendo .NET”, sta bloccando un prerequisito

Quando in SCCM compare un avviso sul prerequisito .NET, la lettura corretta non è “manca .NET e basta”, ma “la funzionalità che stai installando o aggiornando non trova il livello minimo atteso”. In pratica il problema può stare su tre piani diversi: il server site, la console amministrativa, oppure il sistema su cui stai distribuendo un componente specifico. Se si parte dal sintomo e non dal contesto, si perde tempo a reinstallare framework che magari sono già presenti.

In un ambiente SCCM/MECM il prerequisito .NET è spesso un controllo di compatibilità, non un semplice check binario. La stessa versione di .NET può essere sufficiente per una console ma non per un aggiornamento del site server, e un nodo secondario o un server con ruoli aggiuntivi può avere dipendenze diverse. Per questo la prima domanda utile è: dove compare l’avviso?

Capire il layer: console, site server o prerequisite checker

Se l’avviso appare durante l’avvio della console, il problema è quasi sempre locale alla macchina amministrativa o al pacchetto console installato. Se compare durante un upgrade del site server o di un ruolo, il controllo va fatto sul server SCCM e nei log di setup. Se invece l’avviso arriva dal prerequisite checker prima di un’installazione, il messaggio va letto insieme alla versione del prodotto che stai cercando di installare: spesso il requisito cambia tra release e cumulative update.

La distinzione è importante perché la correzione cambia molto: sulla console puoi intervenire con una riparazione o un aggiornamento del client admin, sul server devi verificare feature di Windows, build del sistema operativo, riavvii sospesi e compatibilità del ruolo. In altri termini, non basta “avere .NET installato”; bisogna avere la versione giusta nel punto giusto.

Versioni .NET che contano davvero in SCCM

La parte che crea più errori è la confusione tra .NET Framework classico e .NET moderno. In questo contesto, quando SCCM parla di prerequisito, nella maggior parte dei casi si riferisce a .NET Framework, non al runtime .NET 6/7/8. La console e diversi componenti storici di Configuration Manager si appoggiano ancora a .NET Framework 4.x, e alcune release richiedono un livello minimo preciso del ramo 4.8 o successivo, a seconda della build e del sistema operativo.

Il punto pratico è questo: non dare per scontato che “4.8 installato” equivalga a “ok”. Serve verificare la build effettiva del framework, la presenza di eventuali aggiornamenti cumulativi del sistema operativo e la compatibilità del prodotto SCCM che stai usando. Su Windows Server recenti la versione può essere presente come feature di sistema, ma non sempre il setup la riconosce se mancano patch o se il nodo richiede un riavvio sospeso.

Verifica rapida senza toccare nulla

Prima di cambiare qualcosa, conviene raccogliere evidenze minime. Sul server o sulla macchina console verifica la versione di .NET Framework, lo stato dei servizi SCCM coinvolti e i log che spiegano il blocco. La cosa utile è non fermarsi al pannello “Programs and Features”, perché lì vedi solo che qualcosa è installato, non se è la build attesa.

Per controllare rapidamente il framework installato puoi usare il registro di sistema o il file system delle release. Un esempio pratico:

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release

Il valore Release va confrontato con la tabella ufficiale Microsoft per capire a quale .NET Framework corrisponde. Se il valore è mancante o non coerente con la release richiesta da SCCM, hai un indizio forte. Se invece il valore è corretto, il problema si sposta su patch OS, riavvio pendente o installazione incompleta.

Per la console, controlla anche il percorso di installazione e il log locale se presente. Un controllo semplice è verificare se l’eseguibile della console si avvia senza errori e se l’Event Viewer riporta eccezioni legate a .NET o assembly mancanti. In caso di errore, il messaggio completo vale più dell’avviso generico.

Log da aprire prima di fare manutenzione a caso

Per il site server e gli upgrade, i log di setup e prerequisiti sono la fonte primaria. I nomi esatti possono variare con la versione, ma in genere cerchi file sotto la cartella di installazione del product setup, oppure i log dell’operazione in corso nel path dei log di SCCM. Il criterio non cambia: devi trovare la riga che spiega quale controllo .NET è fallito e perché.

Se il setup dice solo “prerequisite check failed”, è un’informazione troppo vaga. Cerca nel log una riga con il nome del prerequisito, il minimo richiesto e il valore rilevato. Esempio di ciò che serve leggere davvero: versione attesa, versione trovata, eventuale motivo accessorio come “pending reboot”, “missing update” o “unsupported OS build”.

Un approccio pratico è aprire i log con CMTrace o con un viewer che evidenzi warning ed errori, poi filtrare per .NET, prerequisite, install, setup e reboot. Se il componente è una console, aggiungi anche i log dell’installer MSI e l’Event Viewer sotto Application.

La causa più frequente: framework presente ma non allineato

La casistica più comune non è l’assenza totale del framework, ma un disallineamento tra il requisito del componente SCCM e lo stato reale del sistema. Succede spesso in questi casi: aggiornamento di SCCM dopo patch OS incomplete, reinstallazione della console su una macchina con vecchie dipendenze, oppure upgrade del server con riavvio non completato. L’installer vede un ambiente “quasi pronto” e si ferma.

Un’altra situazione tipica è il sistema operativo che ha il framework ma non la combinazione di cumulative update richiesta dal prodotto. In quei casi il prerequisito .NET è solo il messaggero; il problema reale è la matrice di supporto tra release SCCM e build Windows Server. Per questo la documentazione di compatibilità va letta insieme alla versione esatta del site e del sistema operativo, non in modo separato.

Soluzione pratica: correggere il prerequisito senza allargare il blast radius

La correzione più sicura è procedere per passi reversibili. Prima aggiorna o verifica il framework richiesto, poi controlla eventuali patch mancanti, infine ripeti il check dei prerequisiti. Se stai agendo sulla console, evita di toccare il site server finché non hai escluso un problema locale. Se stai agendo sul server, fai prima un backup della configurazione rilevante o almeno salva lo stato del change prima di installare componenti aggiuntivi.

Se serve installare o riparare .NET Framework su Windows Server, la procedura dipende dalla build del sistema operativo e dalla release da ottenere. In generale il flusso corretto è: verificare il requisito esatto nella documentazione della versione SCCM, installare gli aggiornamenti di sistema richiesti, riavviare, e solo dopo rilanciare il prerequisite checker o il setup. Saltare il riavvio è uno degli errori più banali e più costosi in tempo.

Se il problema è la console, spesso la soluzione più pulita è una riparazione o reinstallazione della console stessa dopo aver allineato il framework e le dipendenze. Questo riduce il rischio di file assembly corrotti o riferimenti a vecchie versioni. Se la console è distribuita su più macchine, confronta una macchina funzionante con quella guasta: stessa build di SCCM, stesso .NET, stesso livello di patch.

Se il problema è un upgrade del site, non forzare avanti il setup finché il controllo prerequisiti non è verde. Un upgrade parziale in SCCM non è il posto giusto per “vediamo cosa succede”: il blast radius è alto, e un rollback può diventare complesso. Meglio fermarsi, correggere il nodo che fallisce e rilanciare il check.

Esempio operativo: come leggere il fallimento senza andare a tentativi

Supponiamo che il prerequisite checker segnali un errore su .NET durante l’installazione di un update di Configuration Manager. Il primo controllo è la versione del framework con la query sul registro. Il secondo è il log del setup per capire se il requisito è davvero una versione mancante o se il sistema è in stato non coerente. Il terzo è la verifica di eventuali riavvii pendenti, perché un reboot sospeso può far fallire controlli altrimenti corretti.

Se il valore Release corrisponde alla versione richiesta, ma il setup continua a bloccare il prerequisito, la pista successiva è il sistema operativo non allineato o un componente corrotto. In quel caso il fix non è “installare un altro .NET”, ma ripristinare lo stato supportato: patch corrette, riavvio, eventualmente repair del framework se il log lo suggerisce davvero. Senza evidenza, aggiungere pacchetti è solo rumore.

Quando il problema non è .NET ma il contesto di sicurezza o permessi

In ambienti più rigidi il prerequisito può fallire per motivi indiretti: account con privilegi insufficienti, blocco di software restriction policy, antivirus che interferisce con il setup, o hardening che limita la scrittura in directory usate dall’installer. Il messaggio finale parla di .NET, ma la causa reale è l’esecuzione dell’installazione in un contesto non autorizzato o filtrato.

Qui il controllo minimo è verificare con quale account stai eseguendo il setup, se l’installer genera errori di accesso negato e se in Event Viewer compaiono blocchi di applicazione o di script. Se l’ambiente usa AppLocker, Defender for Endpoint o controlli equivalenti, conviene guardare i log di blocco prima di modificare il framework. Anche in questo caso il principio è semplice: il prerequisito è il sintomo, non sempre la causa.

Rollback e verifica finale: cosa deve essere vero prima di chiudere

Dopo la correzione, la verifica non deve limitarsi a “l’errore è sparito”. Devi confermare tre cose: il valore della versione .NET è quello atteso, il prerequisite checker passa senza warning, e la console o il setup completano l’operazione senza nuovi errori nei log. Se hai aggiornato il framework o il sistema, controlla anche che non ci siano riavvii pendenti e che i servizi SCCM coinvolti siano in stato normale.

Il rollback dipende da ciò che hai toccato. Se hai solo corretto la console locale, il rollback è semplice: disinstallazione della console aggiornata o ripristino della macchina da snapshot, se previsto. Se hai installato patch o modificato il server, il rollback deve seguire il piano di change: rimozione dell’update se supportata, ripristino da backup o ritorno alla finestra precedente. Non improvvisare rollback “creativi” su un site SCCM in produzione.

Assunzione operativa: l’avviso .NET in SCCM è trattato qui come problema di prerequisito su console o site server, non come guasto generico dell’infrastruttura.