Home > Microsoft > Troubleshooting, Disaster Protection & Recovery Active Directory

Troubleshooting, Disaster Protection & Recovery Active Directory

Tratto da: http://technet.microsoft.com/it-it/library/cc645506.aspx

Pianificazione delle operazioni di restore del System State in un contesto AD

Il restore del System State in un contesto AD è un’operazione delicata e importante in quanto tutti i DC sono impegnati continuamente a replicare le informazioni inerenti le partizioni tra loro condivise. Tutti i DC potenzialmente possono replicare oggetti delle partizioni Schema e Configuration, mentre solamente i DC appartenenti ad uno stesso dominio possono, e devono, replicarsi le informazioni in esso contenute.

In generale esistono quattro possibilità di restore del System State in un contesto AD:

  • Alternate location o restore in una posizione alternativa.
  • Primary restore o restore primario.
  • Normal restore o restore non-autoritativo.
  • Authoritative restore o restore non-autoritativo.

Nella scelta di una metodologia per il restore occorre tenere in considerazione i seguenti fattori:

  • Il backup del System State effettuato su un DC contiene tutte le informazioni relative alla replica di AD (e.g.: database NTDS.DIT, file di log e SysVol) da esso ospitata (oltre a informazioni sui Registry, file di boot, ecc.). Tutti gli oggetti AD contenuti in un set di backup del System State, sono caratterizzati dal timestamp e dal version number (o Update Sequence Number (USN)) relativi alla data e ora di effettuazione del backup.
  • Una operazione di backup o restore del System State coinvolge complessivamente tutto il blocco di informazioni relativo ad un computer, e non è possibile selezionare solamente alcuni componenti (se non operando un restore in alternate location, come di seguito indicato).
  • Infrastruttura logica AD: quanti altri DC esistono all’interno dello stesso dominio o di altri domini.
  • Infrastruttura fisica AD: quanti altri DC esistono nello stesso site dello stesso dominio o di altri domini.
  • Se alcuni o tutti gli oggetti AD (e.g.: l’intero database AD o solo una OU (con il relativo contenuto) o solamente un utente) ripristinati con il restore del System State devono essere “imposti” agli altri DC oppure se essi saranno soggetti alla replica degli altri DC partner dello stesso dominio o di altri domini della stessa foresta ?
attenzione Restore “FRS-aware” e “non-FRS-aware”

Il restore eseguito su server non DC è sempre di tipo non-FRS-aware, nel senso che il server assume di far parte di un ambiente “non replicato” (tranne che non faccia parte di un set di replica DFS) e che non esistano altre repliche su altri server. Esso pertanto è da considerarsi un restore autoritativo. Viceversa nel caso di un DC il restore è inteso sempre di tipo FRS-aware, nel senso che il DC assume di default di trovarsi in un ambiente “replicato” nel quale possono esistere altri DC ciascuno dotato di una propria replica. In tal caso il restore è di default non-autoritativo (i.e. il flag When restoring replicated data sets, mark the restored data as the primary data for all replicas non è inserito).

attenzione Restore “FRS-aware” e “non-FRS-aware”

Il restore eseguito su server non DC è sempre di tipo non-FRS-aware, nel senso che il server assume di far parte di un ambiente “non replicato” (tranne che non faccia parte di un set di replica DFS) e che non esistano altre repliche su altri server. Esso pertanto è da considerarsi un restore autoritativo. Viceversa nel caso di un DC il restore è inteso sempre di tipo FRS-aware, nel senso che il DC assume di default di trovarsi in un ambiente “replicato” nel quale possono esistere altri DC ciascuno dotato di una propria replica. In tal caso il restore è di default non-autoritativo (i.e. il flag When restoring replicated data sets, mark the restored data as the primary data for all replicas non è inserito).

attenzione Attenzione !

  1. Quando si effettua il restore del System State senza specificare l’opzione “Alternate Location”, vengono sovrascritte tutte le informazioni inerenti il set di informazioni del System State sul computer sul quale avviene l’operazione di restore (compreso i registry).

Il restore del System State su un DC richiede il riavvio del computer in modalità DSRM.

Restore del System State in una posizione alternativa

