Riprendiamo l’articolo pubblicato precedentemente 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 fineriavviare 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 inFigura 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 sezioneVerifica 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 valoreSysVol impostato a [drive:\]Windows_folder\SYSVOL\sysvol e che contenga il valore SysvolReadyimpostato 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:

· Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style

· 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.

Corso SQL Server - Corso Hyper-V -Corso Windows Server – Corso asp.net

 Certificazione Microsoft

Migrazione Domain Controller Windows Server 2003 a Windows Server 2012 – Parte 1

Con l’uscita di Windows Server 2012 molte infrastrutture prenderanno la decisione di aggiornare i propri Domain Controller per poter trarre vantaggio dalle numerose funzionalità che sono state introdotte rispetto a Windows Server 2003 che rappresenta la versione di sistema operativo più datata da cui è ancora possibile eseguire la migrazione.

In questo articolo verranno analizzate le problematiche relative all’aggiornamento di un’infrastruttura Active Directory basata su Domain Controller Windows Server 2003 affinché si possano introdurre Domain Controller Windows Server 2012.

In particolare si analizzerà nel dettaglio lo scenario in cui si desidera dismettere un Domain Controller Windows Server 2003 rimuovendolo completamente dall’infrastruttura Active Directory per sostituirlo con un Domain Controller Windows Server 2012.

Data la complessità dell'argomento si è scelto di dividerlo in più articoli. Ecco la prima parte!

Novità in Active Directory

Rispetto a Windows Server 2003, nelle successive versioni di sistemi operativi, sono state introdotte diverse novità, anche in ambito Active Directory . Le sintetizzo nella seguente tabella.

Sistema operativo	Funzionalità	Requisiti
Windows Server 2008	· Supporto per la replica del SYSVOL (System Volume) tramite DFS (Distributed File System) che garantisce una replica più robusta e dettagliata · Supporto per Advanced Encryption Standard (AES 128 e AES 256) per il protocollo Kerberos · Informazioni sull’ultimo logon interattivo · Fine-grained password policies · Personal Virtual Desktops	Livello funzionale di dominio Windows Server 2008
Windows Server 2008 R2	· Memorizzazione nel token kerberos utente delle informazioni circa il tipo di autenticazione. · Supporto ai Managed Service Accounts	Livello funzionale di dominio Windows Server 2008
Windows Server 2008 R2	· Active Directory Recycle Bin	Livello funzionale di foresta Windows Server 2008
Windows Server 2012	· Kerberos armoring · Supporto da parte del KDC claim e compound authentication	Livello funzionale di dominio Windows Server 2012

Per ulteriori informazioni circa le novità in Active Directory legate ai nuovi livelli funzionali si vedaUnderstanding Active Directory Domain Services (AD DS) Functional Levels.
Vi sono inoltre anche una serie di novità riguardanti la gestione di Active Directory, quindi non correlate alle modifiche apportate al Directory Service, che sono state introdotte nelle versioni del sistema operativo successive a Windows Server 2003.

Funzionalità introdotte in Windows Server 2008

· Active Directory Domain Services auditing mediante l’introduzione della sottocategoria di policies di audit Directory Service Changes · Read-Only Domain Controllers · Restartable Active Directory Domain Services che consente di eseguire tasks come offline defragmentation, aggiornamenti del Domain Controller senza riavviare il sistema · Database Mounting Tool (Dsamain.exe) che consente di migliorare il processo di recovery visualizzando e confrontando i dati presenti in backup eseguiti in tempi diversi in modo da decidere quale ripristinare · Gestione degli Owner Rights · Nuovo formato ADMX e nuove funzionalità per gli Administrative template files · Starter Group Policy objects · Commenti per GPOs e policy settings · Network Location Awareness · Group Policy Preferences Corso SQL Server - Corso Hyper-V -Corso Windows Server – Corso asp.net  Certificazione Microsoft