Quanto sono sicuri gli aggiornamenti dello schema di Windows Active Directory?

Sto cercando di comprendere meglio il modo in cui Active Directory gestisce gli aggiornamenti dello schema, in particolare la sicurezza con cui viene effettivamente fornita la procedura, quanto è importante l'AD e la gamma di situazioni in cui sono richiesti aggiornamenti. Exchange 2007, OCS, SCOM richiedono tutti modifiche dello schema, ad esempio, non è solo qualcosa che accade quando si sta valutando un passaggio importante da (diciamo) un Windows 2003 a un'infrastruttura di Windows 2008.

Quello che sto cercando è un consiglio sul miglior piano di backout per le modifiche dello schema, nel caso in cui vada storto. Sarebbe accettabile portare un controller di dominio offline durante l'aggiornamento, ad esempio, e utilizzarlo per ripristinare l'intero ambiente se l'aggiornamento dello schema non è riuscito? Ci sono problemi con la riattivazione di un controller di dominio che era offline durante un aggiornamento dello schema?

Gli aggiornamenti dello schema sono una funzione a senso unico. Puoi solo aggiungere un nuovo schema ad AD, non puoi mai cancellare nulla. Per questo motivo è sempre necessario valutare attentamente le alternative quando il software richiede estensioni o aggiornamenti dello schema; assicurati che sia qualcosa che sei disposto a impegnarti a utilizzare.

Per prima cosa, assicurati di avere una buona copia di backup del database AD (di solito% SystemRoot% \ ntds \ NTDS.DIT)! Conservalo in un luogo sicuro.

Se hai solo un DC nella tua foresta, è molto semplice. Basta eseguire adprep come indicato nelle istruzioni (o lasciare che il software aggiorni AD stesso).

Se hai più di un controller di dominio, assicurati che non ci siano errori segnalati da dcdiage replmon -syncall. Assicurarsi di disporre dei backup di ogni database AD (da ciascun controller di dominio). Determinare il controller di dominio con il ruolo Schema Master . Fare tutti gli aggiornamenti su / a quel server ove possibile.

AD si proteggerà nella maggior parte dei casi da aggiornamenti dello schema non riusciti. Se il file LDIF non passa la sintassi (ad esempio BSOD nel mezzo di un aggiornamento), non verrà caricato. Ogni "aggiornamento" ha il proprio set di file LDIF.

Non ho mai visto un aggiornamento dello schema (purché fatto correttamente) andare storto. La SM sembra davvero aver fatto di tutto per rendere questo processo solido e affidabile, e lo dimostra. Gli unici scenari reali in cui potrei vedere qualcosa di brutto accadere sarebbe se perdessi energia a metà strada (anche se non ne sono certo), o se il tuo annuncio fosse già fregato per cominciare (nel qual caso hai problemi più grandi).

Tutto ciò che un aggiornamento di schema fa realmente è estendere l'AD con nuove classi e proprietà di oggetti (che un'applicazione o una versione più recente di AD può utilizzare), quindi l'ambito del disastro è piuttosto limitato. Questo articolo tecnico fornisce una panoramica decente e copre alcuni potenziali casi di cose cattive.

L'approccio standard per me sarebbe quello di garantire che tutto funzioni correttamente in anticipo (tramite dcdiag, replmon, ecc.) E garantire che io abbia un backup ben noto di AD nel caso in cui succeda il peggio. Conserverei questo backup il più a lungo possibile, poiché AD può essere così dannatamente robusto che i problemi potrebbero non manifestarsi per molto tempo dopo. Quindi il backup e il ripristino standard sarebbero il mio rollback. Ma come ho detto, non l'ho mai visto.

L'approccio offline a un cc funzionerebbe per un piccolo ambiente. Per un ambiente di grandi dimensioni, preferirei eseguire l'aggiornamento su un CC non connesso. Se il processo di aggiornamento viene completato correttamente, quindi collegarlo alla rete e replicare le modifiche. Un backout in questo scenario sarebbe semplice come tirare un'unità di un set di mirror e spegnere il DC e reinserire la buona unità che era corrente prima dell'aggiornamento.

Su una grande rete con centinaia o migliaia di DC, reinserire il buon approccio DC non sarebbe pratico.