Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

Il restore di singole mail in Exchange 2010/2013 usando Windows Server Backup

Scritto da Ivan Salvade' il 4 agosto 2014

Non è facilissimo eseguire il restore di singole mail o singole mailbox, senza usare un software di backup di terze parti, o Data Protection Manager di Microsoft.

Ipotizzando che un certo utente abbia eseguito un “hard-delete” di alcune mail, e quindi non sia più in grado di recuperarle “autonomamente”, dovrà intervenire un amministratore per il recupero delle mail da un backup precedente.

Se non si dispone di software di backup professionali, l’unica alternativa è utilizzare Windows Server Backup (2008 R2 o 2012) del server Exchange.  Purtroppo il suo limite principale è quello di saper restorare solo interi database, e non direttamente singole mailbox o singole mail.

Quindi la strategia generale da seguire è la seguente :

  1. Identificare il backup da utilizzare per il recupero delle mail
  2. Eseguire il restore completo del/dei database su posizione alternativa
  3. Creare il Recovery Database in Exchange
  4. Eseguire il controllo di “corretto stato” del database restorato con Eseutil
  5. Montare il database restorato nel Recovery Database
  6. Utilizzare il comando Restore-Mailbox per ripristinare le mail cancellate
  7. Smontare ed eliminare il Recovery Database

Ecco ora i dettagli delle singole fasi.

Fase 1

Dovremo utilizzare un backup che siamo certi contenga le mail da recuperare.  In molti casi andrà bene quello del giorno prima, in altri casi bisogna opportunamente scegliere backup più vecchi.   Identificare il supporto corretto, ed “agganciarlo” (se già non lo è) al server Exchange (per esempio, potrebbe essere un disco USB o un disco su NAS mappato tramite iSCSI).

Fase 2

Windows Server Backup (quello presente in Windows Server 2008 R2 o Windows Server 2012), esegue il backup di Exchange a livello applicativo e a livello di volume, utilizzando il servizio VSS (Volume Shadow-Copy Service).  Questo significa che il backup sarà perfettamente consistente, grazie alla collaborazione tra Windows Server Backup e l’Exchange VSS Writer.  Però, non è possibile indicare a Windows Server Backup di backuppare solo un certo database o certe mailbox : in fase di backup, andranno selezionati tutti i volumi (interi) dove risiedono i database (.edb) e i logs di Exchange.

Questo si riflette anche nella fase di restore : non è possibile indicare di restorare solo un singolo database, ma verranno restorati tutti i DB contenuti nel backup.   Per le aziende che utilizzano un solo DB, questo non è un problema, ma per quelle che utilizzano più database, questo può rappresentare una grossa perdita di tempo.

Aprire Windows Server backup, e lanciare la procedura di restore.  Selezionare poi la data precisa del backup prescelto, utilizzando il calendario proposto dalla procedura : in grassetto sono evidenziate tutte le date per le quali esiste un backup da restorare (Fig. 1) :

exrest1.JPG      Fig. 1

Quindi si indica come elemento di restore le “Applicazioni” (se non dovesse essere disponibile la selezione, sicuramente il backup non è stato eseguito a regola d’arte e non è disponibile il restore applicativo con consistenza garantita dei database).  Fig. 2 :

exrest2.JPG      Fig. 2

Alla schermata successiva il wizard si accorge della presenza dei database (consistenti) di Exchange, e con il tasto “Visualizza Dettagli” è possibile visualizzarli.  Non è possibile restorare uno solo dei database (questo è uno svantaggio di Windows Server Backup rispetto ai software professionali). Fig. 3 :

exrest3.JPG      Fig. 3

Si devono restorare i database in un percorso alternativo (Fig. 4).  Si consiglia di utilizzare altri dischi interni del server Exchange (oppure provenienti da mappature iSCSI su NAS/SAN), sui quali ci sia sufficiente spazio per ospitare il restore di tutti i database.  Nel percorso utilizzato, dovrà essere successivamente creato il Database di Recupero (vedi passaggi successivi).

