Virtualizzazione dei controller di dominio con Hyper-V

Si applica a: Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Windows Server 2012 e versioni successive supportano i controller di dominio virtualizzati con misure di sicurezza per impedire il rollback del numero di sequenza di aggiornamento (USN) nei controller di dominio virtuali e la possibilità di clonare controller di dominio virtuali. La virtualizzazione consolida i diversi ruoli del server in un singolo computer fisico. Per altre informazioni, vedere virtualizzazione sicura di Active Directory Domain Services (AD DS).

Queste linee guida descrivono come eseguire controller di dominio come sistemi operativi guest a 32 o a 64 bit.

Pianificazione della virtualizzazione

Le sezioni seguenti contengono considerazioni sulla pianificazione, da tenere presenti durante la virtualizzazione di un controller di dominio, inclusi i requisiti hardware, l'architettura, la configurazione e la gestione della sicurezza e delle prestazioni.

Requisiti di Hyper-V

Per installare e usare il ruolo Hyper-V, l'hardware deve soddisfare i requisiti seguenti:

• È necessario disporre di un processore x64.

• Il processore deve consentire di abilitare la funzionalità di virtualizzazione assistita dall'hardware.

  • In genere, questa impostazione è nota come Intel Virtualization Technology (Intel VT) o Advanced Micro Devices Virtualization (AMD-V).

• Il processore deve supportare la protezione dell'esecuzione dei dati hardware (DEP).

  • È possibile usare Hyper-V solo quando si abilita il bit Intel execute disable (XD) o amd no execute (NX).

Evitare punti di guasto singoli

Quando si pianifica la distribuzione del controller di dominio virtuale, è necessario preparare una strategia per evitare di creare singoli punti di errore. È possibile evitare di introdurre potenziali singoli punti di errore o aree in cui il tempo di inattività può causare l'arresto dell'intero sistema, implementando la ridondanza del sistema.

I consigli seguenti consentono di evitare singoli punti di errore. Tuttavia, è anche importante ricordare che, seguendo queste raccomandazioni, è possibile aumentare i costi di amministrazione.

• Eseguire almeno due controller di dominio virtualizzati per dominio in host di virtualizzazione diversi. Questa configurazione riduce il rischio di perdere tutti i controller di dominio se un singolo host di virtualizzazione smette di funzionare.

• Diversificare l'hardware che esegue i controller di dominio. Ad esempio, usare CPU, schede madre, schede di rete diverse e così via. Hardware diversificato impedisce danni da malfunzionamenti hardware e dispositivo o configurazione fornitore.

• Se possibile, eseguire controller di dominio su hardware che si trovano in diverse aree. Questo approccio riduce le conseguenze delle emergenze che interessano uno dei siti che ospitano i controller di dominio.

• Aggiungere controller di dominio fisici a tutti i domini. La configurazione del sistema in modo che i controller di dominio fisici impediscano ai sistemi host di riscontrare malfunzionamenti della piattaforma di virtualizzazione.

Considerazioni sulla sicurezza

È necessario gestire il computer host in cui vengono eseguiti controller di dominio virtuali con attenzione come controller di dominio scrivibile, anche se il computer è solo un computer aggiunto a un dominio o a un gruppo di lavoro. Questo requisito è per motivi di sicurezza. Gli host gestiti in modo errato sono vulnerabili agli attacchi di elevazione dei privilegi, in cui gli utenti malintenzionati ottengono l'accesso a privilegi più elevati rispetto al previsto in quanto l'amministratore ha assegnato il livello di autorizzazione errato a un'assegnazione di ruolo di livello inferiore. Questi attacchi possono compromettere tutte le macchine virtuali (VM), domini e foreste ospitati dal computer interessato.

Quando si pianifica di virtualizzare il controller di dominio, tenere presenti le seguenti considerazioni di sicurezza:

• Le credenziali dell'amministratore locale di un computer che ospita controller di dominio scrivibili virtuali deve essere considerato equivalente all'amministratore di dominio predefinito di tutti i domini e le foreste a cui appartengono i controller di dominio.

• È consigliabile configurare il sistema in modo che un host esegua un'installazione Server Core di Windows Server senza applicazioni oltre a Hyper-V. Questa configurazione limita il numero di applicazioni e server installati sul server. Questa limitazione comporta prestazioni migliori del sistema e crea anche una superficie di attacco ridotta, in cui sono presenti meno punti di ingresso per gli attacchi dannosi tramite applicazioni e servizi.

• Per le succursali o altre sedi difficili da proteggere, è consigliabile usare controller di dominio di sola lettura (RODC). Se si dispone di una rete di gestione separata, è consigliabile che l'host sia connesso solo alla rete di gestione. Per maggiori informazioni sui controller di dominio di sola lettura (RODC), consultare la sezione Installare un controller di dominio di sola lettura di Windows Server 2012 Active Directory (livello 200).

• È possibile proteggere i controller di dominio con BitLocker. In Windows Server 2016 e versioni successive, è possibile inoltre usare la funzionalità TPM (Trusted Platform Module) che fornisce il materiale della chiave guest necessario per sbloccare il volume di sistema.

• L'infrastruttura sorvegliata e le macchine virtuali schermate possono fornire altri controlli per proteggere i controller di dominio.

Per altre informazioni sulla protezione dei controller di dominio, vedere la Guida alle procedure consigliate per la protezione delle installazioni di Active Directory.

Limiti di sicurezza per le configurazioni host e guest