Il restore in “Alternate location” del System State si effettua selezionando l’opzione “Restore file to: Alternate Location” nella scheda “Restore and Manage Media”, come indicato in figura 4. Nel caso di un domain controller Win2K3 le componenti ripristinate nella directory indicata come locazione alternativa (e.g.: C:\NtdsRestore) sono i seguenti:

  • Active Directory
  • Boot Files.
  • COM+ Class Registration Database
  • Registry.
  • SysVol.

Questo tipo di restore viene effettuato nei casi in cui è necessario recuperare, su un computer diverso da quello sul quale è stato generato il System State, solamente alcune parti (e.g.: singole GPO o parte dei registry) senza rischiare di sovrascrivere completamente i dati del System State del computer sul quale si opera, oppure in preparazione della promozione di un domain controller addizionale (i.e.: additional domain controller) in un dominio tramite il comando DCPROMO /ADV (i.e.: modalità Installa From Media (IFM)).

image 4

Figure 4: Restore del System State in una posizione alternativa (Alternate Location)

Restore primario

Il restore primario viene effettuato nel caso in cui un server o DC è l’unico all’interno di un set di replica (FRS, SysVol) oppure se intenzionalmente si vuole forzare il contenuto a tutti gli altri server dello stesso set di replica. Viene utilizzato solamente in caso di ricostruzione di una infrastruttura AD o FRS (e.g.: DFS) nella quale tutti i DC di uno stesso dominio hanno avuto dei problemi e devono essere reinstallati. Un’altra “situazione problematica” nella quale è richiesto di effettuare un restore primario è quella citata nei due seguenti articoli: Microsoft Knowledge Base 290762 “FRS: Using the BurFlags Registry Key to Reinitialize File Replication Service Replica Sets”e 292438 “Troubleshooting journal_wrap errors on Sysvol and DFS replica sets”.

Per effettuare un restore primario è necessario seguire la seguente procedura:

  • Avviare l’utility NTBACKUP.
  • Selezionare la scheda Restore and Manage Media e selezionare i file da ripristinare (e.g.: System State).
  • Cliccare sul bottone Start Restore.
  • Cliccare sul bottone Advanced e selezionare la voce “When restoring replicated data sets, mark the restored data as the primary data for all replicas”.

image 5

Figure 5: Restore Primario
attenzione Attenzione !

Eseguire un restore primario solamente in caso di “disastro” e quando nessun altro membro dello stesso set di replica (o domain controller di dominio) è stato precedentemente ripristinato.

Restore normale o non-autoritativo

Il restore normale o non-autoritativo (modalità di default) del System State di un DC viene effettuato per ripristinare un DC nello stato corrispondente alla “fotografia” del suo System State, rispetto alla data e ora della sua esecuzione. Ciò vuol dire che tutti gli oggetti AD verranno ripristinati dal set di backup nel loro stato originale. Successivamente, al primo evento di replica del DC con gli eventuali partner di replica, gli oggetti e/o attributi, che nel frattempo sono stati modificati o aggiunti nelle repliche AD degli altri DC partner, verranno sovrascritti o aggiunti alla copia del database precedentemente ripristinato.

Per effettuare un restore non-autoritativo è necessario seguire la seguente procedura:

  • Riavviare il DC in modalità provvisoria e selezionare la voce “Directory Service Restore Mode (DSRM)”.
  • Eseguire il logon con l’account administrator e la password della “SAM Off-Line
  • Avviare l’utility NTBACKUP.
  • Selezionare la scheda Restore and Manage Media e selezionare il set di backup del System State da ripristinare.
  • Cliccare sul bottone Start Restore.
attenzione Attenzione !

Non modificare l’opzione “Restore files to: Original Location.

  • Confermare cliccando sul bottone OK all’interno della finestra del messaggio di sovrascrittura del System State corrente riportato in figura 6.

image 6

Figure 6: Avviso che il restore del System State sovrascriverà l’attuale System State presente sul computer
  • Confermare cliccando sul bottone OK all’interno della finestra Confirm Restore.
  • Verificare che il restore sia andato a buon fine e cliccare sul bottone Close all’interno della finestra Restore Progress.
  • Riavviare il DC (questa volta in modalità normale) cliccando sul bottone Yes all’interno della finestra Backup Utility indicata in figura 7.

image 7

Figure 7: Riavviare il DC per completare il restore non-autoritativo

