Errore 1053 FRS e MSIS7207 AD FS: guida completa a migrazione DFSR e SPN

Guida operativa per risolvere due guasti frequenti in ambienti Active Directory: arresto del vecchio servizio di replica file dopo il passaggio a DFSR e malfunzionamenti di AD FS dovuti a SPN non risolvibili. Include checklist, comandi PowerShell e percorsi decisionali per un ripristino rapido e stabile.

Indice

Contesto e obiettivo

La migrazione della cartella SYSVOL da File Replication Service (FRS) a DFS Replication (DFSR) è uno step cruciale per la modernizzazione dei controller di dominio. Parallelamente, l’infrastruttura di federazione AD FS si basa su identità di servizio e Service Principal Name (SPN) corretti per erogare endpoint come WS‑Trust. Questo articolo fornisce un playbook pratico per affrontare due incidenti ricorrenti:

Il vecchio servizio FRS che non si avvia dopo la migrazione, generando l’evento 1053 con timeout.
AD FS che registra evento 217 con messaggio MSIS7207 per SPN non recuperabile.

Guasto del servizio di replica file dopo migrazione

Sintomo tipico: durante o subito dopo la migrazione di SYSVOL a DFSR, il vecchio servizio FRS non parte e nel registro appare l’evento “il servizio non ha risposto entro il tempo previsto”. È un falso problema nella maggior parte dei casi: dopo la migrazione completa, FRS è obsoleto e non deve essere eseguito.

Cause ricorrenti

Possibile causa	Dettagli
Servizio obsoleto ancora impostato in avvio	Dopo il passaggio definitivo a DFSR (Eliminated), FRS può restare configurato su Automatico e tentare di avviarsi senza più avere un ruolo.
Credenziali o diritti non validi	Se FRS è impostato su “Questo account” con credenziali errate o scadute, il controllo di sicurezza fallisce e provoca il timeout.
Dipendenze non attive	Servizi di base come RPC o DCOM Server Process Launcher non avviati impediscono la corretta inizializzazione.

Diagnosi immediata

Eseguire i seguenti controlli sull’host interessato. Se si opera da PowerShell con privilegi elevati, usare i comandi riportati.

# Verifica stato della migrazione SYSVOL
dfsrmig /getmigrationstate

Verifica stato servizi

Get-Service -Name ntfrs, dfsr

Ispezione rapida eventi di sistema correlati a FRS/DFSR

