Come risolvere l'errore 0x80244017 durante l'installazione RSAT

0x80244017: dove si rompe davvero l’installazione di RSAT

Quando l’installazione di RSAT fallisce con 0x80244017, il problema non è quasi mai “RSAT” in sé. Il punto debole è il percorso con cui Windows recupera i componenti opzionali: Windows Update, WSUS, policy aziendali, cache locale o prerequisiti mancanti. In pratica, l’errore segnala che il client non riesce a ottenere correttamente i file necessari per la feature on demand.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il fatto importante è questo: RSAT nelle versioni moderne di Windows 10 e Windows 11 non si installa come vecchio pacchetto separato da scaricare a mano, ma come Optional Feature. Se il canale di distribuzione è filtrato, incompleto o reindirizzato male verso un WSUS che non espone i payload, l’installazione si ferma prima ancora di partire davvero.

Classificazione operativa: troubleshooting. Stato atteso: l’aggiunta della feature RSAT deve completarsi da Impostazioni o via PowerShell senza errori. Stato osservato: il wizard o il comando restituisce 0x80244017 e il componente resta non installato.

Il punto da verificare per primo: Windows Update o WSUS

La prima ipotesi da trattare come più probabile è una policy che forza il client a usare WSUS per scaricare anche le funzionalità opzionali, ma il server non ha i contenuti necessari o non è configurato per distribuirli. In molte reti aziendali questo si vede subito: gli update di sicurezza arrivano, ma le feature on demand falliscono.

La seconda ipotesi è una cache corrotta di Windows Update, spesso in C:\Windows\SoftwareDistribution, che blocca il recupero del pacchetto. La terza è una build di Windows non allineata: versione troppo vecchia, componenti mancanti o installazione non aggiornata abbastanza per il pacchetto RSAT desiderato.

Verifiche immediate che separano il problema di rete da quello di policy

Prima di toccare la macchina, conviene raccogliere evidenza minima. Non serve andare a tentativi: bastano pochi controlli per capire se il blocco è locale, di policy o di connettività.

1. Controlla la versione di Windows con winver oppure con systeminfo | findstr /B /C:"OS Name" /C:"OS Version". L’atteso è una build supportata per le feature richieste; se la macchina è molto indietro, il problema può essere compatibilità o catalogo componenti.
2. Verifica se il client è puntato a WSUS con reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer e reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer. Se i valori esistono, il client è quasi certamente governato da policy.
3. Controlla il percorso delle feature opzionali con Get-WindowsOptionalFeature -Online -FeatureName RSAT*. Se lo stato resta Disabled o il comando restituisce errore di download, il problema è nel canale di installazione.
4. Se sospetti un problema di raggiungibilità, testa il backend di update con Test-NetConnection download.windowsupdate.com -Port 443. L’atteso è TcpTestSucceeded : True; se fallisce, il blocco può essere firewall, proxy o ispezione TLS.

Un dettaglio utile: se la macchina è in dominio e usa WSUS, spesso il client può installare patch ma non le funzionalità opzionali. Questo non è un paradosso: dipende da come è stato configurato il server di aggiornamento e da quali contenuti sono stati approvati o scaricati.

Correzione più efficace: aggirare temporaneamente WSUS per le feature opzionali

Se il problema è la distribuzione via WSUS, la soluzione più pulita è consentire al client di scaricare le Features on Demand direttamente da Windows Update, senza cambiare la politica di aggiornamento completa. È una modifica reversibile e con blast radius limitato, adatta a un troubleshooting controllato.

Prima di procedere, tieni chiaro il rollback: se la macchina è gestita da GPO, qualsiasi variazione locale potrebbe essere sovrascritta al successivo refresh delle policy. Quindi la correzione definitiva va fatta dove la policy nasce, non solo sul client, se vuoi evitare che l’errore torni.

1. Apri l’Editor Criteri di gruppo locali con gpedit.msc oppure, in ambiente domain, identifica la GPO che imposta Windows Update.
2. Vai su Computer Configuration > Administrative Templates > System e cerca la policy Specify settings for optional component installation and component repair.
3. Abilita la policy e attiva l’opzione che consente il download dei contenuti opzionali e di ripristino direttamente da Windows Update invece che da WSUS.
4. Forza l’aggiornamento delle policy con gpupdate /force.
5. Riprova l’installazione di RSAT con PowerShell: Get-WindowsCapability -Online | Where-Object Name -like 'Rsat*' | Add-WindowsCapability -Online.

Se preferisci una verifica più chirurgica, controlla prima se la policy è effettivamente applicata con gpresult /h C:\Temp\gp.html e cerca il settaggio relativo ai componenti opzionali. L’atteso è che la macchina risulti autorizzata a recuperare i payload da Windows Update.

Installazione via PowerShell: meno rumore, più controllo

Il percorso grafico di Impostazioni funziona, ma PowerShell è più utile quando vuoi capire cosa sta succedendo davvero. Il punto non è “fare più veloce”, è vedere l’errore nel punto esatto in cui compare.