exrest4.JPG      Fig. 4

Fase 3

Si deve ora creare il Recovery Database, utilizzando il percorso indicato nella procedura di restore.  Nel Recovery Database verrà montato il database restorato (contenente le mail da recuperare), e da questo verranno estratte le mail necessarie con re-inserimento nel database di produzione (merge).

Per creare il Recovery Database è necessario utilizzare una linea di comando Powershell :

New-MailboxDatabase  -Name “RecoveryDB”  -Server FQDN_server_exchange  -EDBFilePath “X:\RecoveryDB\percorso_originale_file_edb”  -LogFolderPath “X:\Recoverydb\percorso_originale_logs”  -Recovery

Quindi, ipotizzando che il database originale avesse database e logs nei seguenti percorsi :

  • Server : “EXC.Adatum.com”
  • DB : ”F:\DB1\db1.edb”
  • Logs : “G:\LOGS1″

il precedente comando diventa :

New-MailboxDatabase  -Name “RecoveryDB”  -Server VAN-EX1.adatum.com  -EDBFilePath “X:\RecoveryDB\F_\DB1\db1.edb”  -LogFolderPath “X:\RecoveryDB\G_\LOGS1”  -Recovery

Nella seguente Fig. 5, ecco un esempio di esecuzione del suddetto comando, ipotizzando di avere un database iniziale di nome “Accounting” su un Mailbox Server “VAN-EX1.adatum.com”, con database “Accounting.edb” posizionato in “D:\AccountingDB” e i logs relativi posizionati in “C:\AccountingLogs” :

ese1.JPG    Fig. 5  (clicca sulla foto per ingrandirla)

Nella Fig. 5 è chiaramente visibile il warning “This database must be brought into a clean shutdown state before it can be mounted”.  Lo stato di “Clean shutdown” è raggiungibile con la procedura della prossima Fase 4.

Fase 4

Il Database appena restorato potrebbe essere in uno stato “non corretto” (per esempio con alcuni logs non ancora applicati al database).  Questo stato “sporco” non consentirebbe il suo montaggio nel database di recupero.

Bisogna allora utilizzare l’utility “Eseutil” per controllare lo stato ed eventualmente riparare il database.

La sintassi Eseutil per il controllo del database è il seguente (posizionare il prompt dei comandi nel preciso percorso dove risiede il database) :

Eseutil /mh  nome_database.edb 

In Fig. 6 è riportata l’esecuzione del suddetto comando sul database “Accounting.edb” appena restorato, con l’indicazione di “Dirty Shutdown” (a causa del log 39 mancante, in questo esempio) :

ese2.JPG     Fig.6  (clicca sulla foto per ingrandirla)

La sintassi di Eseutil per la riparazione del database (Soft Recovery) in caso di “Dirty Shutdown” è il seguente (posizionare il prompt dei comandi nel preciso percorso dove risiede il database) :

Eseutil /R Exx /i /d /l:percorso_dove_risiedono_i_Logs (Exx può essere E00, E01, E02, E03….  prefisso dei logs del database interessato)

In Fig. 7 ecco l’esecuzione del suddetto comando, ipotizzando che i logs si trovino nel percorso “C:\AccountingLogs”, e quindi indicando tale percorso al comando con il parametro “/l”.  In caso di database e logs nello stesso percorso, tale parametro poteva essere omesso :

ese3.JPG     Fig. 7  (clicca sulla foto per ingrandirla)

In Fig. 8 è stato rieseguito il comando “Eseutil /mh” per confermare la correzione dello stato in “Clean Shutdown” :

ese4.JPG     Fig. 8  (clicca sulla foto per ingrandirla)

Fase 5

Si monta ora il database restorato nel Database di Recupero.  Il comando powershell per l’operazione è il seguente :

Mount-Database “RecoveryDB   (usare il nome del vostro database di recupero)

Nella console grafica di Exchange di Fig. 9, si nota ora il database di recupero correttamente montato :