Get-WinEvent -LogName System |
Where-Object { $_.ProviderName -in 'NtFrs','DFSR' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Sort-Object TimeCreated -Descending |
Select-Object -First 30

Verifica dipendenze e configurazione servizio FRS

sc qc ntfrs

Interpretazione rapida:

Se la migrazione riporta Eliminated, FRS è dismesso: non tentare di ripararlo, disabilitalo.
Se la migrazione non è completa, proseguire con correzioni mirate a FRS solo se necessario per sistemi legacy.

Correzione quando la migrazione è completa

Se dfsrmig /getmigrationstate restituisce Eliminated per tutti i controller di dominio, disattivare FRS in modo permanente.

# Disabilita il servizio FRS ed evita futuri tentativi di avvio
sc config ntfrs start= disabled

Facoltativo: arresta il servizio se in stato diverso da Stopped

Stop-Service ntfrs -ErrorAction SilentlyContinue

Verifica che DFSR sia attivo e integro

Get-Service dfsr

Nota: lo spazio dopo start= è voluto dalla sintassi di sc.exe.

Correzione per ambienti che usano ancora repliche legacy

Se per motivi di compatibilità è necessario mantenere temporaneamente FRS:

Aprire services.msc e aprire le proprietà di File Replication Service.
Nella scheda Accesso, impostare Account di sistema locale oppure un account di dominio con diritti amministrativi e password valida.
Nella scheda Dipendenze, verificare e avviare preventivamente i servizi di base richiesti.
Riavviare il server e verificare la presenza dell’evento 135 (FRS avviato) o dell’evento 4614 per DFSR inizializzato senza errori.

Verifiche aggiuntive su DFSR

Per escludere anomalie residue sulla replica SYSVOL con DFSR, eseguire questi controlli:

# Stato dei membri e backlog tra due DC (sostituire i nomi)
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" `
  /smem:DC01 /rmem:DC02

Forza rilettura dell'Active Directory da parte di DFSR

dfsrdiag pollad

Eventi chiave da cercare in caso di problemi: 2212, 2213, 2214, 4604, 4612, 4614

Get-WinEvent -LogName "DFS Replication" |
Where-Object { $_.Id -in 2212,2213,2214,4604,4612,4614 } |
Sort-Object TimeCreated -Descending |
Select-Object -First 50 |
Format-List TimeCreated, Id, Message

Casi particolari da conoscere:

Blocco dopo riavvio improvviso: evento 2213 indica che la replica è stata sospesa per proteggere l’integrità. Riprendere la replica con gli strumenti supportati dal proprio sistema (ResumeReplication via WMI o console DFS Management) solo dopo aver verificato la coerenza del volume.
Sysvol non pronto: se i client non vedono le GPO, verificare la chiave HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SysVolReady impostata a 1 e lo stato della share SYSVOL.

Checklist operativa

Conferma della migrazione a DFSR su tutti i DC.
Disabilitazione di FRS dove non più necessario.
Convalida dei prerequisiti di sistema per DFSR (spazio su disco, tempo di sistema corretto, connettività tra DC).
Controllo backlog e correzione di eventuali Event ID critici.

Guasto di federazione con SPN non recuperabile

Sintomo tipico: l’endpoint WS‑Trust /adfs/services/trust/13/windowstransport non risponde; nel registro AD FS/Admin appare l’evento 217 con il messaggio MSIS7207 che indica impossibilità di recuperare gli SPN per l’account del servizio.

Perché succede

AD FS usa autenticazione integrata di Windows. Se l’identità di servizio è errata o gli SPN host/<FQDN> e http/<FQDN> non sono registrati sull’oggetto corretto (computer se si usa l’account NT SERVICE\adfssrv, oppure gMSA dedicato), la risoluzione Kerberos fallisce e il servizio non può inizializzarsi correttamente.

Percorso decisionale

Identificare l’identità di servizio: AD FS dovrebbe funzionare come NT SERVICE\adfssrv (impostazione predefinita) oppure con un gMSA di dominio (es. DOMINIO\ADFSSVC$).
Determinare la posizione corretta degli SPN:
- Se si usa adfssrv, gli SPN devono essere sul computer account del server AD FS.
- Se si usa un gMSA, gli SPN devono essere sull’oggetto gMSA.
Rimuovere duplicati su altri oggetti di directory e registrare gli SPN corretti.
Verificare replica e DNS per assicurare che la modifica sia visibile in tutta la foresta.

Comandi per diagnosi e correzione

# Verifica dell'identità del servizio
Get-WmiObject -Class Win32_Service -Filter "Name='adfssrv'" |
  Select-Object Name, StartName, State

Esempio: migrazione a gMSA (se applicabile)

Richiede modulo ActiveDirectory e creazione gMSA a priori

Install-ADServiceAccount -Identity ADFSSVC

Test-ADServiceAccount -Identity ADFSSVC

Impostare il servizio per usare il gMSA

In services.msc > AD FS > Accesso: DOMINIO\ADFSSVC$

Ricerca di SPN esistenti e duplicati

setspn -Q http/somadfs.samra.com.jo
setspn -Q host/somadfs.samra.com.jo
setspn -X  # rilevazione duplicati a livello di foresta

Registrazione SPN sull'oggetto corretto (esempio gMSA)

setspn -S host/somadfs.samra.com.jo DOMINIO\ADFSSVC$
setspn -S http/somadfs.samra.com.jo DOMINIO\ADFSSVC$

Alternativa: se si usa adfssrv, registrarli sul computer account

setspn -S host/somadfs.samra.com.jo DOMINIO\SOMADFS$

setspn -S http/somadfs.samra.com.jo DOMINIO\SOMADFS$

Verifica replica e DNS

repadmin /replsummary
dcdiag /test:DNS

Riavvio del servizio AD FS

net stop adfssrv
net start adfssrv

Pulizia cache Kerberos locale (facoltativa, per test interattivi)

klist purge

Consigli pratici:

Quando si passa da NT AUTHORITY\SYSTEM o da un account non idoneo a adfssrv o a un gMSA, verificare che il nuovo account disponga del diritto “Accedi come servizio”; su gMSA è gestito automaticamente quando si assegna l’account al servizio.
Gli SPN devono esistere una sola volta nell’intera foresta. In presenza di duplicati, rimuovere quelli errati con setspn -D sull’oggetto sbagliato.
In farm con più nodi AD FS, l’SPN rimane uno perché il nome è quello del servizio (FQDN del servizio) e non dei singoli host.

Validazione dell’endpoint WS‑Trust

Dopo il riavvio del servizio, eseguire un test di connettività dall’interno del dominio con credenziali di dominio. In ambienti di test è possibile ignorare la validazione TLS per verificare esclusivamente il percorso di autenticazione integrata.

# PowerShell moderno (solo per test in lab)
Invoke-WebRequest -UseDefaultCredentials `
  -Uri "https://somadfs.samra.com.jo/adfs/services/trust/13/windowstransport" `
  -SkipCertificateCheck -OutFile $null

Nel registro AD FS/Admin cercare l’evento 100 (avvio senza errori) e l’assenza di nuovi 217 relativi a MSIS7207.

Tabella cause e azioni

Problema	Azione chiave
Servizio in esecuzione con identità errata	Impostare NT SERVICE\adfssrv o un gMSA dedicato; evitare NT AUTHORITY\SYSTEM.
SPN mancanti	Registrare `host/<FQDN>` e `http/<FQDN>` sull’oggetto corretto (computer o gMSA).
SPN duplicati	Identificare i duplicati con `setspn -X` e rimuoverli dagli oggetti errati con `setspn -D`.
Replica o DNS non coerenti	Sanare errori con `repadmin /replsummary` e `dcdiag /test:DNS`; attendere convergenza.

Procedure guidate passo dopo passo

Playbook per l’incidente di replica file

Confermare lo stato DFSR: eseguire dfsrmig /getmigrationstate. Se tutti i DC risultano Eliminated, FRS è superfluo.
Stabilizzare i servizi: se FRS tenta comunque l’avvio, impostare Disabled e assicurarsi che DFSR sia Running.
Verificare health della replica: controllare backlog, eventi 4604/4614 e assenza di 2212/2213.
Riconciliare le condivisioni: controllare che SYSVOL e NETLOGON siano pubblicate e accessibili.
Documentare la dismissione: aggiornare runbook e criteri per evitare tentativi di ripristino di FRS da strumenti legacy.

Playbook per l’incidente AD FS con SPN

Allineare l’identità di servizio: impostare adfssrv o il gMSA designato.
Correggere gli SPN: inserire host/<FQDN> e http/<FQDN> sullo stesso oggetto e rimuovere duplicati.
Confermare la convergenza: attendere replica AD, validare DNS e flush della cache Kerberos dove necessario.
Riavviare e validare: riavviare il servizio adfssrv, verificare l’evento 100 e testare l’endpoint WS‑Trust.
Stabilizzare la configurazione: se l’ambiente è di test o piccolo, considerare re‑installazione pulita con gMSA già previsto.

Approfondimenti e casi reali

Interazione tra replica SYSVOL e criteri di gruppo

La stabilità della replica SYSVOL influisce direttamente su GPO e script di accesso. In presenza di backlog elevato o sospensioni della replica, i client potrebbero applicare criteri obsoleti. Oltre ai controlli DFSR, monitorare Event Viewer > GroupPolicy sui DC e sui client campione, e confrontare l’hash delle cartelle \<dc>\SYSVOL<domain>\Policies tra almeno due controller di dominio.

Ottimizzazione DNS per AD FS

Un endpoint AD FS che oscilla tra funzionante e non funzionante dopo modifiche agli SPN può soffrire di split‑brain DNS o caching differenziale. Verificare che il record A/CNAME per il nome del servizio punti coerentemente a tutti i nodi previsti (o al bilanciatore) e che i TTL siano adeguati al piano di change. Eseguire ipconfig /flushdns sui client di test per eliminare variabili locali.

Account di servizio gestito

L’uso di un gMSA per AD FS semplifica la rotazione delle credenziali e la gestione degli SPN. Assicurarsi che:

L’oggetto gMSA abbia PrincipalsAllowedToRetrieveManagedPassword contenente i server AD FS.
Sia stato eseguito Install-ADServiceAccount su ogni nodo AD FS.
Sia impostato come identità del servizio senza specificare password in chiaro.

Audit e sicurezza

Registrare le modifiche a SPN e identità di servizio in un registro di change. Attivare auditing di directory per Service Principal Name e monitorare eventi anomali legati a Kerberos (es. ticket granting falliti) per intercettare regressioni tempestivamente.

Domande frequenti

Come verificare rapidamente se DFSR ha completato la migrazione

Usare dfsrmig /getmigrationstate. Solo quando tutti i DC riportano Eliminated è sicuro disabilitare FRS.

È un problema se FRS non si avvia dopo la migrazione

No, è atteso. Se la migrazione è al termine, disabilitare FRS per eliminare tentativi di avvio e ridurre rumore nei log.

Dove registrare gli SPN quando AD FS usa l’account predefinito

Quando AD FS usa l’identità NT SERVICE\adfssrv, gli SPN devono essere sul computer account del server che ospita AD FS.

Come individuare rapidamente duplicati di SPN

Eseguire setspn -X per cercare duplicati in foresta e setspn -Q http/<FQDN> per interrogare un SPN specifico.

Quali eventi confermano l’avvio pulito

Per DFSR cercare 4604/4614; per AD FS cercare 100 in AD FS/Admin e l’assenza di nuovi 217.

Best practice per evitare ricadute

Nei nuovi DC, usare DFSR per SYSVOL fin dall’installazione, evitando qualsiasi dipendenza da FRS.
Mantenere i server aggiornati con gli ultimi aggiornamenti cumulativi di Windows Server che riguardano DFSR e AD FS.
Per AD FS, preferire gMSA o l’identità predefinita adfssrv; evitare account locali o di sistema non supportati.
Prima di reinstallare AD FS, esportare le chiavi di firma e decrittazione con PowerShell (Get-AdfsCertificate) e salvare i bind di HTTP.sys.
Automatizzare controlli periodici su SPN, backlog DFSR e salute DNS per individuare tempestivamente derive di configurazione.

Esempi di script utili

Verifica globale dello stato DFSR su tutti i DC

$dcs = (Get-ADDomainController -Filter *).HostName
$dcs | ForEach-Object {
  Invoke-Command -ComputerName $_ -ScriptBlock {
    "$env:COMPUTERNAME - DFSR: " + (Get-Service dfsr).Status
  } -ErrorAction SilentlyContinue
}

Report rapido sugli SPN del servizio AD FS

$serviceName = "adfssvc$"   # sostituire con l'oggetto gMSA o con il computer account
setspn -L "DOMINIO\$serviceName"
setspn -Q http/somadfs.samra.com.jo
setspn -Q host/somadfs.samra.com.jo

Disabilitazione sicura di FRS

if ((dfsrmig /getmigrationstate) -match "Eliminated") {
  sc config ntfrs start= disabled | Out-Null
  "FRS disabilitato in sicurezza."
} else {
  "Migrazione non completata: non disabilitare FRS."
}

Riepilogo operativo

Errore	Azione rapida	Validazione
Evento 1053 su FRS dopo migrazione	Confermare Eliminated e disabilitare FRS; in legacy correggere credenziali e dipendenze.	DFSR in esecuzione; eventi 4604/4614; condivisioni SYSVOL e NETLOGON accessibili.
Evento 217 con MSIS7207 su AD FS	Impostare identità del servizio su adfssrv o gMSA; registrare SPN `host/` e `http/` sull’oggetto corretto; sanare duplicati.	Evento 100 su AD FS/Admin; endpoint WS‑Trust raggiungibile con autenticazione integrata.

Checklist finale di messa in sicurezza

DFSR attivo e verificato su tutti i controller di dominio.
FRS disabilitato ovunque la migrazione sia completa.
SPN univoci e registrati sul soggetto corretto per AD FS.
Replica AD e DNS senza errori nei riepiloghi di repadmin e dcdiag.
Backup delle chiavi e dei certificati di AD FS aggiornato.

Conclusione

Questi due incidenti, seppure distinti, hanno una radice comune: configurazioni in transizione tra tecnologie legacy e moderne. Rendendo DFSR l’unico meccanismo di replica per SYSVOL e mantenendo AD FS allineato con identità di servizio supportate e SPN coerenti, si ottengono avvii puliti dei servizi, endpoint WS‑Trust disponibili e criteri di gruppo applicati con affidabilità. Applicare il playbook proposto consente di passare rapidamente dalla diagnosi alla correzione, riducendo al minimo i tempi di disservizio e prevenendo ricadute.

Appendice

Servizi e nomi: NTFRS (FRS), DFSR (DFS Replication), adfssrv (AD FS).
Eventi chiave: 1053 (timeout servizio), 135 (FRS avviato), 4604/4614 (DFSR inizializzato/avviato), 217 (AD FS SPN non recuperabile), 100 (AD FS avvio riuscito).
Share e percorsi: \<dc>\SYSVOL, \<dc>\NETLOGON, %systemroot%\NTFRS, %systemroot%\SYSVOL.

Con questi interventi il controller di dominio replica correttamente SYSVOL tramite DFSR e AD FS riapre l’endpoint WS‑Trust senza ulteriori errori.