Come risolvere l’errore 0x800f0907 su Windows Server 2019 e 2022 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 17/10/2026 Pubblicato il: 17/10/2026 04:00 Tempo di lettura: 11 min

L’errore 0x800f0907 su Windows Server 2019 e 2022 compare quasi sempre quando un’operazione di manutenzione dei componenti di sistema fallisce: installazione di un aggiornamento, ripristino di feature, aggiunta di ruoli, riparazione del component store o esecuzione di DISM. In pratica, il sistema non riesce a completare una richiesta che dipende da servicing stack, Windows Update, componenti opzionali o sorgenti di ripristino. Il punto non è “forzare” la correzione, ma capire quale layer si è rotto: repository componenti, sorgente locale, policy di update, connettività verso WSUS/WU, oppure corruzione del file system o del component store.

Su Server 2019/2022 il comportamento è spesso simile, ma la diagnosi cambia in base al contesto: server standalone, dominio con WSUS, macchina isolata, ruolo Hyper-V, file server, nodo RDS o host di virtualizzazione. L’errore 0x800f0907 non ha una sola causa. Il modo corretto di trattarlo è partire dall’evidenza minima, verificare i log giusti e poi applicare la correzione meno invasiva possibile, con rollback chiaro se si toccano policy, sorgenti o componenti di Windows.

Quando compare davvero 0x800f0907

Il codice viene spesso visto in questi casi:

installazione di un aggiornamento cumulativo o delle Features on Demand;
esecuzione di DISM /Online /Cleanup-Image /RestoreHealth;
aggiunta di ruoli o funzionalità da Server Manager o PowerShell;
riparazione di Windows con sorgenti locali o con accesso a Windows Update;
component store danneggiato dopo crash, reboot forzati o spazio disco insufficiente.

La trappola classica è scambiare il sintomo per la causa. 0x800f0907 è spesso il risultato finale di un problema precedente: una policy che blocca il download dei componenti, una sorgente di ripristino non valida, un repository locale incoerente, oppure file di sistema corrotti. Se si parte subito con comandi aggressivi senza leggere i log, si perde tempo e si aumenta il rischio di cambiare più variabili insieme.

Prima verifica: capire il layer coinvolto

Il primo obiettivo è distinguere tra problema di servicing, problema di rete/policy e problema di integrità del sistema. Questa distinzione guida tutta la correzione.

Servicing / component store: DISM fallisce anche con sorgente valida, SFC trova corruzioni ripetute, CBS.log mostra errori di package o manifest.
Rete / policy: il server è dietro WSUS, GPO blocca l’accesso a Windows Update, proxy o firewall interferiscono, oppure manca la sorgente di ripristino.
Integrità locale: spazio disco basso, file system sporco, errori NTFS, riavvii incompleti, file di sistema danneggiati.

Per non andare a tentativi, raccogli subito tre evidenze: il messaggio preciso dell’errore, il comando che lo ha generato e il contenuto dei log CBS/DISM. Con quelle tre informazioni, nella maggior parte dei casi si capisce se servono una sorgente ISO, una correzione della policy o una riparazione del component store.

Verifiche immediate da fare prima di toccare la configurazione

Questi controlli sono rapidi e reversibili. Servono a evitare correzioni inutili o dannose.

Controlla lo stato di Windows Update e del servicing stack.
```
sc query wuauserv
sc query bits
sc query trustedinstaller
```
Atteso: i servizi non devono essere in stato anomalo se l’operazione dipende da update o componenti opzionali. Se uno è fermo, non significa automaticamente guasto, ma va correlato al log.
Verifica spazio libero e salute del disco.
```
wmic logicaldisk get caption,freespace,size,volumename
chkdsk C: /scan
```
Atteso: spazio libero sufficiente su volume di sistema e nessun errore file system evidente. Se il disco è quasi pieno, DISM e gli update falliscono facilmente con sintomi ambigui.
Leggi il log CBS e quello di DISM.
```
findstr /c:"0x800f0907" %windir%\Logs\CBS\CBS.log
findstr /c:"0x800f0907" %windir%\Logs\DISM\dism.log
```
Atteso: una riga che indichi package, feature o source path coinvolto. Se il log parla di sorgente mancante o file non trovati, la causa è quasi certamente nel percorso di ripristino o nella policy di download.
Controlla se il server usa WSUS o policy restrittive.
```
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s
```
Atteso: se sono presenti valori come WUServer o UseWUServer, l’origine degli aggiornamenti può essere vincolata. Questo è uno dei punti più frequenti nei server di dominio.

