lunedì 23 ottobre 2017

Centralino IP PBX su Windows - 3CX Phone System which links here: http://www.3cx.it/centralino/index.html

 

 

RSS Feed RSS Feed

Login

Newsletter Newsletter

Registrati

RisorseGuide e Articoli

 

30

Active Directory disaster recovery: ripristino su hardware differente

Di Ermanno Goletto SysAdmin.it - MCTS - MCSA - MCP - MCBMSP - MCBMSS
e Mario Serra SysAdmin.it -
Microsoft MCP - MCTS - MCDST

Introduzione

In questo articolo prenderemo in esame uno scenario non aderente alle best practices indicate da Microsoft per quanto riguarda l'implementazione di un'infrastruttura Active Directory ovvero uno scenario in cui vi sia un unico Domain Controller. Questa situazione è però purtroppo frequente soprattutto in situazioni in cui siano presenti pochi client(si pensi ad esempio a piccoli uffici) dove il budget a disposizione non permette l'acquisto dell'hardware e della licenza per un secondo Domain Controller.

Sommario

Scenario

Lo scenario sarà un'infrastruttura con unica foresta a singolo dominio test.local in cui vi sia un solo domain controller SRVDC01 che detiene quindi i ruoli FSMO ed configurato come server DNS e Global Catalog.

Si supponga ora che il server SRVDC01 cessi di funzionare e sia necessario ripristinare il DC su hardware differente.

Ripristino del Domain Controller su hardware differente in ambiente Windows 2003 Server

Per poter ripristinare il Domain Controller su hardware differente occorre che siano verificate le seguenti condizioni:

  1. Avere a disposizione un backup della partizione di sistema e del System State eseguito dopo aver arrestato tutti i servizi che potrebbero bloccare file (antivirus, scansione dischi e servizi di indicizzazione). Essendo in un scenario con un unico DC quindi senza altri DC verso cui replicare il periodi di tombstone degli oggetti di Active Directory di 60 giorni (o 180 per sistemi Windows 2003 SP1 e successivi in determinate situazioni) può essere ignorato.

  2. Il computer origine e destinazione devono avere lo stesso tipo di HAL (Hardware Abstraction Layer) con alcune eccezioni:

    • Si può passare da ACPI multiprocessor a ACPI uniprocessor e viceversa.

    • Si può passare da MPS multiprocessor a MPS uniprocessor e viceversa.

E' possibile determinare il tipo di HAL tramite il nodo Computer della console Gestione Periferiche devmgmt.msc.

Nel caso in cui il computer sorgente abbia un HAL ACPI e quello destinazione un HAL MPS potrebbe essere possibile aggiornare il BIOS del computer destinazione per consentire il supporto ad ACPI, nel caso il fornitore della scheda madre abbia rilasciato l'aggiornamento.

  1. Il sistema sorgente e destinazione devono utilizzare un identico sistema operativo per quanto riguarda versione software e retail o OEM. La pratica più corretta è quella di installate il sistema di destinazione utilizzando lo stesso media impiegato per installare il sistema sorgente.

  2. Il sistema destinazione deve avere lo stesso livello di service pack e di hotfix del sistema sorgente.

  3. Il sistem sorgente e destinazione devono avere la stessa lettera per il drive logico di sistema (%systemdrive%) e lo stesso path di installazione (%systemroot%). Inoltre nel caso di un Domain Controller devono essere identici anche la posizione del database e dei log del servizio Active Directory e del database e dei log del FRS (File Replication Service).

  4. Sul sistema di destinazione rimuovere tutto l'hardware non necessario per completare il processo di restore in modo aumentare le probabilità di successo del ripristino (ad esempio disabilitare le schede di rete aggiuntive non necessarie che potranno essere installate al termine del processo di ripristino). 