Successivamente alla esecuzione di un restore non-autoritativo, al riavvio del DC, vengono effettuate le seguenti verifiche:

  • Controllo di consistenza del database.
  • Ricostruzione indici.
  • Allinenamento con lo stato del SDS AD (database AD e SysVol) corrispondente agli altri DC partner di replica.

Il restore non-autoritativo può essere utile in uno dei seguenti casi:

  • Il DC danneggiato (e.g.: corruzione del database o guasto al computer) è l’unico di un dominio/foresta: in tal caso non esiste la possibilità di replicare con nessun altro DC e quindi il System State ripristinato sarà definitivo (i.e.: in tal caso è come se fosse autoritativo).
  • Il DC danneggiato (e.g.: corruzione del database o guasto al computer) non è l’unico di un dominio/foresta: in tal caso il System State ripristinato sarà in parte (i.e.: relativamente a tutti gli oggetti modificati e/o aggiunti successivamente alla data e ora di esecuzione del backup del System State) sovrascritti dagli altri DC partner di replica.
attenzione Restore non-autoritativo in un contesto Win2K

Il restore non-autoritativo era molto utilizzato in ambiente AD Win2K in caso di reinstallazione di DC (conseguente a crash) in sedi remote ed in presenza di linee di collegamento non molto performanti. In queste condizioni per evitare la replicazione dell’intero database AD e della SysVol attraverso la rete geografica (WAN) a partire da un DC di un altro site (e.g.: sede centrale) si potevano adottare due metodi:

  • Effettuare la reinstallazione del nuovo DC direttamente in sede come un qualsiasi DC del site centrale. Successivamente, dopo aver modificato opportunamente i parametri relativi alla configurazione TCP/IP e spostato l’oggetto server dal site centrale al site della sede remota di appartenenza, rispedire il DC.
  • Effettuare un restore non-autoritativo su un nuovo server nel seguente modo:
    • Reinstallazione del computer con la stessa configurazione del precedente (i.e.: nome computer, coordinate IP,controller dischi, partizioni (tipo di file system e dimensione almeno uguale a quella del precedente sistema), ecc.).
    • Senza rieseguire la DCPROMO effettuare il restore non-autoritativo a partire da un backup valido del System State dello stesso DC.

In ambiente Win2K3 la stessa procedura presenta qualche problema per la risoluzione dei quali è necessario installare il SP1. Esiste comunque la possibilità, nel caso il DC da ripristinare non sia il primo e unico all’interno di un dominio AD Win2K3, di sfruttare la nuova opzione /ADV dell’utility DCPROMO per eseguire la promozione a DC a partire da una restore (eseguita in modalità alternate location) del System State di un altro DC (Install From Media (IFM)).

Restore-autoritativo

Il restore autoritativo di un DC viene effettuato nel caso in cui è necessario “riesumare” degli oggetti erroneamente cancellati a partire da un backup del System State avendo la garanzia che essi vengano considerati “come se fossero stati appena ricreati” ed essere forzatamente replicati verso gli altri DC replication partner.

Il restore autoritativo può essere eseguito di un singolo oggetto, di un contenitore (e.g.: una OU con il relativo contenuto) o dell’intero database AD. In quest’ultimo caso occorre prestare attenzione ai potenziali problemi che si possono determinare relativamente alla gestione delle password dei computer e delle trust tra eventuali altri domini Win2K/2K3 o WinNT. Infatti di default queste password vengono automaticamente ri-negoziate con una certa cadenza (i.e.: per i computer account ogni 5 gg) ed effettuando un restore autoritativo di tutto il contesto di dominio si rischia di ripristinarle ad un valore non più congruente con lo stato attuale. Pertanto, in caso di restore autoritativo dell’intero database AD o di porzioni del naming context (i.e.: partizione) relativo al dominio che include oggetti interessati alle suddette password è necessario procedere con il reset dei computer account e/o la ricreazione delle trust manualmente o attraverso l’utility NETDOM contenuta nei Support Tools di Win2K3.