Cause più probabili e come falsificarle in pochi minuti

Le ipotesi più probabili, in ordine pratico, sono queste.

La sorgente di ripristino non è disponibile o non è coerente.
Falsificazione rapida: monta una ISO della stessa build/edizione e prova la riparazione puntando esplicitamente al file install.wim o install.esd. Se con una sorgente valida il comando passa, il problema era lì.
WSUS, policy o proxy impediscono il download dei componenti mancanti.
Falsificazione rapida: verifica la policy UseWUServer, controlla se il server raggiunge gli endpoint di update o prova temporaneamente una sorgente locale. Se disattivando il vincolo il problema sparisce, la root cause è di policy/rete.
Corruzione del component store o di file di sistema.
Falsificazione rapida: esegui SFC e poi DISM /RestoreHealth. Se SFC trova corruzioni ma non riesce a ripararle, e DISM fallisce senza sorgente valida, il problema è quasi certamente nel repository locale.

Procedura consigliata passo-passo

La sequenza sotto parte dalla verifica meno invasiva e arriva solo dopo alla modifica della sorgente o della policy. Se il server è in produzione, esegui ogni passaggio in finestra di manutenzione o almeno con change approvato, perché alcune correzioni richiedono riavvio o impattano il canale di aggiornamento.

Raccogli evidenza e salva i log utili.
```
mkdir C:\Temp\logs 2>nul
copy %windir%\Logs\CBS\CBS.log C:\Temp\logs\CBS.log
copy %windir%\Logs\DISM\dism.log C:\Temp\logs\dism.log
```
Questo non risolve il problema, ma ti evita di perdere il contesto se il sistema ruota i log. Se devi aprire un ticket interno o confrontare prima/dopo, questi file sono la base.
Esegui SFC.
```
sfc /scannow
```
Atteso: nessuna violazione di integrità, oppure violazioni riparate. Se SFC segnala file corrotti non ripristinabili, non passare subito ad altre feature: serve prima sistemare il component store.
Esegui DISM con sorgente locale, se disponibile.
```
dism /online /cleanup-image /restorehealth
```
Se il comando fallisce con 0x800f0907, prova con una sorgente esplicita. Monta la ISO della stessa versione/build del server e identifica l’indice corretto:
```
dism /Get-WimInfo /WimFile:D:\sources\install.wim
```
Poi esegui:
```
dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:<INDEX> /limitaccess
```
Atteso: DISM completa il ripristino senza chiedere Windows Update. Se il comando fallisce anche così, la sorgente è sbagliata oppure il danno è più profondo.
Se il server usa WSUS e il download è bloccato, testa temporaneamente una correzione della policy.
```
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f
net stop wuauserv
net start wuauserv
```
Questa modifica ha blast radius sul comportamento di Windows Update del server. Va considerata solo se hai confermato che la macchina dipende da WSUS e la sorgente locale non basta. Rollback: riportare UseWUServer a 1 e riavviare il servizio.
Riavvia i servizi coinvolti e riprova l’operazione originale.
```
net stop bits
net stop trustedinstaller
net start trustedinstaller
net start bits
```
Non sempre tutti i servizi si fermano pulitamente, ma il punto è ridurre lo stato incoerente dopo tentativi falliti. Se l’errore si presenta durante l’installazione di una feature, ripeti il comando o passa da Server Manager dopo aver corretto la sorgente.
Controlla e, se necessario, ripara il file system.
```
chkdsk C: /scan
```
Se emergono errori, pianifica la correzione in finestra di manutenzione. Non forzare una riparazione offline senza contesto: su un server con carico o ruoli critici il rischio operativo aumenta. Se il volume mostra problemi, qualsiasi riparazione del component store può fallire di nuovo.

Fix tipici in base allo scenario

Alcuni contesti ricorrono spesso e meritano una correzione mirata invece di una diagnosi generica.

Server con WSUS

Se il server è vincolato a WSUS, 0x800f0907 può uscire quando la feature richiesta non è presente nel catalogo locale o quando i componenti on-demand non sono autorizzati a scendere da Microsoft Update. In questo caso il sintomo non è “internet assente”, ma catena di update incompleta. La verifica più utile è il registro policy e il log WindowsUpdate. Se il server deve rimanere su WSUS, assicurati che il repository contenga i pacchetti necessari o che esista una procedura documentata per usare sorgenti locali.

Rollback: ripristina la chiave UseWUServer e l’eventuale policy di gruppo dopo il test. Se hai usato una modifica locale al registro, annota il valore precedente prima di cambiarlo.

Server isolato o senza accesso a Windows Update

Qui la soluzione pulita è quasi sempre una sorgente locale corretta. La ISO deve corrispondere alla stessa release e, idealmente, allo stesso livello di aggiornamento base. Una ISO sbagliata produce un falso positivo: il comando parte, ma il ripristino fallisce con altri codici o con 0x800f0907 perché i manifest non combaciano.

Se lavori su più server, conviene tenere una share interna con le ISO approvate e il relativo hash. In ambienti con controllo change, questo evita di usare supporti non verificati o versioni non allineate.

Errore durante l’aggiunta di ruoli o feature

Quando il problema compare in Server Manager o con PowerShell, il primo sospetto è la sorgente dei file binari. Verifica il nome esatto della feature e, se necessario, installa il ruolo usando una sorgente esplicita. In alcuni casi è più affidabile usare DISM o Add-WindowsFeature con un path ben definito invece dell’interfaccia grafica, perché il log è più leggibile e il comportamento è più deterministico.

Esempio di controllo della feature:

Get-WindowsFeature *<nome-feature>*

Se la feature risulta disponibile ma non installabile, guarda i dettagli nel log di installazione e nel CBS log. Se invece non è presente nel payload del sistema, serve la sorgente corretta o il pacchetto FoD appropriato.

Comandi utili per una diagnosi pulita

Questi comandi non risolvono da soli il problema, ma riducono il tempo per arrivare alla causa.

Verifica versione e build del sistema:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Controlla lo stato del component store:
```
dism /online /cleanup-image /scanhealth
```

Consulta i dettagli di un errore specifico nel CBS log:

findstr /i /c:"error" %windir%\Logs\CBS\CBS.log > C:\Temp\logs\CBS-errors.txt

Esamina la presenza di policy Windows Update:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Se usi una ISO, identifica l’indice corretto della build:
```
dism /Get-WimInfo /WimFile:D:\sources\install.wim
```

Cosa non fare

Ci sono alcune scorciatoie che in ambienti server fanno più danni che altro.

Non cambiare insieme sorgente, policy e servizi senza sapere quale modifica ha funzionato.
Non usare una ISO a caso: edizione, build e lingua contano.
Non cancellare manualmente componenti di WinSxS o file di sistema per “fare pulizia”.
Non disattivare a lungo Windows Update o BITS su un server di produzione solo per aggirare l’errore.
Non ignorare lo spazio disco: se il volume di sistema è saturo, la riparazione fallisce di nuovo anche dopo un fix apparente.

Controlli finali e rollback

Dopo la correzione, conferma che il sistema sia davvero tornato in uno stato sano e non solo che il singolo comando sia passato una volta.

Riesegui il comando che generava 0x800f0907 e verifica che completi senza errori.

Controlla di nuovo i log CBS e DISM per assenza di nuovi errori correlati.

findstr /c:"0x800f0907" %windir%\Logs\CBS\CBS.log
findstr /c:"0x800f0907" %windir%\Logs\DISM\dism.log

Se hai modificato una policy, ripristina il valore originale e documenta la modifica in change record o ticket operativo.
Se hai usato una sorgente locale, conserva il path e l’indice usato, così il fix resta replicabile in caso di nuovo incidente.

Rollback operativo: riportare eventuali chiavi di Windows Update ai valori iniziali, fermare eventuali test di bypass della policy, smontare la ISO se non più necessaria e conservare i log raccolti. Assunzione: il server è un Windows Server 2019 o 2022 con privilegi amministrativi locali e accesso ai log di sistema; se è gestito via GPO/WSUS, la correzione definitiva va allineata con la policy di dominio.

In sintesi, 0x800f0907 non si risolve bene con un singolo comando “magico”. Si chiude in modo affidabile quando il file sorgente è corretto, la policy non blocca il recupero dei componenti e il component store non è già compromesso. Se una di queste tre condizioni manca, il codice tornerà a presentarsi al primo aggiornamento o alla prima feature che richiede file non disponibili localmente.