ese5.JPG     Fig. 9

Fase 6

Ora è necessario identificare, nel database di recupero,  le mail da restorare ed eseguirne il ripristino nel database di produzione.   Anche qui, non esiste un wizard grafico che possa eseguire la procedura, ma siamo costretti a ricorrere a comandi di powershell.

Se si utilizza Exchange 2010 RTM, l’unico comando disponibile sarebbe : Restore-Mailbox

Da Exchange 2010 SP1 in poi, diventa disponibile anche il comando New-MailboxRestoreRequest .   Ufficialmente, sarebbe quest’ultimo il comando da utilizzare, mentre Restore-Mailbox assumerebbe lo stato “deprecato”.

In realtà, Restore-Mailbox è sempre funzionante, ed è dotato della possibilità di estrarre mail dal Recovery Database in base ad intervalli di tempo (per esempio, estrarre e recuperare tutte le mail tra il 10 aprile 2014 e il 10 maggio 2014) : questa operazione non è (stranamente!) nelle capacità del comando New-MailboxRestoreRequest.

Entrambi i comandi hanno comunque parecchi parametri che permettono di localizzare mail all’interno del database di recupero, in base a diverse condizioni impostabili (es. per tipo di elemento, per data, per cartella, per parole contenute nelle mail, ecc.). Consiglio di analizzare tali parametri consultando l’help in linea dei due comandi ai seguenti link :

http://technet.microsoft.com/it-it/library/bb125218(v=exchg.141).aspx

http://technet.microsoft.com/it-it/library/ff829875(v=exchg.141).aspx

Ecco allora un esempio di linea di comando per recuperare mail in base ad intervalli di tempo :

Restore-Mailbox   -Identity nome_mailbox_da_recuperare   -RecoveryDatabase nome_recovery_database   -StartDate 04/10/2014   -EndDate 05/10/2014

Prima di eseguire in produzione il comando precedente, se ne possono testare gli esiti utilizzando il parametro “-ValidateOnly“.  Ecco l’esecuzione in Fig. 10, dove ipotizzo di voler ripristinare le mail tra il 10 aprile e il 10 maggio di un’utenza esemplificativa (tale “Michiyo”) :

ese6.JPG     Fig. 10 (clicca sulla foto per ingrandire)

Se gli esiti della simulazione sono soddisfacenti, si può eseguire il comando in produzione.  L’esempio delle Figg. 11 e 12 esegue il ripristino delle mail dell’utenza Michiyo, comprese tra il 10 aprile e il 10 maggio 2014.  Ricordo che le mail restorate vengono “unite” a quelle già presenti in produzione, che quindi non vengono perse.  E’ attivo per default anche il controllo dei duplicati, in modo che le mail già esistenti in produzione non vengano ripristinate.

ese7.JPG     Fig. 11 (clicca sulla foto per ingrandire)

ese8.JPG     Fig. 12 (clicca sulla foto per ingrandire)

Fase 7

Una volta terminata l’operazione di restore, è possibile smontare ed eliminare il database di recupero.

Smontaggio ed eliminazione possono essere eseguiti con l’unico comando :

Remove-MailboxDatabase   -Identity “RecoveryDB”

Ricordare di eliminare a mano logs e DB dalle cartelle del database di recupero : questo non viene eseguito in automatico.

Buon restore!!!  :-)

  • Share/Bookmark

Pubblicato in Exchange Server 2010, Exchange Server 2013 | Nessun commento »

E ora cosa usiamo al posto di TMG (Threat Management Gateway)?

Scritto da Ivan Salvade' il 25 luglio 2013

Forefront Threat Management Gateway 2010 è ormai stato abbandonato da Microsoft (con un annuncio del 12 settembre 2012), sebbene il supporto continui fino al 14 aprile 2015, per chi dovesse averlo implementato in rete.