È possibile implementare macchine virtuali (VM) in molti tipi diversi di configurazioni del controller di dominio. Pertanto, è necessario considerare attentamente il modo in cui tali VM influiscono sui limiti e sui trust nella topologia di Active Directory. Nell'elenco seguente, vengono descritte due configurazioni che è possibile configurare per i controller di dominio e gli host di Active Directory in un server Hyper-V e per i computer guest che sono VM in esecuzione nel server Hyper-V:

• Host che è un gruppo di lavoro o un computer membro con un guest che è un controller di dominio.
• Host che è un gruppo di lavoro o un computer membro con un guest che è anche un gruppo di lavoro o un computer membro.

Il seguente diagramma illustra una configurazione di tre VM del controller di dominio guest ospitate in un server Hyper-V.

Diagramma di una distribuzione di esempio di tre macchine virtuali (VM) e di un server Hyper-V. Le tre VM si trovano all'interno di un rettangolo blu con etichetta "computer guest". Tutte e tre le VM sono controller di dominio. La VM 1 si trova nel dominio Corp e nella foresta Contoso.com. VM2 si trova nel dominio Fabrikam e nella foresta Fabrikam.com. La VM 3 si trova nel dominio HQ e nella foresta Fineartschool.net. Il server Hyper-V si trova all'esterno del rettangolo blu. Si tratta di un server membro che si trova nel dominio Corp e nella foresta Contoso.com.

In base alla configurazione di esempio nel diagramma precedente, di seguito sono riportate alcune considerazioni importanti da tenere a mente durante la pianificazione di una distribuzione simile alla seguente:

• Accesso amministratore

  • Le credenziali di amministratore nel computer host devono essere considerate uguali a quelle dell'amministratore di dominio nel controller di dominio scrivibile. Per un guest RODC, le credenziali di amministratore del computer host devono essere considerate uguali a quelle dell'amministratore locale nel RODC guest.

• Diritti amministrativi del controller di dominio nel computer host

  • Un amministratore di un controller di dominio virtualizzato dispone di diritti amministrativi sull'host se si aggiunge l'host allo stesso dominio. Tuttavia, questo privilegio di accesso può anche offrire agli utenti malintenzionati la possibilità di compromettere tutte le VM se possono ottenere l'accesso alla VM 1. Questo scenario crea un possibile vettore di attacco. È possibile evitare questo vettore di attacco assicurandosi che tutti i controller di dominio configurati per più domini o foreste abbiano un dominio di amministrazione centralizzato considerato attendibile da tutti i domini e rendere l'host di virtualizzazione un membro del dominio di amministrazione con privilegi elevati. Questo approccio impedisce ai singoli amministratori di dominio di controllare l'host e quindi gli altri domini.

• Evitare attacchi

  • Gli utenti malintenzionati possono attaccare la VM 1 anche se la si installa come controller di dominio di sola lettura. Anche se gli amministratori del controller di dominio di sola lettura non dispongono in modo esplicito dei diritti di amministratore di dominio, possono comunque usare il RODC per applicare i criteri al computer host. Ad esempio, tali criteri possono includere script di avvio. Se un attore malintenzionato trova un modo per ottenere i diritti di amministratore del RODC e invia un criterio con uno script di avvio dannoso, può compromettere il computer host e usarlo per compromettere altre VM nell'host.

• Sicurezza dei file del disco rigido virtuale (VHD)

  • I file VHD per un controller di dominio virtuale sono come il disco rigido fisico di un controller di dominio fisico. Si dovrebbe essere altrettanto attenti a proteggere il file VHD come si farebbe con un disco rigido. Assicurarsi di consentire solo agli amministratori affidabili e attendibili di accedere a questi file VHD.

• Controller di dominio di sola lettura

  • È possibile posizionare i controller di dominio di sola lettura in posizioni in cui la sicurezza fisica non è garantita, ad esempio le succursali. È possibile proteggere i file VHD usando Crittografia unità BitLocker di Windows da attacchi all'host che comportano il furto del disco fisico. Tuttavia, queste protezioni non si applicano ai file system all'interno del RODC.

Considerazioni sulle prestazioni

L'architettura a 64 bit microkernel offre prestazioni migliori di Hyper-V rispetto alle piattaforme di virtualizzazione precedenti.

Le prestazioni delle VM dipendono dal carico di lavoro per cui vengono usate. È consigliabile testare topologie di VM specifiche per assicurarsi di essere soddisfatti delle prestazioni di distribuzione di Active Directory. È possibile valutare le prestazioni in base ai carichi di lavoro in un periodo di tempo specifico usando strumenti come Monitoraggio affidabilità e prestazioni (Perfmon.msc) o il kit di strumenti Microsoft Assessment and Planning (MAP). Lo strumento MAP consente inoltre di eseguire l'inventario di tutti i server e i ruoli dei server attualmente presenti nella rete.

Per dare un'idea del funzionamento del test delle prestazioni del controller di dominio virtualizzato, è stato creato un esempio di test delle prestazioni usando lo Strumento di test delle prestazioni di Active Directory (ADTest.exe).

I test LDAP (Lightweight Directory Access Protocol) sono stati eseguiti su un controller di dominio fisico usando ADTest.exe. Gli stessi test sono stati eseguiti in un controller di dominio virtualizzato costituito da una macchina virtuale ospitata in un server identico al controller di dominio fisico. In questo esempio, è stato usato un solo processore logico per il computer fisico e un solo processore virtuale per la VM. Questa configurazione ha consentito alla distribuzione di raggiungere facilmente l'utilizzo della CPU al 100%.

