Exchange 2007 e cartelle pubbliche.

[frakka]

Devo tirare fuori da una copia di uno storage group del nostro brutto e peloso Exchange 2007 il contenuto delle cartelle pubbliche.
Per farla breve, si erano incartate alcuni riferimento storati in active directory e la consolle mi riportava alcune registrazioni ineliminabili di vecchie rubriche fuori linea. Dopo svariate ricerche, è saltato fuori che l'unico modo per ripristinare la situazione era eliminare con ADSIEdit da active directory la registrazione relativa a quello storage group e così ho fatto, elimando il vecchio db e creando un nuovo storage group in cui attestare le cartelle pubbliche. In quelle cartelle pubbliche ci son solo quattro cavolate e la rubrica fuori linea quindi ho deciso di procedere e amen.

Sapevo che il recupero del contenuto sarebbe stato problematico ma pensavo fosse comunque fattibile. A quanto pare però non è così perchè nessuno degli strumenti tradizionali (nativi di exchange o di terze parti come i software di backup di Symantec), è in grado di recuperare ste cavolo di cartelle: Non è possibile installare un secondo database di cartelle pubbliche perchè ogni server ne può ospitare solo uno e i recovery group funzionano solo con il database delle mailbox. Il tool di Symantec BackupExec, a quanto pare, può ripristinare granularmente i contenuti solo sullo stesso database ma non in un'altro sullo stesso server e il granular restore di SystemRecovery... Bè, lo storage non lo apre neppure: Frulla per ore senza arrivare a nulla (aperto ticket con Symantec mesi fà per un problema simile, a quanto pare è una situazione più o meno nota.)

L'unico modo sarebbe installare un secondo server exchange (meglio se a 32bit, dato che altrimenti l'esportazione in pst non funziona), montare il database e vedere se così riesco a copiare quello che mi serve da una parte all'altra.

Altrimenti ci sono tool di terze parti specifici, che permettono di aprire il file .edb anche offline ed gestirne il contenuto (esatazione singoli file, esportazione in pst, importazione su un nuovo server in produzione) ma per 32mb di dati probabilmente inutili (onestamente non credo le usi nessuno da noi!!) mi sembra un peccato.

Idee o suggerimenti?

[betaxp86]

Soluzioni non ne ho... ma non avete in azienda qualche ticket gratuito da spendervi con MS per la soluzione del problema? Che so proveniente da un MSDN o un TechNet?

[frakka]

Sì, certo li avremmo anche ma preferisco giocarmeli per un eventuale problema serio visto che siamo ancora a inizio anno con un paio di migrazioni importanti in vista non si sà mai...
Ripeto: poco male, c'era dentro un calendario credo inutilizzato e delle email riferite a persone che in azienda non ho mai visto quindi sono almeno 2 anni che nessuno ci butta dentro qualcosa ma la questione mi irrita terribilmente. Ci sarebbero questi tool ma spendere 300$ per una cosa del genere mi irrita troppo: Anche perchè le licenze più economiche si legano allo specifico Storage Group quindi un licenza acquistata per estrarre qualcosa da un db dismesso è praticamente comprata e buttata.

[frakka]

Problema risolto!
Litigando un bel pò con BackupExec sono riuscito a ripristinare completamente i contenuti che mi servivano, usando la redirezione verso il nuovo storage group.

[Totocellux]

Ottimo


Non so bene se e quanto avrebbe potuto esserti di aiuto nella tua situazione, ma al contrario di quanto viene indicato anche da Microsoft sulle pagine web, Exchange Server Mailbox Merge Wizard (ExMerge) può spesso essere proficuamente utilizzato anche sui file di Exchange 2007:

Using ExMerge with Exchange 2007

[frakka]

Uhm...
Non sò... Exmerge mi pare potesse operare solo verso il mailbox store, io avevo problemi con il "public folders". Fortunatamente ho trovato il modo di usare il BackupExec... Dato che l'abbiamo pagato (e neppure pochissimo!) che almeno faccia il suo dovere. Quello che mi fà strano è che le istruzioni sul sito di Symantec siano un pò "fumose" al riguardo...

Comunque la procedura è questa:

Dopo aver eliminato tramite ADSIEdit il secondo storage group, contenente le cartelle pubbliche, ho potuto crearne uno nuovo e vuoto. Per ripristinare tramite l'agente di BackupExec il secondo storage group o il solo contenuto delle public folders come prima cosa è necessario flaggare il database del nuovo Storage Group come “This database can be overwritten by a restore”.


E' poi possibile procedere in due modi:
1. Usando il VSS Provider, ripristinando un intero storage group o database, anche utilizzando un altro nome. In questo caso, è necessario utilizzare i semplici nomi degli storage group o dei database e non i percorsi, senza usare virgolette o altri simboli.
2. Re-indirizzando direttamente verso una specifica mailbox o “Public folders”. In questo caso, è necessario accertarsi che l'utente indicato come logon account abbia i permessi necessari per scrivere nelle public folders. Inoltre, nel campo in cui si indica la destinazione, bisogna indicare il percorso relativo alla radice del database (lasciare il campo vuoto è la “root” delle cartelle pubbliche mentre indicare “\” è sbagliato ed il symantec tenta di scrivere nel “First Storage Group”). Per le “Public Folders” non c'è possibilità di errore perchè ci può essere solo un db di “Public Folders” per ogni server, mentre per le mailbox presumo sia necessario indicare il percorso composto da Storage Group e mailbox (es: First Storage Group\nome.utente) ma non ho ancora potuto testarlo.


Settings → Microsoft Exchange: Accertarsi che l'unità su cui si indirizzano i “TEMP” abbia sufficiente spazio libero, Selezionare “Commit after restore completes” e “Mount Database after restore” (non necessario.) Anche se viene selezionato di smontare il database prima del restore, usando il VSSProvider il job fallisce se il database non è già smontato quindi è necessario farlo prima. La redirezione verso una “Public folders” funziona anche con il database montato (anzi, probabilmente non funziona senza!).


Settings → Advanced: Accertarsi che in questa sezione sia indicato un percorso locale al media server con sufficiente spezio libero. Questo è necessario per i recuperi granulari ogni volta che il backup non si trova su un supporto NTFS. Il percorso è riferito, appunto, ad una macchina diversa da quella cui si riferisce lo screenshoot soprastante.


Lanciato con queste impostazioni il job di ripristino tramite VSS è riuscito ma il restore così eseguito ripristina all'interno del database esistente il database che è stato backuppato quindi, oltre ai contenuti che mi servivano, sono state ripristinate anche le corruzioni.
Il restore con redirezione invece ha ottenuto lo scopo ed è riuscito a ripristinare i soli contenuti utili.