In molti scenari, TMG era caldamente consigliato soprattutto come Reverse Proxy, ovvero con il compito di rendere disponibili all’esterno particolari protocolli applicativi come SMTP, HTTP, HTTPS ecc., proteggendo nel contempo le comunicazioni grazie alle sue caratteristiche di Firewall, URL Filtering e Intrusion Detection.

Sono famose le implementazioni di TMG 2010 per il Reverse Publishing dei servizi di Exchange Server oppure di Lync Server : addirittura, nei corsi ufficiali su questi due prodotti, un intero modulo è dedicato alla configurazione di TMG a questo scopo.

E ora cosa possiamo utilizzare al suo posto?

Fatta salva la possibilità di utilizzare una miriade di terze parti (Kemp Loadmaster, Squid, Kerio Control, EServ, Ositis WinProxy…), volendo rimanere in campo Microsoft cosa possiamo scegliere?

Le soluzioni sono 2 : IIS ARR (Application Routing Request) e UAG (Unified Access Gateway) 2010.

IIS ARR (Application Request Routing)

Si tratta di un componente opzionale di IIS, installabile su Windows Server 2008, 2008 R2 e 2012.  Il componente permette ad IIS di gestire URL Rewrites, richieste di Reverse Proxy, bilanciamenti di carico e altre features ancora, soprattutto se fatto lavorare con un altro modulo di IIS, il URL Rewrite Module.

Il server IIS con ARR e URL Rewrite non necessita di essere installato in ambiente Active Directory.

Sommariamente, ARR e URL Rewrite, congiuntamente, garantiscono le seguenti possibilità :

  • regole di routing applicabili al protocollo http
  • meccanismi sofisticati di bilanciamento di carico, con possibilità di Client Affinity per redirezionare le richieste provenienti da un client ad uno specifico server, utilizzando i cookies
  • Host Name Affinity
  • regole di Reverse Proxy
  • regole di rewriting di URLs, tag HTML, variabili server, intestazioni HTTP
  • supporto per il Failed Request tracing di IIS

Il link per il download diretto di ARR 2.5, in inglese a 64 bit, è il seguente :

http://download.microsoft.com/download/A/A/E/AAE77C2B-ED2D-4EE1-9AF7-D29E89EA623D/requestRouter_amd64_en-US.msi

Il link per il donwload diretto di URL Rewrite Module, in inglese a 64 bit,  è il seguente :

http://go.microsoft.com/?linkid=9722532

Forefront Unified Access Gateway 2010

UAG ha qualcosa in più (e anche qualcosa in meno) rispetto a TMG.

UAG ha le seguenti funzionalità non presenti in TMG :

  • SSL VPN (ma la si può implementare direttamente su Windows Server 2008/R2/2012)
  • migliori possibilità di configurazione delle autenticazioni e del Single Sign-On
  • ILP (Information Leakage Prevention)
  • Endpoint Security (con le Endpoint Access Policies per il controllo dei client)

UAG non ha le seguenti funzionalità di TMG :

  • Proxy in uscita
  • Malware inspection
  • IDS (Intrusion Detection System)
  • Templates di configurazione delle reti

L’ultimo Service Pack di UAG 2010 (il Service Pack 3) ha introdotto le seguenti nuove features :

  • Supporto per il publishing di Exchange 2013
  • Supporto per il publishing di SharePoint 2013
  • Supporto per tutte le applicazioni della suite di Office 2013
  • Supporto per Windows 8
  • Supporto per RDC 8.0 in esecuzione su Windows 8

Se aggiungiamo il già esistente supporto per Exchange, Lync e SharePoint 2010, e il supporto per iOS 5 su iPhone e iPad, Android 4 e Windows Phone 7.5, direi che UAG è assolutamente in grado di sopperire all’assenza di TMG.

Ricordo comunque che TMG continuerà a ricevere supporto base fino al 2015, e supporto esteso ben oltre questa data : nella mia opinione, può anche non essere necessario avventurarsi di colpo verso altre soluzioni.

  • Share/Bookmark

Pubblicato in Gestione dei Sistemi, Sicurezza | Nessun commento »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok