Migrazione Domain Controller Windows Server 2003 a Windows Server 2012 – Parte 2
Riprendiamo l’articolo pubblicato precedentemente a nome di Mario Serra e Ermanno Goletta(Migrazione Domain Controller Windows Server 2003 a Windows Server 2012 – Parte 1) continuando nella guida che ci aiuta a migrare Domain Controller da Windows Server 2003 a Windows Server 2012.
Rimozione del Domain Controller Windows Server 2003
Prima di iniziare la procedura di dismissione del Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) occorre impostare i client in modo che non lo utilizzino più come server DNS e utilizzino invece il nuovo server Windows Server 2012 (VMDC2012 nell’esempio). Questa impostazione generalmente viene distribuita tramite DHCP di conseguenza per evitare problemi ai client durante e dopo la rimozione del Domain Controller Windows Server 2003 sarebbe opportuno attendere che la configurazione sia distribuita col rinnovo del lease DCHP.
Di seguito analizzeremo i passi necessari per eseguire il demote di un Domain Controller Windows Server 2003, per maggiori informazioni si veda Decommissioning a Domain Controller.
Configurazione delle impostazioni di rete per il Domain Controller Windows Server 2012
Dopo aver verificato la funzionalità di Active Directory col nuovo Domain Controller e aver controllato che la replica tra i due Domain Controller è avvenuta correttamente è possibile configurare il Domain Controller Windows Server 2012 affinché usi se stesso come primo server DNS tramite l’indirizzo IP 127.0.0.1 oppure tramite l’indirizzo IP assegnato (10.10.0.12 nell’esempio).
Spostamento dei ruoli Flexible Single Master Operations sul Domain Controller Windows Server 2012
Dal momento che il Domain Controller Windows Server 2012 dovrà sostituire il Domain Controller Windows Server 2003 è necessario spostare su di esso i ruoli FSMO (Flexible Single Master Operations) elencati nella seguente tabella:
| Ruolo FSMO | Scope | Diritti necessari per lo spostamento |
| SchemaMaster | Foresta | Schema Admins |
| Domain Naming Master | Foresta | Enterprise Admins |
| RID Master | Domino | Domain Admins |
| PDC Emulator | Domino | Domain Admins |
| Infrastructure Master | Domino | Domain Admins |
E possibile eseguire lo sposamento dei ruoli FSMO tramite PowerShell direttamente dal Domain Controller Windows Server 2012. Di seguito il comando PowerShell per trasferire tutti i ruoli FSMO sul Domain Controller Windows Server 2012 (VMDC2012 nell’esempio):
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole SchemaMaster, DomainNamingMaster, RIDMaster,InfrastructureMaster,PDCEmulator
In alternativa è anche possibile spostare i ruoli uno alla volta:
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole SchemaMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole DomainNamingMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole InfrastructureMaster
Move-ADDirectoryServerOperationMasterRole -Identity "VMDC2012" -OperationMasterRole PDCEmulator 
Per verificare che lo sposamento dei ruoli FSMO sia avvenuto correttamente è possibile controllare che il seguente evento sia stato registrato 5 volte (uno per ogni ruoli FSMO trasferito):
· Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 1458
Inoltre sempre tramite PowerShell, come visto precedentemente, è possibile controllare che i ruoli FSMO risultino assegnati ad Domain Controller Windows Server 2012 (VMDC2012 nell’esempio)
Get-ADForest | Select SchemaMaster, DomainNamingMaster
Get-ADDomain | Select RIDMaster, PDCEmulator, InfrastructureMaster 
Rimozione del ruolo di Global Catalog dal Domain Controller Windows Server 2003
Prima di iniziare la procedura di demote del Domain Controller Windows Server 2003 oltre a rimuovere i ruoli FSMO detenuti occorre rimuovere anche il ruolo di Global Catalog come indicato in Demote a domain controller.
Per rimuovere il ruolo di Global Catalog è possibile utilizzare il tool Siti e servizi di Active Directory.
Per verificare che la rimozione del ruolo Global Catalog sia avvenuta correttamente è possibile controllare che sul Domain Controller Windows Server 2003 sia stati registrati i seguenti eventi:
· Domain Controller Windows Server 2003
Registro Servizio Directory - Evento d’informazioni NTDS General 1120
· Domain Controller Windows Server 2012
Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 1869
Inoltre occorre verificare che il record DNS SRV _gc relativo al Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) sia stato rimosso e che sia presente solamente quello relativo al Domain Controller Windows Server 2012 (VMDC2012 nell’esempio), per maggiori informazioni si veda Verify Global Catalog DNS Registrations:
Dopo aver rimosso il ruolo di Global Catalog e aver verificato che l’operazione è andata a buon fine riavviare il Domain Controller Windows Server 2003.
Configurazione delle impostazioni di rete per il Domain Controller Windows Server 2003
Per evitare problemi di risoluzione DNS durante il demote del Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) occorre configurare il Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) affinché usi il Domain Controller Windows Server 2012 (VMDC2012 con IP 10.10.0.12 nell’esempio) come primo server DNS.
Dopo aver modificato le impostazioni di rete riavviare il server.
Rimozione del server DNS dal Domain Controller Windows Server 2003
Dal momento che il servizio DNS sul Domain Controller Windows Server 2003 (VMDC2003 nell’esempio), non è più di fatto utilizzato all’interno dell’infrastruttura è possibile rimuoverlo tramite Amministrazione Server.
Demote del Domain Controller Windows Server 2003
Avviare il demote eseguendo sul Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) Dcpromo senza specificare che questo è l’ultimo server Domain Controller del dominio, al termine riavviare il server come richiesto.
Nel caso si verifichi l’errore di time out durante l’arresto del servizio NETLOGON come mostrato in Figura 5, molto probabilmente il Domain Controller Windows Server 2003 non è stato riavviato dopo aver rimosso il ruolo di Global Catalog o non è stato impostato il Domain Controller Windows Server 2012 (VMDC2012 con IP 10.10.0.12 nell’esempio) come server DNS primario. In alternativa potrebbero esserci sul server dei servizi dipendenti da Active Directory che vanno arrestati prima di eseguire il demote. Dopo avere provveduto a risolvere la causa del time out riavviare la procedura di Demote, per maggiori informazioni si veda la KB555078 Netlogon service time out error message while promote domain controller.
Eliminazione dell’oggetto server relativo al Domain Controller Windows Server 2003 dal Sito
Terminata la procedura di demote occorre rimuovere manualmente l’oggetto server relativo al Domain Controller Windows Server 2003 tramite il tool Siti e servizi di Active Directory.
Rimozione e correzione dei record DNS relativi al Domain Controller Windows Server 2003
Il demote del Domain Controller Windows Server 2003 dovrebbe già rimuovere gran parte dei record DNS, ma occorre eseguire alcune operazioni manualmente per quanto riguarda i record NS nel dominio e nel sottodomino _msdcs.
Il sottodominio _msdcs è riservato alla registrazione dei record DNS dei servizi di rete inerenti ai servizi di directory specifici di Microsoft, Active Directory infatti non è altro che l’implementazione Microsoft dei servizi di directory. I client il dominio che interrogano il dominio _msdcs , ad esempio, per un record DNS SRV relativo al servizio LDAP otterranno un record per un server LDAP Microsoft (Domain Controller). Le query verranno eseguite nel formato _Service._Protocol.DcType. _msdcs. DnsDomainName dove DcType sarà il GUID del dominio, _Service l’identificativo del servizio (_ldap per LDAP) e _Protocol l’identificativo del protocollo di rete (_tcp per TCP).
La prima operazione manuale consiste nel rimuovere il Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) dall’elenco dei Server dei nomi per la zona di ricerca diretta del dominio (sysadmin.lan nell’esempio).
La seconda operazione manuale consiste nel rimuovere il riferimento al Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) dal sottodominio dominio delegato _msdcs sostituendolo con il Domain Controller Windows Server 2012 (VMDC2012 nell’esempio).
La terza operazione manuale consiste nel rimuovere il riferimento al Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) dal sottodominio _msdcs sostituendolo con il Domain Controller Windows Server 2012 (VMDC2012 nell’esempio)
Controllare che non esistano altri record DNS che puntino ancora al Domain Controller Windows Server 2003 ad esclusione del record A nella zona del domino (sysadmin.lan nell’esempio) dal momento che tale server è membro del dominio.
Nel caso fossero ancora presenti altri record è possibile eliminarli manualmente o usare il tool a riga Nltest per eliminare i record DNS che un Domain Controller registra:
nltest /dsderegdns:vmdc2003.sysadmin.lan
Terminata la pulizia dei record DNS riavviare il Domain Controller Windows Server 2012.
Verifica della funzionalità di Active Directory
Terminata la dismissione del Domain Controller Windows Server 2003 (VMDC2003 nell’esempio) è opportuno procedere alla verifica del funzionamento di Active Directory dopo aver arestato il Domain Controller dismesso eseguendo i seguenti controlli descritti nella sezione Verifica della promozione del Domain Controller:
· Verifica dell’esistenza delle share NETLOGON e SYSVOL
· Verifica del servizio DNS
· Verifica della replica
· Verifica dei ruoli Flexible Single Master Operations
Come ultimo controllo rieseguire il best practices analyzer che dovrebbe elencare un nuovo avviso relativo all’opportunità di installare un secondo Domain Controller per garantire la ridondanza e l’errore che occorre impostare il Domain Controller Windows Server 2012 (VMDC2012 nell’esempio) per sincronizzare l’ora con una fonte valida dal momento che esegue il ruolo di PDC Emulator (a riguardo si veda AD DS: The PDC emulator master in this forest should be configured to correctly synchronize time from a valid time source).
Rimozione del server Windows Server 2003
Il server Windows Server 2003 (VMDC2003 nell’esempio) può essere rimosso dal dominio arrestato e poi dismesso, quindi è possibile eliminare l’account computer relativo e il record DNS A.
Successivamente è possibile valutare se può essere conveniente attribuire al Domain Controller Windows Server 2012 (VMDC2012 nell’esempio) l’indirizzo IP che aveva il Domain Controller Windows Server 2003 (VMDC2003 con IP 10.10.0.11 nell’esempio). Questa modifica può essere conveniente se nell’infrastruttura vi sono un numero consistente di client, server o host che si riferiscono all’IP del Domain Controller dismesso tramite impostazioni statiche, ad esempio per risolvere le query DNS per gli host del dominio o, nel caso di host non in domino, come NTP server.
Migrazione della replica SYSVOL da FRS a DFS
I Domain Controller utilizzano la directory condivisa SYSVOL per replicare tra loro gli script di logon e i file delle Group Policy. In Windows Server 2000 e Windows Server 2003 la replica della directory SYSVOL avviene tramite File Replication Service (FRS). A partire da Windows Server 2008 viene utilizzata invece la replica DFS se il livello funzionale del domino è Windows Server 2008, in caso contrario si continua ad utilizzare FRS.
Questo significa che nell’infrastruttura di esempio dal momento che il livello funzionale è Windows Server 2003 la replica della directory SYSVOL avviene tramite FRS e non tramite la nuova replica DFS che ha i seguenti vantaggi:
· Maggior efficienza.
· Maggior scalabilità.
· Utilizza l’algoritmo Remote Differential Compression (RDC) che riduce l’utilizzo della banda di rete.
· Ha un meccanismo di auto ripristino da eventuali corruzioni.
In scenari come quello dell’esempio risulta quindi necessario eseguire manualmente la migrazione dalla replica FRS alla replica DFS, sino a che la migrazione non è terminata non devono essere apportate modifiche a script di logon e Group Policy, per maggiori informazioni si veda SYSVOL Replication Migration Guide: FRS to DFS Replication e i seguenti post dello Storage Team:
· SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process
· SYSVOL Migration Series: Part 2 - Dfsrmig.exe: The SYSVOL migration tool
· SYSVOL Migration Series: Part 3 - Migrating to the Prepared State
· SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state
· SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state
Per le novità introdotte nella replica DFS in Windows Server 2012 si veda DFS Replication Improvements in Windows Server 2012.
Primo step: Verifica della funzionalità della replica FRS
Per verificare che la replica FRS funzioni correttamente è possibile eseguire i seguenti controlli:
1. Verificare l’esistenza e funzionalità delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante i comandi:
a. net share
b. dcdiag /test:frssysvol
c. dcdiag /test:netlogons
2. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2012) che il disco su cui risiede la share SYSVOL abbia lo spazio disponibile per crearne una copia.
3. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style)
4. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2012) che la replica Active Directory funzioni correttamente tramite il comando repadmin /ReplSum.
5. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2012) che la chiave di registro HKLM\System\CurrentControlSet\Services\Netlogon\Parameters contenga il valore SysVol impostato a [drive:\]Windows_folder\SYSVOL\sysvol e che contenga il valore SysvolReady impostato a 1.
6. Controllare che su ogni Domain Controller (nell’esempio esiste solo VMDC2012) il servizio Replica DFS (DFSR) sia avviato e impostato per l’avvio automatico.
Secondo step: Aumento del livello funzionale del dominio
Per poter utilizzare la replica DFS occorre aumentare il livello funzionale portandolo almeno a Windows Server 2008, ma se si suppone di inserire nell’infrastruttura sol Domain Controller Windows Server 2012 o superiori conviene portare a Windows Server 2012 il livello funzionale della foresta per beneficiare di tutte le novità introdotte.
E’ possibile elevare il livello funzionale del dominio e della foresta tramite il tool i Servizi di dominio di Active Directory come visto precedentemente oppure usare i seguenti comandi PowerShell:
#Raise livello funzionale del dominio a Windows 2012
Set-ADDomainMode -Identity sysadmin.lan -DomainMode Windows20012
#Verifica livello funzionale del dominio corrente
(Get-ADDomain).DomainMode
#Raise livello funzionale della foresta a Windows 2012
Set-ADForestMode -Identity sysadmin.lan -ForestMode Windows2012
#Verifica del livello funzionale della foresta corrente
(Get-ADForest).ForestMode
Per verificare che l’aumento del livello funzionale di dominio sia avvenuto correttamente è possibile controllare che sia stato registrato il seguente evento:
· Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 2039
Per verificare che l’aumento del livello funzionale della foresta sia avvenuto correttamente è possibile controllare che sia stato registrato il seguente evento:
· Registro Directory Services - Evento d’informazioni ActiveDirectory_DomainService 2040
Terzo step: Migrazione del dominio nello stato Prepared
Prima di eseguire la migrazione del dominio nello stato Prepared eseguire un backup del system state dei Domain Controller nell’infrastruttura (nell’esempio esiste solo VMDC2012) eseguendo su ciascun Domain Controller il comando:
Wbadmin start systemstatebackup
Terminato il backup dei system state dei Domain Controller nell’infrastruttura, che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi, è possibile impostare il global migration state a Prepared eseguendo da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:
dfsrmig /setglobalstate 1
Per verificare che il global migration state è stato impostato a Prepared è possibile utilizzare il seguente comando:
dfsrmig /getglobalstate
Per verificare che tutti i Domain Controller abbiano raggiunto lo stato Prepared è possibile utilizzare il seguente comando:
dfsrmig /getmigrationstate 
Se il global migration state è stato impostato a Prepared viene registrato il seguente evento:
· Registro Replica DFS - Evento d’informazioni DFSR 8014
Prima di continuare la migrazione della replica SYSVOL da FRS a DFS eseguire i seguenti controlli:
1. Verificare l’esistenza e funzionalità delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante i comandi:
a. net share
b. dcdiag /test:frssysvol
c. dcdiag /test:netlogons
2. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style).
3. Verificare che su ogni Domain Controller (nell’esempio esiste solo VMDC2012) sia stata la directory %SystemRoot%\SYSVOL_DFSR e che il contenuto delle directory domain e sysvol in %WinDir%\SYSVOL sia stato copiato in %WinDir%\SYSVOL_DFSR.
4. Usare il tool Gestione DFS per creare un report diagnostico per la directory SYSVOL_DFSR, è possibile installare lo snap-in aggiungendo la funzionalità Strumenti di amministrazione remota del server – Strumenti di amministrazione ruoli – Strumenti per servizi file – Strumenti di gestione DFS.
a. Selezionare il nodo Replica – Domain System Volume
b. Verificare nel Tab Appartenze che per tutti i Domain Controller sia abilitata la replica per il path %SystemRoot%\SYSVOL_DFSR\domain.
c. Selezionare Azioni – Crea rapporto di diagnostica.
d. Creare un Rapporto di stato, un Test di propagazione e un Rapporto di propagazione e verificare che non vi siano errori
Quarto step: Migrazione del dominio nello stato Redirect
Per impostare il global migration state a Redirect eseguire da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:
dfsrmig /setglobalstate 2
Per verificare che il global migration state è stato impostato a Redirect è possibile utilizzare il seguente comando:
dfsrmig /getglobalstate
Per verificare che tutti i Domain Controller hanno raggiunto lo stato Redirect è possibile utilizzare il seguente comando:
dfsrmig /getmigrationstate 
Se il global migration state è stato impostato a Redirect viene registrato il seguente evento:
· Registro Replica DFS - Evento d’informazioni DFSR 8017
Prima di continuare la migrazione della replica SYSVOL da FRS a DFS eseguire i seguenti controlli:
1. Verificare l’esistenza delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante il comando net share e verificare che ora le share mappino rispettivamente le directory:
a. %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS
(nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\sysadmin.lan\SCRIPTS)
b. %SystemRoot%\SYSVOL_DFSR\sysvol
2. Usare il tool Gestione DFS per creare un report diagnostico per la directory SYSVOL_DFSR, come descritto nel secondo step.
3. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style). La replica FRS deve continuare ad essere funzionante per garantire la possibilità di un eventuale roll back.
Quinto step: Migrazione del dominio nello stato Eliminated
Prima di eseguire la migrazione del dominio nello stato Prepared eseguire le seguenti operazioni:
1. Verificare che le repliche funzionino correttamente tramite il comando repadmin /ReplSum (controllare che non siano riportati errori)
2. Eseguire un backup del system state dei Domain Controller nell’infrastruttura (nell’esempio esiste solo VMDC2012) che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi eseguendo su ciascun Domain Controller il comando Wbadmin start systemstatebackup.
Per impostare il global migration state a Eliminated eseguire da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:
dfsrmig /setglobalstate 3
Per verificare che il global migration state è stato impostato a Eliminated è possibile utilizzare il seguente comando:
dfsrmig /getglobalstate
Per verificare che tutti i Domain Controller hanno raggiunto lo stato Eliminated è possibile utilizzare il seguente comando:
dfsrmig /getmigrationstate 
Se il global migration state è stato impostato a Redirect viene registrato il seguente evento:
· Registro Replica DFS - Evento d’informazioni DFSR 8019
Terminata la migrazione della replica SYSVOL da FRS a DFS eseguire i seguenti controlli:
1. Verificare l’esistenza delle share NETLOGON e SYSVOL su ogni Domain Controller (nell’esempio esiste solo VMDC2012) mediante il comando net share e verificare che ora le share mappino rispettivamente le directory:
a. %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS
(nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\sysadmin.lan\SCRIPTS)
b. %SystemRoot%\SYSVOL_DFSR\sysvol
2. Usare il il tool Gestione DFS per creare un report diagnostico per la directory SYSVOL_DFSR, come descritto nello step due.
3. Verificare che su ogni Domain Controller (nell’esempio esiste solo VMDC2012) sia stata rimossa la directory % SystemRoot%\SYSVOL
4. Arrestare e disabilitare il servizio FRS su tutti Domain Controller (nell’esempio esiste solo VMDC2012) tranne nel caso in cui l’FRS venisse utilizzato per repliche diverse dalla directory SYSVOL. E’ possibile eseguire tale configurazione tramite i comandi:
a. sc stop ntfrs
b. sc config ntfrs start=disabled
Per ulteriori informazioni sulla procedura di migrazione si vedano i post sul blog del team di Directory Services:
· The Case for Migrating SYSVOL to DFSR
Conclusioni
In Windows Server 2012 il processo d’installazione di un Domain Controller si è semplificato molto e può anche essere eseguito remotamente grazie alla nuova console Server Manager. Inoltre il modulo PowerShell per Active Directory consente agli amministratori di eseguire attività di configurazione e verifica in modo estremamente automatizzabile.