Nella tabella seguente, sono elencati i risultati dei test per i controller di dominio fisici e virtuali. Le lettere e i numeri tra parentesi accanto ai nomi dei test rappresentano le relative etichette in ADTest.exe. Questi dati illustrano che le prestazioni del controller di dominio virtualizzate sono state tra l'88 e il 98% delle prestazioni del controller di dominio fisico.

Misura	Test	Fisico	Le macchine	Delta
Ricerche/sec	Ricerca di un nome comune nell'ambito di base (L1)	11508	10276	-10.71%
Ricerche/sec	Ricerca di un insieme di attributi nell'ambito di base (L2)	10123	9005	-11.04%
Ricerche/sec	Ricerca di tutti gli attributi nell'ambito di base (L3)	1284	1242	-3.27%
Ricerche/sec	Ricerca di un nome comune nell'ambito del sottoalbero (L6)	8613	7904	-8.23%
Binding riusciti/sec	Esecuzione di binding veloci (B1)	1438	1374	-4.45%
Binding riusciti/sec	Esecuzione di binding semplici (B2)	611	550	-9.98%
Binding riusciti/sec	Utilizzo di NTLM per l'esecuzione dei binding (B5)	1068	1056	-1.12%
Scritture/sec	Scrittura di più attributi (W2)	6467	5885	-9.00%

Per ottimizzare le prestazioni nella distribuzione di test, in questa build di test, sono stati installati componenti di integrazione per consentire al sistema operativo guest di usare driver sintetici in grado di supportare hypervisor. Quando si installa un IC, a volte è necessario usare driver emulati Integrated Drive Electronics (IDE) o schede di rete. Negli ambienti di produzione è necessario sostituire tali driver emulati con driver sintetici per migliorare le prestazioni.

In base a questo test, considerare i consigli seguenti per migliorare le prestazioni:

• Quando si monitorano le prestazioni delle VM usando lo strumento Perfmon.msc, a volte, le informazioni sulla CPU per la VM non sono completamente accurate. Questa imprecisione è dovuta al modo in cui la CPU virtuale è pianificata per l'esecuzione nel processore fisico. Per ottenere informazioni più accurate sulla CPU per una VM in esecuzione in server Hyper-V, usare piuttosto i contatori del processore logico Hyper-V Hypervisor nella partizione host. Per altre informazioni sull'ottimizzazione delle prestazioni di Active Directory Domain Services e Hyper-V, vedere Linee guida per l'ottimizzazione delle prestazioni per Windows Server.

• È consigliabile evitare di usare dischi rigidi virtuali disco diversi in una VM configurata come controller di dominio, in quanto i dischi rigidi virtuali del disco differenze possono ridurre le prestazioni. Per altre informazioni sui tipi di disco Hyper-V, inclusi i dischi differenze, vedere Creazione guidata nuovo disco rigido virtuale.

• È inoltre consigliabile acquisire familiarità con le informazioni su come usare Active Directory Domain Services negli ambienti di hosting virtuale leggendo Aspetti da considerare quando si ospitano controller di dominio Active Directory in ambienti di hosting virtuale.

Considerazioni sulla distribuzione

Le seguenti sezioni descrivono le procedure comuni per le macchine virtuali da evitare durante la distribuzione di controller di dominio e considerazioni speciali per la sincronizzazione e l'archiviazione dell'ora.

Indicazioni di distribuzione

Le piattaforme di virtualizzazione, come Hyper-V, dispongono di molte funzionalità che semplificano la gestione, la manutenzione, il backup e la migrazione delle macchine. Esistono tuttavia alcuni suggerimenti da seguire per sfruttare queste funzionalità per i controller di dominio virtuali.

• Per garantire la durabilità delle scritture di Active Directory, non distribuire i file di database di un controller di dominio virtuale, ad esempio il database NTDS. DIT di Active Directory, log e SYSVOL su dischi IDE virtuali. Creare piuttosto un secondo disco rigido virtuale (VHD) collegato a un controller SCSI (Small Computer System Interface) virtuale e assicurarsi che i file di database si trovino nel disco SCSI della VM quando si installa il controller di dominio.

• Non implementare dischi rigidi virtuali differenze in una VM che si sta configurando come controller di dominio. Anche se questa operazione facilita il ripristino della distribuzione in versioni precedenti, comporta anche un calo delle prestazioni. Per altre informazioni sui tipi di disco rigido virtuale, vedere Creazione guidata nuovo disco rigido virtuale.

• Non distribuire nuovi domini e foreste di Active Directory in una copia di un sistema operativo Windows Server senza prima prepararli usando lo strumento sysprep (System Preparation) per prepararli alla distribuzione. Per altre informazioni sull'esecuzione di Sysprep, vedere Panoramica di Sysprep (Preparazione del sistema).

  Avviso

  L'esecuzione di Sysprep in un controller di dominio alzato di livello non è consigliata perché può influire negativamente sul database di Active Directory e sui componenti correlati e causare i problemi seguenti:

  • Perdita di dati
  • Corruzione del database AD
  • Problemi di stabilità e funzionalità
  • Problemi relativi a applicazioni, servizi e driver

• Non distribuire altri controller di dominio con una copia di un file VHD da un controller di dominio distribuito. Il non utilizzo di copie impedisce potenziali scenari di rollback USN. Per maggiori informazioni sul rollback USN, consultare la sezione USN e Rollback USN.

  • In Windows Server 2012 e versioni successive, gli amministratori possono clonare le immagini del controller di dominio per distribuire più controller di dominio solo se usano immagini propriamente preparate.

