Come risolvere l'avviso prerequisito .NET in SCCM

Leggere bene l’avviso: non è quasi mai “manca .NET”, è “manca la versione giusta”

In SCCM l’avviso sul prerequisito .NET va trattato come un controllo di compatibilità, non come un messaggio generico da ignorare. Il punto non è solo avere .NET installato: conta la versione richiesta dal componente, il ruolo in cui gira, l’architettura del sistema e, in certi casi, il fatto che la feature sia presente ma non abilitata correttamente. In pratica, il sintomo più comune è una procedura di setup, update o installazione role che si ferma perché il controllo prerequisiti non trova il framework atteso oppure rileva una release non sufficiente.

La prima cosa da chiarire è dove compare il warning. Se lo vedi durante l’installazione di un ruolo SCCM, il problema è quasi sempre lato server. Se invece emerge su console, distribuzione componenti o client, la verifica cambia: bisogna capire quale nodo sta eseguendo il controllo e quale dipendenza richiede davvero. Trattare tutto come “installa l’ultima .NET e risolvi” è un classico modo per perdere tempo o introdurre una modifica inutile.

Che cosa controlla davvero SCCM quando parla di .NET

SCCM non si limita a cercare una presenza generica del runtime. Nei controlli prerequisito possono entrare in gioco la release del .NET Framework, alcune componenti Windows abilitate tramite feature, l’allineamento con la build di Windows Server e perfino la differenza tra installazione lato console e lato server. Il messaggio può essere ambiguo, ma il controllo dietro è preciso: se il setup si aspetta una release specifica, una versione precedente non basta.

Su Windows Server moderno, il .NET Framework 4.x è spesso già presente come componente di sistema, ma non bisogna confonderlo con il fatto che sia davvero pronto all’uso per il ruolo che stai installando. Un’incongruenza tipica è trovare la feature “.NET Framework 4.x” installata, ma con una release non allineata al prerequisito richiesto da quel ramo di SCCM. Per questo la verifica va fatta in modo oggettivo, non per supposizione.

Verifica minima: versione reale, feature, log

Prima di cambiare qualcosa, raccogli tre evidenze: versione del framework, stato della feature Windows e log del controllo prerequisiti. Se uno di questi tre punti manca, stai navigando a vista.

Per la versione installata del .NET Framework 4.x, la strada più affidabile è leggere la release dal registro. Il valore Release indica la build effettiva e non solo la presenza del framework.

reg query