Per effettuare un restore autoritativo è necessario seguire la seguente procedura:

  • Effettuare un restore non-autoritativo senza riavviare il DC.
  • Aprire una sessione Command Prompt ed eseguire il comando NTDSUTIL.
  • Al prompt di NTDSUTIL, inserire i seguenti comandi:
    • Inserire il comando Authoritative restore (o semplicemente le iniziali a r).
      • Dal prompt “Authoritative restore” inserire i seguenti comandi per marcare autoritativo l’oggetto AD da “riesumare”:restore subtree <DN-Oggetto>alla comparsa della finestra di dialogo mostrata in figura 8, confermare cliccando sul bottone Yes.

image 7

Figure 8: Restore autoritativo del System State
– Esempio 1: restore di un oggetto utente

authoritative restore: restore subtree “CN=Leone Randazzo,OU=sistemisti, DC=learning-solutions,DC=local”

Opening DIT database… Done.

The current time is 02-22-05 12:35.10.

Most recent database update occured at 02-22-05 11:08.46.

Increasing attribute version numbers by 100000.

Counting records that need updating…

Records found: 0000000001

Done.

Found 1 records to update.

Updating records…

Records remaining: 0000000000

Done.

Successfully updated 1 records.

Authoritative Restore completed successfully.

– Esempio 2: restore di una OU (e del relativo contenuto)

authoritative restore: restore subtree “OU=servers,dc= DC=learning-solutions,DC=local”

Opening DIT database… Done.

The current time is 02-22-05 12:43.59.

Most recent database update occured at 02-22-05 12:35.10.

Increasing attribute version numbers by 100000.

Counting records that need updating…

Records found: 0000000003

Done.

Found 3 records to update.

Updating records…

Records remaining: 0000000000

Done.

Successfully updated 3 records.

Authoritative Restore completed successfully.

– Esempio 3: restore dell’intero database AD (da eseguire solo in casi eccezionali e con molta cautela):

restore database

  • Ripetere l’operazione di restore subtree per tutti gli oggetti da ripristinare.
  • Inserire il comando quit per uscire dal contesto Authoritative restore.
  • Inserire il comando quit per uscire da NTDSUTIL.
  • Riavviare in modalità normale il DC.

L’effetto del comando di restore autoritativo (come si può notare dagli esempi precedenti) è di rimarcare l’oggetto indicato con un timestamp aggiornato ed avanzare il contatore USN (Update Sequence Number) ad un valore che risulti sicuramente superiore a quello di qualsiasi altro oggetto all’interno dell’infrastruttura AD (di solito viene sommato 100.000 moltiplicato per il numero dei giorni intercorsi dal backup del System State).

Al riavvio del DC in modalità normale e successivamente alla replica con eventuali altri DC partner di replica, si verifica un “authoritative merge”, nel senso che tutti gli oggetti ripristinati autoritativamente (i.e.: quelli precedentemente cancellati o modificati) verranno replicati agli altri DC, mentre eventuali nuovi oggetti creati o modificati successivamente al backup del System State ripristinato verranno replicati dagli altri DC al DC “ripristinato autoritativamente”.

E’ da notare che esistono alcune parti di AD che non possono essere ripristinate autoritativamente, tra questi:

  • Gli oggetti della partizione Schema AD non possono essere ripristinati autoritativamente.
  • Gli oggetti della partizione Configuration devono essere trattati con molta cautela in quanto il loro impattto è esteso a tutta la foresta. In ogni caso per alcuni tipi di oggetti (e.g.: connection object per la replica tra DC) non ha senso ripristinarli in quanto essi vengono ricreati automaticamente dal Knowledge Consistency Checker (KCC) come indicato nel capitolo 10 “La struttura fisica AD”.
  • Oggetti che interessano il servizio FRS solitamente contenuti in CN=File Replication Service,CN=System,DC=<DN-Dominio> e CN=NTFRS Subscriptions,CN=<Domain Controller> non devono essere ripristinati per non causare effetti collaterali con la replica gestita dal servizio FRS.
  • Gli oggetti che interessano il ruolo FSMO RID Master (e.g.: l’oggetto “RID Set” del DC RID Master e l’oggetto “RID Manager$” del contenitore System) non devono essere ripristinati per non causare effetti collaterali con la gestione dei SID degli oggetti Security Principal.
  • In ogni caso è consigliato ripristinare solo parti limitati di un qualsiasi Naming Context o Partizione.
Share

Microsoft

  1. Nessun commento ancora...