In questo post vorrei approfondire un po’ l’argomento delle istantanee di Active Directory e spiegare in quali casi è possibile utilizzarle e in quali no.

"Innanzitutto, chiariamo bene una cosa: gli snapshot VM dei controller di dominio non sono supportati!

Lasciatemelo ripetere: se avete un controller di dominio virtualizzato e state pensando di creare uno snapshot di quella macchina virtuale dal vostro host (Hyper-V, VMware o qualsiasi provider di cloud pubblico), fermatevi subito!

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 acquisire né utilizzare uno snapshot 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!

Supponiamo quindi che il nostro DC1 abbia un USN massimo assegnato pari a 5000 e che il DC2 abbia un USN massimo assegnato pari a 6000. (Tornando all’esempio delle guardie di sicurezza, la guardia n. 1 ha contato 5000 persone in entrata e la guardia n. 2 ne ha contate 6000).

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, ciò significa che a un certo punto si chiamano a vicenda dicendo: «Ehi, ho contato 5000 persone», ecco i loro nomi, e l’altro risponde: «Ottimo, io ne ho contate 6000, ecco i loro nomi».

Vediamo ora cosa succede durante un ripristino da snapshot (ripristino del server a un punto precedente nel tempo).

Supponiamo di ripristinare DC1 a un punto nel tempo in cui il suo USN più alto confermato era 3000. Ora, ricordate che la tabella dei vettori UTD su DC2 conserva ancora il valore dell’USN più alto confermato di DC1 come 5000. Quando provano a replicare, DC1 dice: “Ehi, ho modifiche fino a 3000”. DC2 “lo guarda storto” e risponde: “Ma l’ultima volta che abbiamo effettuato la replica avevi modifiche fino a 5000. Che cosa è successo?”.

Un esempio con le guardie di sicurezza? Dopo quella prima telefonata, ne arriva un’altra in cui la guardia di sicurezza n. 1 dice: «Ehi, ho contato 3000 persone». E la risposta della guardia di sicurezza n. 2? «L’ultima volta che abbiamo parlato avevi detto di averne contate 5000. Che cosa è successo?»

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 utilizzando un metodo supportato, il processo di ripristino modifica effettivamente il modo in cui il controller di dominio appare nella tabella del vettore di aggiornamento, modificando il GUID del database (chiamato anche InvocationID). Le voci presenti nel vettore di aggiornamento non sono in realtà nomi di controller di dominio, bensì i GUID dei database dei controller di dominio oggetto di replica per lo specifico contesto di denominazione.

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

Pertanto, quando un DC viene ripristinato utilizzando un metodo supportato, il GUID del database viene modificato; di conseguenza, il DC2 riconosce che ora non è più replicato con il DC1, bensì con il DC1a (che mantiene lo stesso nome del computer, lo stesso GUID del server, ecc., ma dispone di un database AD diverso, che è l'elemento rilevante ai fini della 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 dell'USN.

Ecco la spiegazione completa del motivo per cui gli snapshot non sono supportati!

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.