La promozione di un nuovo Domain Controller Windows Server 2022 può bloccarsi con l’errore “adprep validation / unable to check the forest upgrade status” (eccezione Win32 -2147467259, 0x80004005). Questa guida spiega cause, diagnosi e rimedi affidabili per completare l’installazione in modo sicuro.
Panoramica del problema
Durante l’installazione del ruolo Active Directory Domain Services e la successiva promozione del server a Domain Controller (DC), la procedura tenta di verificare in automatico se la foresta richiede l’esecuzione di adprep
. In alcuni ambienti la fase AD Prep / VerifyForestUpgradeStatus fallisce con l’eccezione Win32 -2147467259
(0x80004005 – “Unspecified error”). Il messaggio risultante suggerisce che il sistema non è in grado di determinare lo stato della foresta e quindi non può completare la promozione del DC.
Il sintomo più comune è la chiusura della procedura guidata di promozione o il fallimento del cmdlet PowerShell Install-ADDSDomainController
con un riferimento ad adprep validation non riuscita. Nei log vengono spesso citati componenti di connettività (RPC/LDAP) o la necessità di aggiornare lo schema/il dominio.
Perché accade
La convalida di adprep
richiede che il nuovo server:
- Riesca a contattare il Schema Master e il Domain Naming Master via DNS, LDAP e RPC;
- Operi in una foresta/dominio con Functional Level compatibili (almeno Windows Server 2008 per FFL e DFL);
- Trovi la replica SYSVOL già su DFS‑R (non su FRS/NTFRS), perché Server 2022 non supporta più FRS;
- Disponga dei privilegi corretti (Enterprise Admins + Schema Admins) per eseguire gli aggiornamenti di schema e dominio, se richiesti;
- Non incontri blocchi dovuti a DNS errato, firewall, time skew, o logiche di hardening che impediscono l’inizializzazione di RPC/SMB;
- Non sia ostacolato da uno stato anomalo della replica o da migrazioni SYSVOL incomplete.
Se uno qualsiasi di questi prerequisiti viene meno, la verifica automatica si interrompe con l’errore generico, impedendo la promozione.
Checklist di diagnosi e rimedio
La seguente tabella riassume i passaggi consigliati con motivazioni; i paragrafi più sotto forniscono i dettagli operativi, i comandi e le verifiche.
Passaggio | Dettaglio | Perché è importante |
---|---|---|
Verificare i Functional Level | Controllare che FFL e DFL siano almeno Windows Server 2008. | Server 2022 non può essere aggiunto a domini/foreste con livello inferiore. |
Controllare la replica di SYSVOL | Accertarsi che SYSVOL sia su DFS‑R, non su FRS/NTFRS. | Server 2022 non supporta il motore legacy FRS. |
Convalidare AD Prep | Eseguire manualmente adprep /forestprep e adprep /domainprep dal DC Schema Master, verificando assenza errori. | Garantisce schema aggiornato prima del join del nuovo DC. |
Verificare permessi e connettività | Usare un account Enterprise Admins + Schema Admins; controllare DNS, LDAP/LDAPS, SMB, RPC 135 e porte dinamiche. | Errori di credenziali o rete spesso generano l’eccezione generica. |
Riavvio dei server | Riavviare DC sorgente e nuovo server dopo adprep e dopo le modifiche DFS‑R. | Forza rilettura di livelli funzionali e stato replica. |
Controlli post‑migrazione | Usare dcdiag , repadmin /replsummary e l’Event Viewer (ID 135, 2213) per confermare la salute del dominio. | Convalida che la promozione sia stabile e priva di errori latenti. |
Diagnostica guidata, comando per comando
Identificare il Schema Master e gli altri ruoli FSMO
Eseguire da un DC esistente o da una postazione con RSAT:
netdom query fsmo
oppure con PowerShell:
Import-Module ActiveDirectory
(Get-ADForest).SchemaMaster
(Get-ADForest).DomainNamingMaster
(Get-ADDomain).PDCEmulator
Se lo Schema Master non è raggiungibile, la verifica di adprep
fallirà. Ripristinarne la raggiungibilità o trasferire il ruolo prima di proseguire.
Controllare i Functional Level
Import-Module ActiveDirectory
(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Assicurarsi che entrambi siano ≥ Windows Server 2008. Se necessario, valutare l’innalzamento con gli strumenti nativi di AD DS, dopo aver verificato pienamente la replica e la compatibilità applicativa.
Verificare lo stato di SYSVOL (FRS vs DFS‑R)
In un dominio sano e moderno, SYSVOL deve essere replicato tramite DFS‑R. Controllare lo stato di migrazione:
dfsrmig /getglobalstate
dfsrmig /getmigrationstate
Se getglobalstate
< 3 o getmigrationstate
non raggiunge “Eliminated”, significa che la migrazione da FRS a DFS‑R non è completa. Portare lo stato a 3:
dfsrmig /setglobalstate 1
dfsrmig /getmigrationstate
dfsrmig /setglobalstate 2
dfsrmig /getmigrationstate
dfsrmig /setglobalstate 3
dfsrmig /getmigrationstate
Procedere oltre solo quando tutti i DC riportano “Eliminated”. In caso contrario, Server 2022 continuerà a rifiutare la promozione.
Controllare DNS, tempo e porte
- DNS: il nuovo server deve usare come preferred DNS un DC interno autorevole per la zona AD (no DNS pubblico). Verifica rapida:
ipconfig /all nslookup ldap.tcp.dc._msdcs.<ForestRootFQDN>
- Tempo: la deriva temporale invalida Kerberos. Verificare e, se necessario, riallineare:
w32tm /query /status w32tm /resync /nowait
- Porte minime da consentire tra il nuovo server e i DC esistenti:
- TCP/UDP 53 (DNS)
- TCP/UDP 88 (Kerberos)
- TCP 135 (RPC Endpoint Mapper)
- TCP 445 (SMB)
- TCP/UDP 389 (LDAP), TCP 636 (LDAPS)
- TCP 3268/3269 (GC/GC SSL)
- Porte RPC dinamiche (default 49152–65535 su sistemi moderni)
Esecuzione manuale di AD Prep
Eseguire adprep
sempre dalla cartella \support\adprep
del media di Windows Server 2022, sul DC con ruolo Schema Master, usando un utente membro di Enterprise Admins e Schema Admins (prompt elevato):
adprep.exe /forestprep
adprep.exe /domainprep
Al termine, verificare i log:
C:\Windows\Debug\adprep\logs\adprep.log
C:\Windows\Debug\adprep\logs\adprep_YYYYMMDD-XXXXXXX.log
Lo schema di AD coerente con Server 2022 corrisponde a objectVersion = 88. Verifica rapida via PowerShell:
Import-Module ActiveDirectory
$schemaDN = (Get-ADRootDSE).schemaNamingContext
(Get-ADObject $schemaDN -Properties objectVersion).objectVersion
Permessi effettivi e hardening
La convalida fallisce anche quando l’account usato non possiede effettivamente i permessi, oppure quando GPO o soluzioni di hardening bloccano componenti necessari (es. DCOM/RPC, SMB, LDAP signing obbligatorio non compatibile, TLS anomalo). Effettuare il test con un utente di Enterprise Admins + Schema Admins e provare da una sessione elevata su un DC, per discriminare un problema di policy locale dal problema di rete.
Riavvio mirato
Dopo aver eseguito adprep
e/o modifiche a DFS‑R, riavviare sia il DC sorgente (Schema Master) sia il nuovo server. Il riavvio forza la rilettura dei livelli funzionali, degli attributi di schema e reinizializza canali RPC/SMB.
Verifiche post‑migrazione
Dopo la promozione, validare la salute del dominio:
dcdiag /v
repadmin /replsummary
repadmin /showrepl *
Controllare l’Event Viewer su ciascun DC. Eventi da osservare:
- DFS Replication: ID 2213 (replica sospesa dopo spegnimento improvviso). Se presente, seguire la procedura di ripristino e riprendere la replica prima di riprovare la promozione.
- FRS/DFSR: ID 135/135xx in caso di FRS (retaggio) o errori di inizializzazione/replica SYSVOL.
Playbook operativo completo
- Preflight
- Connettere il nuovo server alla rete dei DC; configurare DNS verso un DC interno.
- Verificare NTP/tempo; disattivare temporaneamente firewall locali per test (o aprire le porte elencate).
- Inventario ruoli e livelli
netdom query fsmo
→ identificare lo Schema Master.- PowerShell → controllare
(Get-ADForest).ForestMode
e(Get-ADDomain).DomainMode
.
- SYSVOL
dfsrmig /getglobalstate
e/getmigrationstate
.- Se non “Eliminated”, completare la migrazione a DFS‑R fino a stato 3.
- Schema e dominio
- Dal DC Schema Master:
adprep /forestprep
→ verificare log. - Quindi
adprep /domainprep
sul dominio target. - Controllo
objectVersion
= 88 nello Schema.
- Dal DC Schema Master:
- Reboot mirato
- Riavviare Schema Master e nuovo server.
- Promozione
- Eseguire la procedura guidata o
Install-ADDSDomainController
.
- Eseguire la procedura guidata o
- Post‑promozione
dcdiag
,repadmin
, Event Viewer → assenza errori.- Verificare la condivisione
SYSVOL
e la registrazione DNS del nuovo DC.
Script di verifica rapida
Lo script seguente aiuta a riassumere lo stato dell’ambiente prima della promozione.
Import-Module ActiveDirectory
Write-Host "=== FSMO Roles ==="
(Get-ADForest).SchemaMaster
(Get-ADForest).DomainNamingMaster
(Get-ADDomain).PDCEmulator
Write-Host "=== Functional Levels ==="
"{0}" -f (Get-ADForest).ForestMode
"{0}" -f (Get-ADDomain).DomainMode
Write-Host "=== Schema Version ==="
$schemaDN = (Get-ADRootDSE).schemaNamingContext
"objectVersion: {0}" -f (Get-ADObject $schemaDN -Properties objectVersion).objectVersion
Write-Host "=== DNS SRV Records ==="
Resolve-DnsName -Type SRV ldap.tcp.dc._msdcs.$((Get-ADForest).Name) -ErrorAction SilentlyContinue
Write-Host "=== SYSVOL/DFSR Migration State ==="
cmd /c "dfsrmig /getglobalstate"
cmd /c "dfsrmig /getmigrationstate"
Write-Host "=== Replication Health ==="
cmd /c "repadmin /replsummary"
Approfondimenti su errori tipici e rimedi
Functional Level troppo basso
In foreste/domìni rimasti a Windows Server 2003 o inferiori, Server 2022 rifiuta l’introduzione di nuovi DC. Pianificare l’innalzamento del livello funzionale a Windows Server 2008 o superiore, previa validazione della compatibilità applicativa e della replica.
SYSVOL ancora su FRS
Se il dominio usa FRS, completare la migrazione a DFS‑R. Una migrazione parziale (stati 0–2) è una delle cause più frequenti dell’errore di adprep validation. Attendere che dfsrmig /getmigrationstate
riporti “Eliminated” per tutti i DC.
Schema non aggiornato o permessi insufficienti
Se adprep
fallisce, controllare il gruppo dell’account (deve essere Enterprise Admins e Schema Admins), riprovare eseguendo il comando dal DC Schema Master, quindi rileggere i log in C:\Windows\Debug\adprep\logs\
per la causa specifica (attributi, classi, ACL).
Problemi di DNS, RPC o firewall
DNS mal configurato (ad es. server che punta a DNS pubblico) impedisce di localizzare correttamente GC e FSMO, traducendosi in errori generici. Aprire le porte elencate, verificare le sessioni RPC dinamiche e la risoluzione dei record SRV. In ambienti con firewall L7 o IDS, assicurarsi che l’ispezione non tronchi i binding RPC.
Time skew e Kerberos
Una differenza di tempo superiore a pochi minuti tra i server può causare errori nelle security context init. Assicurare che il nuovo server si sincronizzi con l’ora del PDC Emulator o con una gerarchia NTP corretta.
Eventi DFSR/FRS bloccanti
Eventi 2213 su DFSR segnalano che la replica è sospesa dopo uno spegnimento non pulito: riprendere la replica seguendo la procedura di “recovery after unexpected shutdown” e ripetere la promozione solo a replica ripristinata. Eventi 135/135xx indicano spesso ancora FRS attivo o inconsistenze SYSVOL.
Appendice: mappa rapida versioni di schema e livelli funzionali
Versione Windows Server | AD Schema objectVersion | Note |
---|---|---|
2008 | 44 | Minimo livello funzionale supportato da Server 2022. |
2008 R2 | 47 | |
2012 | 56 | |
2012 R2 | 69 | |
2016 | 87 | |
2019 / 2022 | 88 | Coerenza di schema; adprep deve portare a 88. |
Nota: alcuni aggiornamenti cumulativi possono introdurre modifiche minori non impattanti per la promozione, ma il riferimento operativo per Server 2022 è 88.
Appendice: porte e dipendenze di rete
Servizio | Porte | Scopo |
---|---|---|
DNS | TCP/UDP 53 | Risoluzione nomi AD, record SRV |
Kerberos | TCP/UDP 88 | Autenticazione |
LDAP/LDAPS | TCP/UDP 389, TCP 636 | Directory bind e query |
Global Catalog | TCP 3268/3269 | Query cross-domain |
RPC | TCP 135 + dinamiche | Gestione AD DS, replica, DCOM |
SMB | TCP 445 | Condivisione SYSVOL , gestione file |
Come leggere i log di adprep
I file in C:\Windows\Debug\adprep\logs\
forniscono il dettaglio di ogni passaggio: classe/attributo creato o aggiornato, ACL modificati, eventuali conflitti. Cercare le stringhe ERROR
e WARNING
per circoscrivere rapidamente la causa. In caso di conflitti di schema dovuti a estensioni di terze parti, valutare una finestra di manutenzione per disabilitare filtri o controlli di sicurezza che inibiscono modifiche a classi e attributi.
Risoluzione passo‑passo consigliata
- Completare la migrazione SYSVOL a DFS‑R (
dfsrmig
fino a “Eliminated”). - Eseguire
adprep /forestprep
eadprep /domainprep
dal DC Schema Master con privilegi adeguati. - Verificare
objectVersion
= 88 nello schema. - Riavviare Schema Master e nuovo server.
- Ripetere la promozione con DNS, tempo e firewall corretti.
- Chiudere con
dcdiag
,repadmin
e Event Viewer puliti.
Domande frequenti
La promozione fallisce ma adprep
da riga di comando non mostra errori. Cosa controllo?
Assicurati che il nuovo server risolva correttamente i record SRV della foresta, che raggiunga lo Schema Master via RPC e che non vi siano policy che impongono requisiti TLS/LDAP incompatibili. Verifica anche eventuali Event ID 2213/135 sulla replica.
Posso lanciare adprep
dal nuovo server invece che dal DC Schema Master?
Puoi eseguire adprep
solo su un DC con il ruolo Schema Master (o comunque indirizzarlo a quel DC). È la scelta più sicura e raccomandata.
Che versione di schema devo vedere per Server 2022?
88 (objectVersion=88
).
Ho FRS ancora attivo: posso comunque promuovere un DC 2022?
No. Devi completare la migrazione a DFS‑R (dfsrmig
stato 3 “Eliminated”).
L’errore -2147467259 significa qualcosa di specifico?
È un codice generico (0x80004005). Di solito è la punta dell’iceberg: cerca la causa reale in connettività, permessi, schema o replica.
Esempio di promozione via PowerShell (dopo i prerequisiti)
# Eseguire sul nuovo server, con prerequisiti soddisfatti
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Esempio: aggiunta di un DC aggiuntivo nel dominio corrente
Install-ADDSDomainController ` -Credential (Get-Credential)`
-DomainName "contoso.local" ` -SiteName "Default-First-Site-Name"`
-InstallDNS ` -NoGlobalCatalog:$false`
-SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password") `
-Force
Checklist stampabile
- FFL/DFL ≥ Windows Server 2008 (OK/KO)
- SYSVOL replicato con DFS‑R,
dfsrmig
= 3 “Eliminated” (OK/KO) - Schema aggiornato con
adprep
,objectVersion
= 88 (OK/KO) - Account in Enterprise Admins + Schema Admins (OK/KO)
- DNS corretto, NTP allineato, porte aperte (OK/KO)
- Riavvio Schema Master e nuovo server (OK/KO)
dcdiag
erepadmin
senza errori (OK/KO)
Conclusioni
Il blocco “adprep validation / unable to check the forest upgrade status” è quasi sempre la conseguenza di prerequisiti non soddisfatti o di un ambiente AD non pienamente sano (SYSVOL su FRS, replica in stato anomalo, connettività o permessi non corretti). Applicando l’ordine di controllo proposto — livelli funzionali, migrazione DFS‑R, adprep
manuale, connettività e riavvii mirati — si rimuove la causa principale nella maggior parte dei casi e si dispone di log e strumenti per un’analisi puntuale quando necessario. Una volta regolarizzati schema e SYSVOL, la promozione di un DC Windows Server 2022 procede senza interruzioni, e l’infrastruttura beneficia di un livello di compatibilità e sicurezza atteso dalle piattaforme moderne.
Informazioni supplementari utili
- Aggiornamento DFS‑R: se la foresta usa ancora FRS, migrare a DFS‑R con
dfsrmig /setglobalstate 3
seguendo le best practice; solo al completamento (“Eliminated”) si possono aggiungere DC 2022. - Schema version check: per Server 2022 atteso
objectVersion=88
. - Log dettagliati: i file
C:\Windows\Debug\adprep\logs\adprep.log
eC:\Windows\Debug\adprep\logs\adprep_YYYYMMDD-XXXXXXX.log
contengono il dettaglio della causa.
Seguendo l’ordine di controllo sopra indicato si elimina la causa più frequente (functional level e DFS‑R) e, se necessario, si dispone di log e strumenti per un’analisi più profonda dell’errore.