In questo post vorrei spiegare un po' di più sulle istantanee di Active Directory e su come si possono o non si possono usare.

Prima di tutto, chiariamo una cosa: le snapshot VM dei controller di dominio non sono supportate!

Se avete un controller di dominio virtualizzato e state pensando di fare un'istantanea della macchina virtuale dal vostro host (Hyper-V, VMWare o qualsiasi provider di cloud pubblico), fermatevi!

Si può leggere qui, come dichiarato ufficialmente da Microsoft http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx

Non prendere o usare un'istantanea di un controller di dominio virtuale".

La stessa cosa vale per la copia del disco rigido virtuale di un controller di dominio, l'uso di dischi di differenziazione o qualsiasi altra funzione non ancora inventata per riportare indietro nel tempo la macchina virtuale stessa senza utilizzare un metodo di backup e ripristino supportato.

Ora parliamo un po' del perché.

Quando i controller di dominio replicano, utilizzano un meccanismo chiamato vettore di aggiornamento per tenere traccia delle modifiche replicate.

Supponiamo di avere due controller di dominio DC1 e DC2, entrambi nel dominio corp.contoso.com. Ciascuno di questi controller di dominio avrà un numero di sequenza di aggiornamento (USN) locale che tiene traccia delle modifiche apportate al database locale. Questi USN sono locali e non vengono replicati (quindi sono diversi tra i due controller di dominio).

Pensate agli USN come a dei contatori che contano le modifiche effettuate localmente su ogni DC; un esempio reale potrebbe essere una guardia di sicurezza all'ingresso di un concerto che conta le persone che entrano. Ora pensate che questo concerto abbia due porte, con due guardie di sicurezza. Il numero sarebbe lo stesso? Sicuramente no!

Quindi diciamo che il nostro DC1 ha un USN massimo impegnato di 5000 e il DC2 ha un USN massimo impegnato di 6000. (tornando all'esempio delle guardie di sicurezza, la guardia di sicurezza n. 1 ha contato 5000 persone in entrata e la guardia di sicurezza n. 2 ha contato 6000 persone in entrata).

Che cosa ha a che fare con il vettore UTD? Beh, il vettore UTD mantiene localmente su ogni DC un elenco di quelli che sono stati gli USN impegnati più alti nel precedente tentativo di replica. Quindi, se attiviamo la replica nello stato attuale, al termine della stessa il vettore UTD sul DC1 mostrerà:

DC2 6000

E il vettore UTD sul DC2 si vedrebbe:

DC1 5000

Nota: è possibile visualizzare il vettore di aggiornamento utilizzando il comando repadmin:

Repadmin /showutdvec Nome DCN PartitionDN

Quindi, se torniamo all'esempio delle guardie di sicurezza, significa che a un certo punto si chiamano l'un l'altro dicendo: "Ehi, ho contato fino a 5000 persone", ecco i loro nomi, e l'altro dice: "Bene, ho contato fino a 6000, ecco i loro nomi": Bene, ho contato fino a 6000 persone, ecco i loro nomi.

Vediamo ora cosa succede durante un ripristino snapshot (rollback del server nel tempo).

Supponiamo di ripristinare DC1 a un punto in cui il suo USN impegnato più alto era 3000. Ora ricordate, la tabella vettoriale UTD su DC2 memorizza ancora il valore dell'USN impegnato più alto di DC1 come 5000. Quando provano a replicare, DC1 dice: "Ehi, ho delle modifiche fino a 3000". DC2 lo guarda in modo strano e dice: "Ma l'ultima volta che abbiamo replicato avevi modifiche fino a 5000".

Esempio delle guardie di sicurezza? Dopo la prima telefonata, arriva un'altra telefonata in cui la guardia di sicurezza n. 1 dice: "Ehi, ho contato fino a 3000 persone", la risposta della guardia di sicurezza n. 2? 'L'ultima volta che abbiamo parlato hai detto di aver contato fino a 5000', cosa c'è che non va?".

Vedete il problema?

Questa situazione è chiamata USN rollback e a quel punto i DC hanno smesso di parlare tra loro e di replicare qualsiasi informazione.

Come si risolve questo problema?

Quando si esegue il ripristino con un metodo supportato, il processo di ripristino modifica effettivamente il modo in cui il controller di dominio appare nella tabella del vettore di aggiornamento, cambiando il GUID del database (chiamato anche InvocationID). Le voci nel vettore up to dateness non sono in realtà nomi di DC, ma piuttosto i GUID del database dei controller di dominio replicati per lo specifico contesto di denominazione.

Nota: eseguendo Repadmin /showutdvec DCName PartitionDN /nocache verranno visualizzati i GUID indicati.

Quindi, quando un DC viene ripristinato utilizzando un metodo supportato, il GUID del database viene modificato, quindi DC2 sa che ora non è replicato con DC1, ma piuttosto con DC1a (che ha ancora lo stesso nome di computer, GUID del server e così via, ma ha un database AD diverso, che è quello che conta per la replica).

Quindi, in questo scenario è come se DC2 avesse iniziato a replicare con un controller di dominio nuovo di zecca, quindi non si verifica alcun rollback USN.

Questa è la spiegazione completa del perché le istantanee non sono supportate!

Ora, tolto questo dubbio, quali sono le buone istantanee?

Le buone istantanee sono quelle realizzate con il comando ntdsutil, che utilizza VSS per creare un'istantanea del database di Active Directory. Queste istantanee non possono essere utilizzate per ripristinare il database (per lo stesso motivo spiegato sopra), ma possono essere montate, ispezionate e alcune informazioni possono essere estratte e inserite nel database di produzione da strumenti come ldifde.exe e altri, ma sulle istantanee di AD si dirà di più nei prossimi post.

Un'importante considerazione da trarre da questo articolo. Utilizzate il backup dello stato del sistema per eseguire il backup dei controller di dominio e assicuratevi di sapere come ripristinarlo in ogni singolo scenario possibile.