Migrazione Active Directory e DNS a un nuovo dominio: guida completa step‑by‑step (da example.com a test.com)

Migrazione di Active Directory e DNS a un nuovo dominio (da example.com a test.com): guida pratica e completa per progettare, testare e realizzare il passaggio con downtime minimo, preservando identità, ACL e servizi Kerberos.

Indice

Panoramica e scenari possibili

La necessità: sostituire il dominio example.com con test.com in un ambiente Windows Server. L’obiettivo è migrare Active Directory, DNS e identità senza interrompere l’operatività e senza dover riconfigurare tutte le autorizzazioni.

Gli approcci in sintesi:

Trasferimento inter-foresta con ADMT (consigliato nella maggior parte dei casi): creazione di un nuovo dominio/foresta clean, trust bidirezionale, migrazione graduale di utenti, gruppi, computer e server applicativi. Permette di mantenere la SID History e un rollout per fasi.
Domain Rename con rendom (solo in condizioni restrittive): possibile quando si rinomina un’unica foresta senza carichi dipendenti non supportati (es. versioni moderne di Exchange, Skype for Business/Lync, Azure AD Connect, AD FS complessi, integrazioni terze). Richiede test meticolosi; non è una “banale” operazione di rebranding.
Green‑field puro: si costruisce una nuova foresta, si migrano risorse e servizi, poi si spegne la legacy. È il più sicuro per ambienti molto complessi o con requisiti di continuità elevati, a fronte di un progetto più lungo.

Piano di progetto ad alto livello

Fase	Attività chiave	Scopo / Note operative
Backup completo	• Eseguire System State dei DC (include AD). • Esportare/dump delle zone DNS. • Snapshot dei server virtuali (se applicabile).	Garantire un rollback rapido in caso di problemi.
Preparazione del nuovo dominio	• Aggiungere il ruolo AD DS in `test.com`. • Promuovere almeno 2 DC (siti diversi se possibile). • Configurare DNS integrato in AD.	Crea l’infrastruttura di destinazione robusta e ridondata.
Creazione di trust interdominio	Trust bidirezionale, autenticazione forest-wide, SIDHistory abilitata, quarantine disabilitata.	Permette migrazione graduale mantenendo accessi alle risorse.
Migrazione con ADMT	Installare ADMT + SQL Express; usare PES per la migrazione password; migrare utenti → gruppi → computer.	ADMT 3.2 è datato; leggere note di rilascio e limiti. Pianificare workaround e test.
Test pilota	Campione rappresentativo (utenti, workstation, app). Validare login, risorse, GPO, script, SSO, stampa.	Riduce il rischio di blocchi produttivi.
Aggiornamento DNS	Forwarder/conditional tra namespace; replicare record (A, CNAME, SRV) in `test.com`; pulizia riferimenti legacy.	Assicura risoluzione corretta durante e dopo la migrazione.

Nota di prudenza
ADMT 3.2 è in manutenzione minima. In presenza di ambienti complessi o requisiti di continuità stringenti, l’approccio green‑field (nuova foresta, migrazione graduale) è spesso più sicuro del rename o di migrazioni in‑place.

Prerequisiti tecnici e controlli preliminari

Salute di AD in example.com: replica senza errori, cataloghi globali disponibili, FSMO stabili, SYSVOL su DFSR (se ancora FRS, migrare a DFSR prima).
Livelli funzionali: definire DFL/FFL target. Evitare mix di DC troppo eterogenei.
DNS pulito: niente record obsoleti, scavenging correttamente configurato.
Tempo: NTP coerente (PDC Emulator sorgente e destinazione sincronizzati).
Connettività: porte AD/LDAP/Kerberos/DNS aperte tra domini e siti.
Inventario: contare utenti, gruppi, computer, server, servizi che usano SPN/SSO, stampanti, condivisioni, applicazioni.
Account di servizio: mappare dove sono usati (SQL, IIS, servizi Windows).
Dipendenze cloud: se usi Azure AD Connect/Entra Connect, ADFS o MDM, pianificare attentamente (il rename del dominio non è supportato in molti scenari).

Verifiche rapide

repadmin /replsummary
repadmin /showrepl * /csv &gt; repl.csv
dcdiag /v /c /e /fix
dnscmd /enumzones
w32tm /query /status