1. Apri una console PowerShell con privilegi amministrativi.
2. Elenca le capability RSAT disponibili con Get-WindowsCapability -Online | Where-Object Name -like 'Rsat*' | Select-Object Name, State.
3. Installa il modulo necessario, per esempio: Get-WindowsCapability -Online | Where-Object Name -eq 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0' | Add-WindowsCapability -Online.
4. Se il comando fallisce, annota il codice restituito e confrontalo con il log di Windows Update in %windir%\Logs\CBS\CBS.log e con l’Event Viewer sotto Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational.

Per RSAT conviene spesso installare solo i componenti che servono davvero. Non c’è un vantaggio operativo a portarsi dietro tutto il catalogo se ti serve solo Active Directory, DNS o Group Policy Management. Meno superficie, meno tempo di download, meno probabilità di incastrarsi su un singolo pacchetto difettoso.

Se la cache di Windows Update è sporca

Quando la policy è corretta ma l’errore persiste, la cache locale è il sospetto successivo. Qui l’obiettivo non è “pulire tutto”, ma rimuovere il minimo necessario per forzare un nuovo ciclo di download. Il blast radius è limitato al client, ma resta una modifica di stato: meglio farla con rollback chiaro.

1. Apri un prompt amministrativo.
2. Ferma i servizi coinvolti con net stop wuauserv e net stop bits.
3. Rinomina la cache invece di cancellarla: ren C:\Windows\SoftwareDistribution SoftwareDistribution.old.
4. Riavvia i servizi con net start bits e net start wuauserv.
5. Riprova l’installazione di RSAT.

Il rollback è immediato: se qualcosa va storto, puoi fermare i servizi e ripristinare la cartella rinominandola nel nome originale. In ambienti gestiti, però, conviene documentare l’operazione perché il problema potrebbe ripresentarsi se c’è un proxy, un filtro o un repository interno che continua a servire contenuti incompleti.

Quando il problema è la versione di Windows o il canale di distribuzione

Non tutte le build gestiscono RSAT nello stesso modo. Su sistemi non allineati, soprattutto se non aggiornati da tempo, alcune capability possono risultare presenti nel catalogo ma non installabili dal canale corrente. In questi casi l’errore non dice “manca RSAT”, ma “il percorso di acquisizione del payload non è coerente con la macchina”.

1. Verifica se la macchina è aggiornata con winver e con Get-ComputerInfo | Select-Object WindowsVersion, WindowsBuildLabEx.
2. Controlla gli aggiornamenti cumulativi mancanti in Settings > Windows Update oppure con Get-HotFix.
3. Se il sistema è molto indietro, porta prima Windows a una build supportata e solo dopo ripeti l’installazione di RSAT.

In un ambiente enterprise, questa non è una correzione cosmetica: una build vecchia può essere la causa del fallimento, ma anche il moltiplicatore di altri problemi. Aggiornare il sistema prima di diagnosticare troppo a fondo è spesso il modo più rapido per evitare false piste.

Controlli finali: come capire che l’errore è davvero risolto

La verifica non è “il wizard non mostra più l’errore”. Serve una conferma funzionale: la capability deve risultare installata e il relativo snap-in deve aprirsi senza warning.

1. Riesegui Get-WindowsCapability -Online | Where-Object Name -like 'Rsat*' | Select-Object Name, State e controlla che il componente desiderato sia Installed.
2. Apri lo strumento corrispondente, per esempio dsa.msc per Active Directory Users and Computers o gpmc.msc per Group Policy Management.
3. Controlla che non compaiano nuovi errori in Event Viewer sotto WindowsUpdateClient o CBS.
4. Se hai modificato una policy, verifica che il comportamento sia stabile dopo gpupdate /force e un riavvio, perché il vero test è il refresh della configurazione, non il primo avvio fortunato.

Se dopo questi passaggi RSAT si installa solo quando bypassi WSUS, la root cause è quasi certamente nel flusso di distribuzione aziendale e non nel singolo client. In quel caso la correzione strutturale sta nella GPO o nella configurazione del server di aggiornamento, non nel ripetere l’installazione all’infinito su ogni postazione.

Fix strutturale in ambiente gestito

Se il problema è ricorrente su più endpoint, la soluzione vera è centralizzare la correzione. In pratica: rendere disponibile il download delle feature opzionali da Windows Update per i client che ne hanno bisogno, oppure preparare in modo corretto il catalogo di distribuzione se usi un’infrastruttura interna che deve servire anche i payload delle componenti opzionali.

Qui la verifica minima è doppia: lato client vedi la policy applicata e lato server confermi che il canale scelto è coerente con il tipo di contenuto richiesto. Se WSUS è usato solo per patch e non per feature on demand, forzare tutto lì è un errore di design, non un dettaglio operativo.

Assunzione operativa: i passaggi sopra sono pensati per Windows 10/11 in contesto desktop o dominio; se la macchina è soggetta a policy più restrittive, la modifica va fatta sul criterio di gruppo centrale e non solo localmente.