La procedura di ripristino si articola nelle seguenti fasi:

  1. Installare sul sistema di destinazione il sistema operativo rispettando le condizioni viste precedentemente ai punti 3,4 e 5.

  2. Terminata l'installazione del sistema operativo sul sistema di destinazione utilizzare la console Gestione Computer (compmgmt.msc /s) per creare, formattare e assegnare le lettere di volume (le stesse del sistema sorgente) ad ogni volume su cui sono memorizzare componenti del system state o applicazioni nel sistema sorgente.

  3. Creare sul sistema di destinazione una directory C:\Backup e inserire all'interno di essa una copia del file %SystermDrive%\Boot.ini, e della cartella %SystemRoot%\Repair e delle sue sottodirectory.

  4. Eseguire il restore del system state e del drive di sistema sul sistema di destinazione tramite la seguente procedura:

    1. Avviare l'utility di sistema Backup (ntbackup.exe) in modalità interattiva (per default al primo avvio viene proposta la modalità guidata).

    2. Selezionare la voce Opzioni del menù Strumenti, selezionare la scheda Ripristino e quindi l'opzione Sostituisci sempre il file nel computer.

    3. Selezionare la scheda Ripristina e gestisci supporti.

    4. Catalogare il backup contenente il system state e il drive di sistema del sistema sorgente tramite la voce di Cataloga un file di backup. del menù Strumenti.

    5. Eseguire il restore assicurandosi che sia selezionata l'opzione Percorso originale in Destinazione file ripristinati.

    6. Selezionare Avvia ripristino.

    7. Confermare il messaggio d'avviso di sovrascrittura dello stato corrente del sistema.

    8. Avviare il ripristino accettando le opzioni di ripristino avanzate predefinite.

    9. Terminato il restore selezionare No al messaggio di richiesta di riavvio del computer.

  5. Eseguire le seguenti operazioni al termine del restore, ma prima di riavviare il sistema:

    1. Sostituire il file %SystermDrive%\Boot.ini e %SystemRoot%\Repair\Boot.ini con quello precedentemente memorizzato in C:\Backup\System.ini.

    2. Copiare la directory Repair e le sue sottodirectory da C:\Backup in %SystemRoot%\Repair.

    3. Reinstallare i driver del controller dell'hard disk nel caso nel sistema di destinazione siano stati utilizzati driver di terze parti non inclusi nel disco di installazione di Windows.

    4. Nelle impostazioni TCP/IP verificare che il server DNS non sia impostato su un server DSN non disponibile o su localhost (indirizzo IP locale o di loopback) in quanto i record DNS del backup potrebbero non essere più validi. Al termine del restore, dopo aver verificato che il sistema di destinazione funzioni correttamente sarà possibile impostare l'indirizzo di loopback come server DNS.

    5. Dal momento che il sistema di destinazione è l'unico DC del dominio occorre eseguire il restore autoritativo del File Replication service (FRS) tramite la seguenti impostazione:

      • Aprire la chiave di registro
        HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

      • Impostare il valore DWORD BurFlags a D4.

    6. Riavviare il sistema di destinazione.

    7. Se dopo il riavvio Windows non si avvia normalmente a causa del chipset differente, driver incompatibili o HAL non corrispondente. In questo caso occorre eseguire il ripristino del sistema operativo tramite la seguente procedura:

      1. Avviare i sistema tramite il CD di installazione di Windows.

      2. Premere Invio alla richiesta di Installazione di Windows.

      3. Premere F8 per accettare il Contratto di licenza di Windows.

      4. Premere R per ripristinare l'installazione di Windows.

    8. Se dopo il ripristino del sistema operativo Windows non si avvia normalmente utilizzare la seguente procedura:

      1. Avviare i sistema tramite il CD di installazione di Windows.

      2. Premere R alla richiesta di Installazione di Windows per aprire la console di ripristino.

      3. Digitare l'identifificativo dell'installazione di Windows a cui accedere (1 nel caso ve ne sia solo una) e premere Invio.

      4. Digitare la password di administrator e premere invio.

      5. Digitare il comando disable acpi per disabilitare l'ACPI.

      6. Digitare exit per chiudere la console di ripristino e riavviare il computer.

      7. Eseguire nuovamente il il ripristino del sistema operativo tramite la procedura descritta al punto 8.

    9. Un volta avviato il sistema di destinazione rimuovere le periferiche appartenenti al sistema sorgente e non esistenti nel sistema destinazione (ad esempio scheda di rete, scheda video, controller dischi) tramite la seguente procedura:

      1. Aprire il prompt dei comandi (cmd).

      2. Digitare il seguente comando per consentire la visualizzazione di tutte le periferiche nascoste:
        set DEVMGR_SHOW_NONPRESENT_DEVICES=1

      3. Aprire la console per la gestione delle periferiche tramite il comando devmgmt.msc.

      4. Visualizzare le periferiche nascoste selezionare la voce Mostra periferiche nascoste del menù Visualizza.

      5. Disinstallare le periferiche non esistenti nel sistema.

    10. Aprire le connessioni di rete (ncpa.cpl) e controllare le impostazioni di rete impostando l'indirizzo di loopback come server DNS.

    11. Riavviare il computer.

Se sul sistema sorgente sono presenti anche altre funzionalità oltre al DNS e all'Active Directory potrebbe accadere che siano necessarie ulteriori operazioni (ad esempio se sul sistema è presente il servizio licenze di Terminal Services durante il ripristino del sistema viene segnalato che sarà necessario reinstallare tale funzionalità).

Il mio consiglio nel caso si debba eseguire tale procedura è quello di utilizzare una macchina virtuale come sistema di destinazione in modo che per il futuro il ripristino su hardware differente si risolva nello spostare i file di quest'ultima o al limite nella loro conversione nel caso si utilizzi una nuova versione del software di virtualizzazione. Inoltre una volta rimessa in funzione l'Active Directory sarebbe consigliabile aggiungere un secondo domain controller e migrare su questo i ruoli fsmo in modo da avere un domain controller basato su un'installazione nuova evitando così di portarsi dietro possibili problemi dovuti al ripristino su hardware differente.

Per ulteriori informazioni si vedano i seguenti:

Ripristino del Domain Controller su hardware differente in ambiente Windows 2008 Server