• Non usare la funzionalità di esportazione di Hyper-V per esportare una VM che esegue un controller di dominio.

  • In Windows Server 2012 e versioni successive, il sistema gestisce l'esportazione e l'importazione di guest virtuali del controller di dominio come un ripristino non autoritario. Questo processo rileva se l'ID di generazione è cambiato e se il controller di dominio non è configurato per la clonazione.

  • Quando si esporta una VM guest, è necessario assicurarsi che nessuno la usi. Per semplificare le operazioni, è possibile usare la replica Hyper-V per creare una copia inattiva del controller di dominio. Quando si inizia a usare l'immagine replicata, è necessario eseguire anche la pulizia come si farebbe per l'immagine di origine dopo l'esportazione di un'immagine guest del controller di dominio.

Conversione da fisica a virtuale

System Center VM Manager (VMM) consente di gestire computer fisici e VM in modo unificato. È inoltre possibile usare VMM per eseguire la migrazione di un computer fisico a una VM. Questo processo di migrazione è denominato conversione da fisica a VM o conversione P2V. Per avviare il processo di conversione P2V, è necessario assicurarsi che la VM e il controller di dominio fisico di cui si esegue la migrazione non siano in esecuzione contemporaneamente. Verificare che i due computer non siano in esecuzione contemporaneamente impedisce scenari di rollback USN, come descritto in USN e Rollback USN.

È consigliabile eseguire la conversione P2V in modalità offline per mantenere i dati della directory coerenti quando il controller di dominio viene riattivato. È possibile attivare o disattivare la modalità offline nel programma di installazione Converti server fisico. Per maggiori informazioni su come usare la modalità offline, consultare la sezione P2V: Convertire computer fisici in VM in VMM.

È inoltre necessario disconnettere la VM dalla rete durante la conversione P2V. È consigliabile abilitare la scheda di rete solo dopo aver completato il processo di conversione e verificare che tutto funzioni. A questo punto, il computer di origine fisica deve essere disattivato. Non riattivare il computer di origine fisico e riconnetterlo alla rete fino a quando non si riformatta il disco rigido.

Evitare il rollback degli USN

Quando si creano controller di dominio virtuali, è consigliabile evitare di creare scenari di rollback USN. Per evitare i rollback, è possibile configurare un nuovo controller di dominio virtuale tramite una promozione regolare, una promozione da Install from Media (IfM) oppure tramite la clonazione del controller di dominio, se si dispone già di almeno un controller di dominio virtuale. Questo approccio consente anche di evitare problemi legati all'hardware o alla piattaforma che i guest virtuali convertiti in P2V potrebbero incontrare.

Avviso

Per evitare problemi relativi alla replica di Active Directory, verificare che, in qualsiasi momento, sia presente una sola istanza fisica o virtuale di un determinato controller di dominio in una rete specifica. È possibile ridurre la probabilità che il clone precedente sia un problema usando uno dei seguenti metodi:

• Quando il nuovo controller di dominio virtuale è in esecuzione, eseguire il seguente comando due volte per modificare la password dell'account computer:

  netdom resetpwd /Server:<domain-controller>
  

• Esportare e importare il nuovo guest virtuale per forzarlo a diventare un nuovo ID generazione e un ID chiamata al database.

Ambienti di test e migrazione P2V

È possibile utilizzare la migrazione P2V in combinazione con VMM per creare ambienti di prova. Con questo metodo, è possibile eseguire la migrazione dei controller di dominio di produzione dai computer fisici alle macchine virtuali per creare un ambiente di test senza arrestare definitivamente i controller di dominio di produzione. Tuttavia, è necessario creare l'ambiente di test in una rete separata dall'ambiente di produzione per consentire l'esistenza di due istanze dello stesso controller di dominio. È importante evitare i rollback USN quando si creano ambienti di test usando la migrazione P2V.

Creazione di un ambiente di test

Quando si creano ambienti di test usando P2V, è consigliabile eseguire le operazioni seguenti:

• Eseguire la migrazione di un controller di dominio in produzione da ogni dominio a una macchina virtuale di test usando P2V in base alle raccomandazioni della sezione Conversione da fisica a virtuale.

• Posizionare i computer di produzione fisici e testare le VM in reti diverse quando vengono riconnesse.

• Per evitare Rollback USN nell'ambiente di test, disconnettere tutti i controller di dominio di cui si intende eseguire la migrazione dalla rete. È possibile disconnettere i controller di dominio arrestando il servizio NTDS o riavviando i computer in modalità di ripristino dei servizi directory.

• Non introdurre nuovi aggiornamenti all'ambiente dopo aver disconnesso i controller di dominio dalla rete.

• Non connettere nessuno dei computer alla rete durante la migrazione P2V. È possibile riconnetterli solo dopo aver completato la migrazione di tutti i computer.

• È consigliabile alzare di livello solo i controller di dominio di test esistenti dopo la conversione P2V come repliche nell'ambiente di test.

Servizio ora e sincronizzazione

Per le VM configurate come controller di dominio, è consigliabile disabilitare la sincronizzazione dell'ora tra il sistema host e il sistema operativo guest che funge da controller di dominio. Se il controller di dominio guest non si sincronizza con il sistema host, viene sincronizzato con la gerarchia di dominio.

Per disabilitare il provider di sincronizzazione dell'ora di Hyper-V, spegnere la VM, quindi passare alle impostazioni della VM, selezionare Servizi di integrazione e deselezionare la casella di controllo Sincronizzazione ora.

Archiviazione e ottimizzazione

È consigliabile seguire le raccomandazioni di archiviazione in questa sezione per ottimizzare le prestazioni della macchina virtuale del controller di dominio e assicurarsi che le scritture di Active Directory siano durevoli.

• Per l'archiviazione guest, archiviare il file di database di Active Directory (Ntds.dit) e i file di registro e i file SYSVOL su un disco virtuale separato dai file del sistema operativo. È consigliabile archiviare questi file in un disco SCSI virtuale in un secondo VHD collegato a un controller SCSI virtuale. Un disco SCSI virtuale aumenta le prestazioni e supporta l'accesso forzato alle unità (FUA). Con FUA, il sistema operativo scrive e legge i dati direttamente dal supporto, ignorando tutti i meccanismi di memorizzazione nella cache.

• Se si usa BitLocker per proteggere il guest del controller di dominio virtuale, configurare i volumi aggiuntivi per lo sblocco automatico usando il cmdlet Enable-BitLockerAutoUnlock di PowerShell.

• Quando si archiviano file VHD negli host, è consigliabile usare un disco che non viene spesso usato da altri servizi o applicazioni, ad esempio il disco di sistema per il sistema operativo host. Archiviare ogni file VHD in una partizione separata dal sistema operativo host e da altri file VHD, preferibilmente in un'unità fisica separata.

• Il sistema del disco fisico host deve soddisfare almeno uno dei seguenti criteri per soddisfare i requisiti di integrità dei dati del carico di lavoro virtualizzati:

  • L'host utilizza dischi di classe server, ad esempio SCSI o Fibre Channel.

  • L'host garantisce che i dischi siano connessi a un HBA con memorizzazione nella cache supportata dalla batteria.

  • L'host usa un controller di archiviazione come una matrice ridondante di dischi indipendenti (RAID) come dispositivo di archiviazione.

  • L'host usa un alimentatore (UPS) non interattivo per alimentare il disco.

  • L'host disabilita la funzionalità di memorizzazione nella cache di scrittura del disco per impostazione predefinita.

• Quando si usano file VHD, è consigliabile usare dischi pass-through o dischi rigidi virtuali di dimensioni fisse perché sono ottimizzati per le prestazioni. Non è consigliabile espandere e differenziare dinamicamente i dischi perché possono causare ritardi, riduzione delle prestazioni durante l'attività elevata del disco e potenziale perdita di dati durante il rollback a uno snapshot precedente.

• Si consiglia di utilizzare controller SCSI virtuali per ridurre la possibilità che i dati di Active Directory vengano danneggiati.

  • Nei server Hyper-V che ospitano controller di dominio virtuali, è consigliabile usare unità fisiche SCSI. Se lo scenario non consente di usare unità SCSI, è consigliabile disabilitare la memorizzazione nella cache di scrittura nell'unità Advanced Technology Attachment (ATA) o IDE (Integrated Drive Electronics) in uso. Per altre informazioni, vedere ID evento 1539 - Integrità del database.

Restrizioni operative per i controller di dominio della VM

I controller di dominio in esecuzione nelle macchine virtuali hanno restrizioni operative che non si applicano ai controller di dominio in esecuzione nei computer fisici. Quando si usa un controller di dominio virtualizzato, è necessario seguire queste linee guida:

• Non sospendere, arrestare o archiviare lo stato salvato di un controller di dominio in una VM per un periodo superiore alla durata dell'oggetto contrassegnato per la rimozione definitiva della foresta. La ripresa di uno stato salvato sospeso o salvato più a lungo della durata della rimozione definitiva può interferire con la replica. Per informazioni su come determinare la durata della rimozione definitiva per la foresta, vedere Determinare la durata della rimozione definitiva per la foresta.

• Non copiare o clonare VHD.

• Non creare o usare snapshot di controller di dominio virtuali. È consigliabile usare invece un metodo di backup più permanente e affidabile.

• Non usare la funzionalità Esporta in una macchina virtuale che esegue un controller di dominio.

• Non ripristinare o eseguire il rollback del controller di dominio o il contenuto di un database di Active Directory usando un metodo di backup non supportato.

Considerazioni su backup e ripristino

È necessario eseguire il backup dei controller di dominio per evitare la perdita di dati a causa di scenari di emergenza o errori amministrativi. Il metodo di backup supportato da Active Directory usa un'applicazione di backup per ripristinare un backup dello stato del sistema eseguito dall'installazione corrente del controller di dominio. L'applicazione posteriore deve essere compatibile con Active Directory, ad esempio Windows Server Backup. Per maggiori informazioni sui metodi di backup supportati, consultare la sezione Guida dettagliata al backup e al ripristino di AD DS.

Nelle distribuzioni virtualizzate, è necessario prestare particolare attenzione a determinati requisiti per le operazioni di backup di Active Directory. Ad esempio, se si ripristina un controller di dominio usando una copia del file VHD e non si aggiorna la versione del database del controller di dominio dopo il ripristino, possono verificarsi problemi con la replica a causa di numeri di rilevamento non accurati tra le repliche del controller di dominio. Nella maggior parte dei casi, la replica non rileva questo problema e non segnala errori, ma le incoerenze tra controller di dominio possono causare problemi in determinati scenari.

Metodo consigliato per il backup e il ripristino di controller di dominio virtualizzati

Il metodo consigliato per eseguire il backup e il ripristino dei controller di dominio virtualizzati consiste nell'eseguire Windows Server Backup nel sistema operativo guest. Per maggiori informazioni, consultare la sezione Ripristino di un controller di dominio virtuale.

Sebbene sia tecnicamente possibile usare snapshot o copie di file VHD per ripristinare un backup, non è consigliabile usare questi metodi per i motivi seguenti:

• Se si copia o si clona un file VHD, il database diventa obsoleto perché il numero di versione del database non viene aggiornato automaticamente quando viene ripristinato. Questa incoerenza nei numeri di rilevamento significa che, se si avvia il disco rigido virtuale in modalità normale, è possibile che si verifichi un Rollback USN.

• Anche se Windows Server 2016 (e versioni successive) è compatibile con gli snapshot, gli snapshot non forniscono il tipo di cronologia di backup stabile e permanente che è necessario ripristinare costantemente il sistema durante gli scenari di emergenza. Gli snapshot basati su Volume Shadow Copy Service (VSS) che è possibile creare in Windows Server 2016 Hyper-V e versioni successive non sono compatibili anche con BitLocker, e questo causa potenziali problemi di sicurezza. Questo problema impedisce al motore di database di Active Directory di accedere al database contenente lo snapshot quando Hyper-V tenta di montare il volume di snapshot.

Nota

Il progetto di VM schermata descritto in Infrastruttura sorvegliata e VM schermate ha un backup basato su host Hyper-V come non obiettivo per la massima protezione dei dati della VM guest.

USN e rollback degli USN

In questa appendice vengono descritti i problemi di replica che possono verificarsi in seguito a un ripristino non corretto del database di Active Directory con una versione precedente di una macchina virtuale. Per altre informazioni sul processo di replica di Active Directory, vedere Concetti relativi alla replica di Active Directory.

In che modo gli Active Directory Domain Services e i controller di dominio usano gli USN

Gli Active Directory Domain Services usano gli USN per tenere traccia della replica dei dati tra controller di dominio. Ogni volta che viene apportata una modifica ai dati contenuti nella directory, l'USN viene incrementato per segnalare una nuova modifica.

I controller di dominio di destinazione usano gli USN per tenere traccia degli aggiornamenti a ogni partizione di directory archiviata. L'USN tiene inoltre traccia dello stato di ogni altro controller di dominio in cui sono archiviate le repliche di queste partizioni di directory. Quando i controller di dominio replicano le modifiche l'una all'altra, eseguono query sui partner di replica per individuare le modifiche con USN maggiori dell'ultima modifica ricevuta dal controller di dominio dal partner.

È possibile reperire le tabelle dei metadati di replica che contengono gli USN nel vettore di aggiornamento e nel segno d'acqua elevato. I controller di dominio di origine e di destinazione usano queste tabelle per filtrare gli aggiornamenti richiesti per il controller di dominio di destinazione.

Il controller di dominio di destinazione mantiene la tabella vettoriale aggiornata per tenere traccia degli aggiornamenti di origine ricevuti da tutti i controller di dominio di origine. Quando un controller di dominio di destinazione richiede modifiche per una partizione di directory, fornisce il vettore di aggiornamento al controller di dominio di origine. Il controller di dominio di origine usa quindi questo valore per filtrare gli aggiornamenti inviati al controller di dominio di destinazione. Il controller di dominio di origine invia il proprio vettore di aggiornamento al controller di dominio di destinazione al termine di un ciclo di replica eseguito correttamente. Il controller di dominio di origine usa l'USN per tenere traccia del fatto che il controller di dominio di destinazione sia sincronizzato con gli aggiornamenti di origine in ogni controller di dominio e che gli aggiornamenti alle destinazioni siano allo stesso livello dell'origine.

Il controller di dominio di destinazione mantiene la tabella del limite massimo per tenere traccia delle modifiche più recenti ricevute da un controller di dominio di origine specifico per una partizione specifica. La tabella del livello massimo impedisce al controller di dominio di origine di inviare modifiche già ricevute dal controller di dominio di destinazione.

Identità database di directory

Oltre agli USN, i controller di dominio tengono traccia del database di directory dei partner di replica di origine. Il sistema mantiene l'identità del database di directory in esecuzione sul server separatamente dall'identità dell'oggetto server stesso. L'identità del database di directory in ogni controller di dominio viene archiviata nell'attributo invocationID dell'oggetto NTDS Settings, che si trova nel percorso cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*LDAP (Lightweight Directory Access Protocol).

Il sistema archivia l'oggetto server nell'objectGUIDattributo dell'NTDS Settingsoggetto. e non cambia mai. Tuttavia, nelle seguenti circostanze, l'identità del database della directory cambia:

• Quando si verifica una procedura di ripristino dello stato del sistema nel server.

• Quando si aggiunge una partizione di directory dell'applicazione al server, la si rimuove e la si aggiunge di nuovo.

• Quando un'istanza di Hyper-V attiva i writer VSS in una partizione contenente il VHD di un controller di dominio virtuale.

  In questo scenario, il guest attiva i propri writer VSS. Questa azione prevede lo stesso meccanismo usato dal processo di backup e ripristino. Questo metodo reimposta l'attributo invocationID.

L'attributo invocationID correla efficacemente un set di aggiornamenti di origine in un controller di dominio con una versione specifica del database di directory. Il vettore di aggiornamento e le tabelle del limite massimo usano rispettivamente il GUID invocationID e del controller di dominio in modo che i controller di dominio riconoscano la copia del database di Active Directory da cui arrivano le informazioni di replica.

L'attributo invocationID è un valore GUID (Globally Unique Identifier) visibile nella parte superiore dell'output dopo l'esecuzione del comando repadmin /showrepl. Il testo seguente rappresenta un esempio di output del comando:

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

Quando si ripristina Active Directory Domain Services in un controller di dominio, il sistema reimposta l'attributo invocationID. Questa modifica causa un aumento del traffico di replica, in cui la durata è relativa alle dimensioni della partizione che si sta replicando.

Per illustrare questo scenario, il diagramma seguente illustra un ambiente di esempio in cui il controller di dominio virtuale VDC1 e il controller di dominio DC2 sono due controller di dominio nello stesso dominio. Questo diagramma mostra come DC2 rileva il valore invocationID in VDC1 dopo una reimpostazione in uno scenario di ripristino supportato.

Diagramma che illustra un grafico di flusso della visualizzazione di VDC1 di se stesso e della vista DC2 di VDC1. Nella riga VDC1, VDC1 inizia con un USN di 1000 e un ID chiamata di B. Viene quindi ripristinato alla versione precedente, che ha un USN pari a 500 e un valore InvocationID pari a B. Le modifiche si verificano in VDC1, riportandola su USN 600 mentre l'ID chiamata rimane invariato. Nella riga che indica "DC2 view of VDC1", DC2 inizia con un ID di chiamata di VDC1(A)@USN1000. Dopo il ripristino di VDC1, DC2 reimposta l'USN previsto da 1000 a 500, impostandone il valore per L'ID chiamata B VDC1(B)@USN500. Continua a tenere traccia sia dell'ID chiamata A che dell'ID chiamata B. Dopo il set successivo di modifiche in VDC1, DC2 ora tiene traccia dell'ID di chiamata A di USN 1000 e del nuovo ID chiamata B di USN 600.

Rollback degli USN

Il rollback degli USN si verifica quando il sistema non è in grado di aggiornare un USN come di consueto, un utente elude gli aggiornamenti degli USN o un controller di dominio tenta di usare un USN inferiore all'aggiornamento più recente. Quando il sistema rileva un Rollback USN, interrompe la replica prima che la mancata corrispondenza possa causare una divergenza nella foresta.

Molti fattori possono causare un rollback degli USN. Ad esempio, può verificarsi se si usano file VHD precedenti o si esegue la conversione P2V senza disconnettere definitivamente il computer fisico dopo la conversione.

Prevenzione del rollback degli USN

È possibile evitare i rollback degli USN adottando le precauzioni seguenti:

• Quando non si esegue Windows Server 2012 o versione successiva, non creare o usare uno snapshot di una macchina virtuale del controller di dominio.

• Non copiare il file VHD del controller di dominio.

• Quando non si esegue Windows Server 2012 o versioni successive, non esportare la VM che esegue un controller di dominio.

• Ripristinare un controller di dominio o eseguire il rollback del contenuto di un database di Active Directory utilizzando solo soluzioni di backup proprietarie supportate, ad esempio, Windows Server Backup.

A volte, il sistema non riesce a rilevare il rollback degli USN prima che possa causare errori di replica. Quando si verificano errori di replica, è necessario identificare l'entità del problema e risolverlo il prima possibile. Per maggiori informazioni su come rimuovere gli oggetti persistenti che possono verificarsi in seguito al rollback degli USN, consultare la sezione ID evento di replica di Active Directory 1388 o 1988: viene rilevato un oggetto persistente.

Rilevamento del rollback degli USN

Nella maggior parte dei casi, il sistema è in grado di rilevare i rollback degli USN monitorando le incoerenze nell'attributo invocationID causato dal ripristino di un controller di dominio senza reimpostare l'attributo. Windows Server 2008 offre protezioni contro gli errori di replica dopo operazioni di ripristino del controller di dominio non supportate. Queste protezioni si attivano quando un'operazione di ripristino non supportata creare un numero inferiore di USN rispetto alle versioni originali, che rappresentano le modifiche già ricevute dai partner di replica.

In Windows Server, quando un controller di dominio di destinazione richiede modifiche usando un USN usato in precedenza, il controller di dominio di destinazione interpreta la risposta del partner di replica per indicare che i metadati di replica sono obsoleti. I metadati obsoleti indicano che il database di Active Directory nel controller di dominio di origine ha eseguito il rollback a uno stato precedente, quindi, il sistema risponde di conseguenza.

Si supponga, ad esempio, di eseguire il rollback del file VHD di una VM a una versione precedente. In questo caso, il controller di dominio di destinazione avvia le seguenti misure di quarantena sul controller di dominio sul quale è stata identificata una procedura di ripristino non supportata:

• Servizi di dominio Active Directory sospende il servizio Accesso rete che impedisce che gli account utente e gli account computer modifichino le password degli account. In questo modo è possibile evitare la perdita di tali modifiche quando vengono apportate dopo un ripristino inadeguato.

• Servizi di dominio Active Directory disabilita la replica di Active Directory in entrata e in uscita.

• AD DS genera l'ID evento 2095 nel registro eventi di Directory Service per registrare la condizione verificatasi.

Il seguente diagramma mostra la sequenza di eventi che si verificano quando AD DS rileva il rollback degli USN in VDC2, il controller di dominio di destinazione in esecuzione in una VM. In questa illustrazione, il rilevamento del rollback degli USN si verifica in VDC2, quando un partner di replica rileva che VDC2 ha inviato un valore USN aggiornato visualizzato in precedenza dal controller di dominio di destinazione. Questa condizione indica che il database VDC2 ha riscontrato un rollback.

Diagramma che illustra un diagramma di flusso degli aggiornamenti di VDC2 e del valore di aggiornamento DC1 per VDC2. VDC2 inizia con un USN di 100 e ID chiamata A. Aggiorna quindi gli USN da 101 a 200, che viene replicato in DC1. Tuttavia, l'utente crea anche una copia VHD di VDC2 USN 200. Successivamente, VDC2 esegue l'aggiornamento a USN 201 a 350 e replica tali modifiche in DC1. Tuttavia, VDC2 ha esito negativo. L'utente ripristina quindi VDC2 con la copia creata nel disco rigido virtuale USN 200. Successivamente, l'utente effettua un altro aggiornamento a VDC2 per una nuova versione di USN 201-355. DC1 richiede modifiche superiori a USN 350 da VDC2 e viene replicato perché l'USN in VDC2 è superiore a DC1. Tuttavia, la nuova versione di USN da 201 a 350 non è uguale a quella in DC1, causando un rollback degli USN.

Risolvere i problemi relativi all'ID evento 2095

Se, nel registro eventi del servizio directory, viene visualizzato l'ID evento 2095, mettere in pratica immediatamente quanto segue:

1. Isolare la macchina virtuale che ha registrato l'errore dalla rete.

2. Controllare se le modifiche segnalate hanno avuto origine da questo controller di dominio e propagate ad altri controller di dominio. Se l'evento è il risultato dell'uso di uno snapshot o di una copia di una VM, provare a scoprire quando si è verificato il rollback degli USN. Quando si ha il tempo, controllare i partner di replica del controller di dominio per stabilire se la replica si è verificata dopo il rollback.

   È possibile usare lo strumento Repadmin per verificare la provenienza delle modifiche. Per informazioni su come usare Repadmin, vedere Monitoraggio e risoluzione dei problemi di replica di Active Directory con Repadmin. Se non si riesce a stabilire, contattare il supporto tecnico Microsoft per assistenza.

3. Abbassare forzatamente il controller di dominio. Questa operazione comporta la pulizia dei metadati di tale controller e l’assegnazione dei ruoli di master operazioni, anche noti come ruoli FSMO (Flexible Single Master Operations). Per maggiori informazioni, consultare la sezione Eseguire il ripristino dal rollback degli USN.

4. Eliminare tutti i file VHD precedenti per il controller di dominio.

Rollback degli USN non rilevato

Il controller di dominio potrebbe non rilevare il rollback degli USN negli scenari seguenti:

• Il file VHD viene collegato a macchine virtuali diverse in esecuzione contemporaneamente in più posizioni.

• L'USN nel controller di dominio ripristinato è aumentato oltre l'ultimo USN ricevuto dall'altro controller di dominio.

Nello scenario del file VHD, altri controller di dominio potrebbero essere replicati con una delle macchine virtuali e le modifiche potrebbero verificarsi in entrambe le VM senza essere replicate nell'altra. Questa divergenza nella foresta può essere rilevata difficilmente e causerà risposte di directory imprevedibili. Questa situazione può verificarsi dopo una migrazione P2V se il controller di dominio fisico e la macchina virtuale vengono eseguiti nella stessa rete. Questa situazione può verificarsi anche se più controller di dominio virtuali vengono creati dallo stesso controller di dominio fisico e quindi eseguiti nella stessa rete.

Nello scenario USN, un intervallo di numeri USN viene applicato a due insiemi di modifiche diversi. Questo scenario può continuare per periodi prolungati senza essere rilevato. Quando si modifica un oggetto creato durante questo periodo, il sistema rileva un oggetto persistente e lo segnala come ID evento 1988 nel Visualizzatore eventi. Il diagramma seguente illustra perché il controller di dominio potrebbe non rilevare il rollback degli USN in questo scenario.

Diagramma che mostra un grafico di flusso per il processo di rilevamento del rollback in una compilazione di esempio. Esistono due controller di dominio con etichetta "VDC1" e "DC2". La fase iniziale del grafico di flusso mostra il controller di dominio virtuale, VDC1, creare uno snapshot quando l'USN è 2000. Dopo lo snapshot, VDC1 crea 100 utenti e il data center virtuale 1 aggiornato ha ora un USN pari a 2100. Gli aggiornamenti in VDC1 vengono replicati in DC2, che ora condivide l'USN 2100. Tuttavia, VDC1 usa lo snapshot impiegato per ripristinare la versione USN 2000. La versione ripristinata di VDC1 crea 150 nuovi utenti, che porta l'USN fino a 2150. Il data center virtuale 1 aggiornato viene replicato in DC2, ma DC2 non rileva le modifiche non corrispondenti perché l'USN è superiore all'USN dc2 di 2100. Il testo nella parte inferiore indica che "Il rollback degli USN non viene rilevato, il che comporta una divergenza non rilevata in cui gli USN da 2001 a 2100 non sono uguali tra i due controller di dominio.

Controller di dominio di sola lettura

I controller di dominio di sola lettura (RODC) sono controller di dominio che ospitano copie di sola lettura delle partizioni in un database di Active Directory. Grazie a tali controller è possibile evitare la maggior parte dei problemi relativi ai rollback degli USN in quanto non replicano le modifiche agli altri controller di dominio. Tuttavia, se un RODC viene replicato da un controller di dominio scrivibile interessato dal rollback degli USN, il rollback ha un impatto anche sul RODC.

Non è consigliabile usare uno snapshot per ripristinare un RODC. È consigliabile ripristinare solo un RODC usando un'applicazione di backup compatibile con Active Directory. Inoltre, come per i controller di dominio scrivibili, è opportuno evitare che un RODC rimanga in modalità non in linea per un periodo di tempo superiore alla durata per la rimozione definitiva. Questa condizione può generare oggetti residui nel controller di dominio di sola lettura.

Per altre informazioni sull'implementazione dei controller di dominio di sola lettura, vedere la Guida dettagliata ai controller di dominio di sola lettura.

Contenuti aggiuntivi

Informazioni su come ripristinare controller di dominio virtualizzati in Ripristinare controller di dominio virtualizzati.