Dominio nuovo o rename del dominio?

Opzione	Quando usarla	Pro	Contro
ADMT (cross-forest)	Si vuole migrare in sicurezza, tenendo SIDHistory e facendo fasi con rollback.	Rollout progressivo; minimizza downtime; SIDHistory preserva ACL.	Tool datato; richiede SQL; complessità nello scripting; limiti con feature recenti.
Domain Rename (`rendom`)	Foresta unica, carichi compatibili, assenza di componenti non supportate.	Nessun trust/migrazione oggetti; conserva foresta/OU.	Non supportato con varie integrazioni; rischio elevato; test lunghi e articolati.
Green‑field	Ambienti grandi/complessi o moderni con molte integrazioni.	Massima pulizia, minori sorprese; design moderno.	Progetto più lungo; serve migrare ogni componente.

Procedura dettagliata consigliata (con ADMT)

Backup e recovery

Eseguire un System State backup di ogni DC, più un backup completo dei server DNS/Applicativi. Validare il ripristino in laboratorio.

wbadmin start systemstatebackup -backuptarget:E: -quiet
dnscmd /zoneexport example.com example_com.dns

Creazione del dominio di destinazione `test.com`

# Esempio PowerShell su Windows Server (elevato)
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

Nuova foresta

Install-ADDSForest -DomainName "test.com" -DomainNetbiosName "TEST" `
-InstallDNS -NoRebootOnCompletion:$false

Promuovere almeno due DC in siti diversi, abilitare il Global Catalog su almeno un DC per sito e verificare la replica.

Trust tra `example.com` e `test.com`

Creare un trust bidirezionale, forest-wide, con SIDHistory consentita e SID filtering disattivato durante la migrazione (si potrà riattivare a fine progetto).

# Da uno dei domini (elevato)
netdom trust test.com /domain:example.com /Forest /twoway /Add `
  /UserO:EXAMPLE\Administrator /PasswordO:* `
  /UserD:TEST\Administrator    /PasswordD:*

Disabilita SID filtering temporaneamente

netdom trust test.com /domain:example.com /quarantine:No
netdom trust example.com /domain:test.com /quarantine:No

Prerequisiti ADMT e PES

Server ADMT in test.com con SQL Server Express (db ADMT).
Account di servizio ADMT con privilegi amministrativi su entrambi i domini.
PES (Password Export Server) sul PDC Emulator del source (example.com) per migrare le password.
Su example.com: abilitare audit “Account Management: Success” e impostare i rights per la migrazione SIDHistory.
Firewall aperti tra i due domini (RPC dinamiche, LDAP/LDAPS, Kerberos, SMB).

# Installazione PES (esempio) sul PDC sorgente
PESetup.exe /keyfile:pes.key /keypassword:<PasswordForte>

Sul dominio sorgente (audit)

auditpol /set /category:"Account Management" /success:enable

Sequenza di migrazione con ADMT

UPN Suffix: aggiungere @test.com nelle proprietà della foresta e pianificare il passaggio UPN.
Utenti: migrazione con SIDHistory + password via PES; opzione per aggiornare profili locali/roaming.
Gruppi: migrazione rispettando l’ordine (prima gruppi globali, poi universali, poi locali).
Workstation: migrare per OU o per sito (vedi script di rejoin sotto).
Server applicativi: dopo convalida utenti+PC; migrare account di servizio, SPN, pool IIS, job schedulati.

Esempi di comandi/pipeline utili

# Aggiornare in blocco gli UPN verso @test.com (ESEMPIO: filtrare per OU)
Get-ADUser -SearchBase "OU=Utenti,DC=example,DC=com" -Filter * |
  ForEach-Object {
    $newUpn = "$($_.SamAccountName)@test.com"
    Set-ADUser $_ -UserPrincipalName $newUpn
  }

Verifica canale di protezione delle macchine dopo lo spostamento

Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=test,DC=com" |
ForEach-Object {
Test-ComputerSecureChannel -Server "dc1.test.com" -Credential (Get-Credential)
}

Script di rejoin automatico per workstation

Distribuibile via GPO, RMM o software di gestione (ESEMPIO base, adattare e testare prima del roll-out):

param(
  [string]$NewDomain = "test.com",
  [string]$TargetOU  = "OU=Workstations,OU=ITA,DC=test,DC=com"
)

1. Uscita dal dominio legacy (richiede credenziali dominio sorgente)

$credOld = Get-Credential -Message "Credenziali dominio example.com"
Remove-Computer -UnjoinDomainCredential $credOld -Force -PassThru -Verbose
Restart-Computer -Force

2. Join al nuovo dominio dopo il riavvio (usare Scheduled Task o fase 2 script)

$credNew = Get-Credential -Message "Credenziali dominio test.com"
Add-Computer -DomainName $NewDomain -Credential $credNew -OUPath $TargetOU -PassThru -Verbose
Restart-Computer -Force

Per ridurre l’impatto sul profilo utente locale, valutare l’uso di USMT (User State Migration Tool) o la migrazione dei profili via ADMT quando possibile.

Gestione DNS durante la transizione

Creare le zone test.com integrate in AD, con scope di replica appropriato (ForestDnsZones).
Configurare forwarder o conditional forwarder bidirezionale example.com ⇄ test.com.
Recreare i record SRV per i DC del nuovo dominio (automatico se DNS integrato e DC sani).
Replicare CNAME/A applicativi (file server, web, SQL), creare alias temporanei se serve.
Rimuovere gradualmente i riferimenti legacy (suffissi DNS, ricerca di “example.com” in GPO, script, applicazioni).

# Esempi
dnscmd /zoneadd test.com /dsprimary
dnscmd /recordadd test.com files  A 10.10.10.50
dnscmd /recordadd test.com www    CNAME webapp.test.com

Migrazione GPO e logon script

Le GPO possono contenere riferimenti a UNC/nomi di dominio. Usare migration table per il remapping e l’import.

# Backup GPO dal dominio sorgente
Backup-GPO -All -Path C:\GPO_Backup

Creare una Migration Table (esempio MT.xml) per mappare example.com -> test.com

Import GPO nel dominio di destinazione

Get-GPO -All | ForEach-Object {
Import-GPO -BackupId $.Id -TargetName $.DisplayName -Path C:\GPO_Backup -MigrationTable C:\MT.xml
}

Valutare la sostituzione degli script di logon con Group Policy Preferences (drive mapping, stampanti, file INI/Registry) per maggiore resilienza.

Service Accounts, SPN e Kerberos

Inventariare i servizi che girano con identità di dominio (EXAMPLE\svc-*).
Migrare gli account (ADMT) e riassociare i servizi.
Ricreare gli SPN nel nuovo dominio ed eliminare duplicati.

# Ricerca rapida su un server:
Get-CimInstance Win32Service | Where-Object {$.StartName -match "EXAMPLE\\"} |
  Select-Object Name, StartName, State

SPN

setspn -Q */server01
setspn -X  # Trova duplicati

Applicazioni e SSO

Elencare applicazioni che delegano a Kerberos/NTLM o hanno binding LDAP (IIS, Tomcat, SQL, SharePoint, app verticali). Adeguare connection string, SPN e provider di autenticazione. Verificare con klist e log di sicurezza gli eventuali ticket falliti.

Cut‑over e pulizia finale

Concludere migrazione utenti/gruppi/workstation/server; confermare accessi e profili.
Passare UPN primario a @test.com per tutti gli utenti (mantenere alias/suffisso secondario per un periodo).
Aggiornare certificati (Wi‑Fi 802.1X, VPN, RADIUS), profili Outlook/OneDrive, stampanti, connessioni mappate.
Rimuovere trust e dismettere i DC legacy: demote ordinato, aggiornare i metadata, rimuovere le zone DNS example.com quando non più necessarie.

# Demote DC legacy (da eseguire sull'ultimo DC del dominio sorgente)
Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartitions -ForceRemoval

Strategia di test e qualità

Pilota

10–15% degli utenti rappresentativi (ruoli diversi, sedi diverse).
Workstation di modelli diversi, con e senza VPN, e almeno un server per categoria (file, web, DB).
Check di: login online/offline, condivisioni, stampanti, applicazioni, GPO (drive, proxy, firewall), client di posta, SSO verso app interne.

Metriche di successo

Fallimenti di logon < 1% nel pilota; 0 incidenti Critical in produzione nei primi 7 giorni.
Nessun evento 4013 DNS/2213 DFSR su DC.
Replica AD senza backlog sostanziale (monitorata con repadmin).

Monitoraggio e troubleshooting

# Replica AD
repadmin /replsummary
repadmin /showrepl * /csv > repl.csv

DC health

dcdiag /v /c /e /fix

DNS logging (server DNS)

Get-WinEvent -LogName "DNS Server" | Select-Object TimeCreated, Id, Message -First 50

Kerberos

klist purge
klist get host/dc1.test.com

Canale sicuro su client

Test-ComputerSecureChannel -Verbose
nltest /sc_verify:test.com

Informazioni supplementari utili

Argomento	Nota rapida
Domain Rename (`rendom`)	Utilizzabile solo con una foresta unica e carichi pienamente compatibili; evitare se presenti Exchange moderni, Skype for Business/Lync, Azure AD Connect, AD FS e PKI complesse.
Script di rejoin	Per le workstation si possono distribuire script PowerShell per staccare/riunire i PC al nuovo dominio senza intervento manuale.
Sequenza consigliata	1) Utenti e gruppi → 2) Workstation → 3) Server applicativi → 4) Servizi con SPN/Kerberos.
Pulizia finale	Dopo il cut‑over: rimuovere il trust, decommissionare i vecchi DC, aggiornare certificati, share, GPO legacy.

Rischi comuni e mitigazioni

Duplicati SPN → usare setspn -X e correggere prima del cut‑over.
FRS ancora attivo → migrare a DFSR su SYSVOL prima di tutto.
SIDHistory non popolata → verificare trust, SID filtering, audit e privilegi degli account ADMT/PES.
Profili utente “nuovi” post‑join → usare ADMT/USMT, o associare i profili via registro (operazione delicata).
App vincolate a LDAP semplice → aggiornare binding e base DN, validare con ldp.exe.
VPN/802.1X → aggiornare realm e certificati prima del cut‑over.

Checklists operative

Pre‑migrazione

Backup System State DC + esportazione zone DNS.
Replica AD ok; SYSVOL via DFSR; NTP corretto.
Nuovo dominio test.com: 2+ DC GC, DNS integrato.
Trust forest-wide bidirezionale; SID filtering disattivato temporaneamente.
Server ADMT + SQL Express; PES su PDC sorgente; account ADMT con privilegi; audit abilitato.
Inventario SPN, account servizio, GPO, share, stampanti, applicazioni.
Migration Table per GPO pronta; script di rejoin testati.

Durante la migrazione

Migrare UPN/utenti (con password), poi gruppi, poi workstation.
Importare GPO con migration table; convalidare su OU pilota.
Migrare server applicativi per ondate controllate; ricreare SPN.
Tenere abilitati log DNS, sicurezza e Kerberos; monitor repadmin e dcdiag.

Post‑migrazione

Passaggio UPN primario a @test.com per tutti; mantenere alias per transizione.
Pulizia DNS e riferimenti example.com (GPO/script/app).
Demote DC legacy, rimuovere trust, aggiornare documentazione e runbook.
Audit accessi; rimuovere SIDHistory quando certo che le ACL sono state riallineate (opzionale).

Comunicazione e change management

Notifiche agli utenti con date/ore, cosa cambia (UPN, login), impatti (Outlook/OneDrive), contatti supporto.
Manuali aggiornati per Wi‑Fi, VPN, posta, condivisioni.
Piano di supporto H+48 con war room, canali dedicati, dashboard incident.

Domande frequenti

Quanto downtime serve? Con ADMT, il downtime per utente/PC è tipicamente limitato ai riavvii di join e al refresh dei profili. I server applicativi vanno programmati per finestre ridotte (blue/green o rolling).

Gli ACL sui file server rimangono validi? Sì, grazie alla SIDHistory gli accessi continuano a funzionare senza riassegnare permessi. Verificare comunque le ACL “speciali” e i servizi che fanno enumerazioni per nome dominio.

Cosa succede ai profili Windows? Se il SID cambia, Windows crea un nuovo profilo. ADMT/USMT o i tool di profilo possono mantenere dati e impostazioni. Pianificare per i casi speciali (PC condivisi, VDI).

Posso rinominare direttamente il dominio? Solo in scenari compatibili e dopo test rigorosi. La presenza di Exchange moderni, Azure AD Connect e altre integrazioni spesso rende il rename impraticabile.

Esempi di mapping e tabelle di migrazione

Elemento	Valore legacy	Valore target	Note
UPN	utente@example.com	utente@test.com	Mantenere alias UPN secondario temporaneo.
NetBIOS	EXAMPLE	TEST	Verificare script che usano `EXAMPLE\user`.
DFS Namespace	\\example.com\dfs\…	\\test.com\dfs\…	Aggiornare i target e le GPO di mappatura.
File server	\\files.example.com\share	\\files.test.com\share	Usare CNAME temporanei per ridurre impatti.

Verifica finale prima del go‑live

Tutti i DC in test.com sono GC e replicano correttamente.
DNS risolve nomi di entrambi i namespace; niente record obsoleti critici.
Utenti del pilota si autenticano con @test.com; profili e SSO funzionano.
GPO applicate correttamente; logon script sostituiti o aggiornati.
App critiche (file/DB/web) testate con account di servizio migrati e SPN aggiornati.

Piano di rollback

Mantenere il trust e i DC legacy fino al completamento del progetto.
Se emergono problemi gravi: rejoin temporaneo del gruppo interessato a example.com (script inverso), ripristino DNS e GPO legacy dal backup.
Eseguire root cause analysis, fix e riprovare sul pilota prima di estendere.

Raccomandazioni pratiche finali

Documentazione ufficiale: studiare attentamente le guide ADMT e Domain Rename per scegliere l’approccio migliore e conoscere i limiti (Exchange, Azure AD Connect, ecc.).
Ambiente di test: replicare la foresta in un laboratorio virtuale e simulare end‑to‑end (incluso PES, SPN, GPO e applicazioni).
Comunicazione utenti: pianificare finestre, aggiornare manuali, prevedere assistenza per Outlook/OneDrive/Wi‑Fi.
Monitoraggio post‑migrazione: usare repadmin /replsummary, dcdiag, log DNS e dashboard per garantire stabilità.

Modelli operativi e comandi utili (pronti all’uso)

Ricerca riferimenti legacy nei GPP

# Individua impostazioni GPP che contengono "example.com"
Get-GPO -All | ForEach-Object {
  $report = Get-GPOReport -Guid $_.Id -ReportType Xml
  if ($report -match "example.com") {
    Write-Output "Riferimento legacy in: $($_.DisplayName)"
  }
}

Ricerca share con permessi basati su dominio legacy

# Controlla ACL per SID/nomi EXAMPLE su file server
Get-ChildItem -Recurse \\fileserver\share | ForEach-Object {
  try {
    $acl = Get-Acl $_.FullName
    $acl.Access | Where-Object { $.IdentityReference -match "EXAMPLE\\" -or $.IdentityReference -match "S-1-5-21-" } |
      Select-Object @{n="Path";e={$_.Path}}, IdentityReference, FileSystemRights
  } catch {}
}

Validazione Kerberos post‑migrazione

klist purge
klist
Accesso a risorsa
dir \\files.test.com\share
Verifica ticket
klist

Conclusioni

Seguendo un percorso strutturato – nuovo dominio test.com, trust bidirezionale, ADMT per oggetti e password, migrazione per fasi, DNS coerente, cura per GPO/SPN e un robusto pilota – la transizione da example.com a test.com può avvenire con downtime minimo e senza perdita di identità o accesso alle risorse. Una migrazione AD ben riuscita non è un insieme di wizard, ma un progetto: inventario, pianificazione, test, automazione, comunicazione e monitoraggio fanno la differenza tra un cambio di dominio fluido e una crisi operativa.

Vantaggi e svantaggi dell’approccio con ADMT

Pro: mantiene SID History (evita di riconfigurare ACL), consente rollout progressivo, riduce downtime.
Contro: tool datato, richiede SQL Server, complesso da scriptare, non supporta oggetti FRS legacy o funzionalità introdotte dopo Windows Server 2016.

Nota: gli esempi proposti (comandi, script) sono schemi operativi; vanno adattati all’ambiente e testati in laboratorio.