Con Windows 2008 Server la gestione del backup e del restore è demandata a Windows Server Backup che ha sostituito NTBackup. Windows Server Backup utilizza il servizio Copia Shadow del volume e la tecnologia di backup a livello di blocco per eseguire il backup e ripristino del sistema operativo, di file, cartelle e volumi. Il ripristino può essere eseguito sullo stesso server oppure, in caso di errore hardware, in un server diverso con hardware simile e privo di sistema operativo.

Per quanto riguarda il restore su hardware differente occorre tenere presente che l'immagine di backup contiene i driver utilizzati per avviare il sistema dopo il restore, quindi nei casi in cui il tipo di controller dei dischi (IDE, SATA o SCSI) sia diverso tra computer sorgente e destinazione potrebbe essere necessario specificare i driver necessari durante la fase di ripristino.

La procedura di ripristino si articola nelle seguenti fasi:

  1. Avviare il sistema di destinazione col DVD di installazione di Windows 2008 Server. Nel sistema di destinazione dovrà essere disponibile il backup del sistema sorgente (per esempio memorizzato su un disco USB connesso al sistema).

  2. Selezionare l'opzione Ripristina il Computer.

  3. Selezionare l'opzione Ripristina il computer utilizzando un'immagine del sistema creata in precedenza (nel caso sia necessario utilizzare driver del controller dischi diversi da quelli del sistema sorgente e non compresi tra i driver disponibili sul DVD di installazione specificarli tramite Carica driver) quindi selezionare Avanti.

  4. Accettare l'opzione predefinita di ripristino dell'immagine di sistema più recente o selezionarne una specifica quindi selezionare Avanti.

  5. Terminata la procedura di ripristino, dopo aver avviato il sistema di destinazione rimuovere le periferiche appartenenti al sistema sorgente e non esistenti nel sistema destinazione (ad esempio scheda di rete, scheda video, controller dischi). La procedura è analogoga a quella utilizzata con sistemi Windows 2003 Server e descritta precedentemente al punto 9.

  6. Aprire le connessioni di rete (ncpa.cpl) e controllare le impostazioni di rete impostando l'indirizzo di loopback come server DNS.

  7. Riavviare il computer.

Anche in questo caso valgono le considerazioni fatte precedentemente per sistemi Windows 2003 Server di utilizzare una macchina virtuale come sistema di destinazione e di aggiungere un secondo domain controller su cui migrare i ruoli fsmo.

Per ulteriori informazioni si vedano

Verifica della funzionalità di Active Directory

Per verificare che Active Directory funzioni correttamente è possibile utilizzare il seguente script:

REM *** I test sono memorizzati su file nella directory di avvio dello script

REM Eliminazione test precedenti
DEL Test-*.txt

REM Controllo Share
net share > Test-01-NetShare.txt
dcdiag /test:netlogons /f:Test-02-NetLogons.txt /i

REM Controllo DNS
dcdiag /test:DNS /DnsDynamicUpdate /f:Test-03-DnsDynamicUpdate.txt /i
dcdiag /test:DNS /DnsRecordRegistration /f:Test-04-DnsRecordRegistration.txt /i
dcdiag /test:RegisterInDNS /DnsDomain:%USERDNSDOMAIN% /f:Test-05-RegisterInDNS.txt /i

REM Controllo Membership
dcdiag /test:MachineAccount /f:Test-06-MachineAccount.txt /i

REM Controllo Replica
dcdiag /test:Replications /f:Test-07-Replications.txt /i
dcdiag /test:VerifyReplicas /f:Test-08-VerifyReplicas.txt /i
repadmin /showreps > Test-09-RepAdmin-showreps.txt

REM Controllo Operations Masters
dcdiag /test:knowsofroleholders /f:Test-10-knowsofroleholders.txt /i
dcdiag /test:fsmocheck /f:Test-11-fsmocheck.txt /i
netdom /query fsmo >Test-12-QueryFsmo.txt

Conclusioni

Tale configurazione non rispetta le best practices indicate da Microsoft per quanto riguarda l'implementazione di un'infrastruttura Active Directory dal momento che con un solo DC non è possibile avere alcuna ridondanza. Ciò comporta inevitabilmente un disservizio nell'utilizzo delle funzionalità di rete che richiedono l'autenticazione che si protrae fino al temine della procedura di disaster recovery. E' quindi consigliabile prevedere la messa in funzione di un secondo DC utilizzando ad esempio una macchina virtuali per ridurre le spese legate all'hardware. In alternativa si potrebbe pensare di virtualizzare l'unico Domain Controller eseguendo periodici backup della macchina virtuale dopo averla arrestata, ciò non eviterebbe un disservizio nel caso in cui l'hardware su cui è in esecuzione la macchina virtuale cessasse di funzionare, ma ridurrebbe i tempi necessari alla procedura di disaster recovery e la semplificherebbe notevolmente.


Scritto in: Guide e Articoli
AZIONI: E-mail | Permalink |
CONDIVIDI: del.icio.us   Facebook   Digg   Google   Live Bookmarks   Newsvine   StumbleUpon   Technorati   Yahoo   DotNetKicks
blog comments powered by Disqus

Copyright 2011 by SysAdmin.it