none
Lista Exchange Trash

    Domanda

  • Buon giorno,

    non sapevo che titolo mettere.

    Purtroppo ho problemi di spazio sul server EXC2010.

    Per dare un po di fiato, ho cancellato le mail dal "cestino di exchange" (io lo chiamo cosi, non so come si chiami tecnicamente).

    Questo è il comando che do per ogni utente Search-Mailbox -Identity nome.cognome -SearchDumpsterOnly -DeleteContent.

    Adesso ho 2 necessità:

    1) Esiste modo per lanciare questo comando su tutte le mailbox?

    2) Esiste un comando che mi permetta di vedere quanti MB sono archiviati per ciascun cestino?

    N.b Per cestino di exchange, se non si è capito bene, intendo dove vengono parcheggiati i messaggi (di default 30gg) prima che vengano definitivamente cancellati anche dal server dopo che l'utente li ha cancellati dal cestino del client.

    Grazie!

    mercoledì 6 giugno 2012 08:04

Risposte

  • Ciao,

    Il Defrag Offline non è una buona idea. Fortunatamente il DB di Exchange si è evoluto nel tempo e con lui le modalità di maintenance :-)

    Se l'Online Maintenance e e l'Online Defragmentation non sono abbastanza è più facile:

    • Fare tutta la pulizia che serve
    • Spostare le mailbox su un nuovo DB (ricordo che la mailbox move in Exchange 2010 è Online per cui il downtime è minimo)
    • Buttare il vecchio DB

    Il comando dovrebbe essere qualcosa di simile:

    get-mailbox | search-mailbox etc., etc....

    L'offline defrag non è una buona idea per i seguenti motivi:

    • Intanto che lo fai l'intero DB è fermo. Nessuno accede a nulla per X ore a seconda della dimensione del DB.
    • Cambia la DB signature per cui ti saltano tutte le copie del DB e devi fare un full reseed. Il cambio di signature non è una transazione per cui non viene replicato. Quando la DB signature all'interno dei transaction log replicati non coinciderà più con quella della copia dle DB la replica salterà.
    • Sempre per il cambio di DB signature ti invalida tutti i backup precedenti (Stesso motivo sopra. la DB signature nei log dei backup non sarà la stessa che trovi in quelli di produzione)

    Questi punti valgono anche per Exchange 2007 ma in questo caso il downtime resta elevato dato che il move mailbox è offline.

    Conclusione: Eseutil /d dovrebbe fare la fine di eseutil /y (nessuno lo usa) :-)

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"

    mercoledì 6 giugno 2012 13:27

Tutte le risposte

  • Ciao, devo darti una brutta notizia...non si svuota molto in questo modo...per fare una pulizia corretta dovresti eseguire un'archiviazione sulle cassette postali e poi smontare il db e fare un bel defrag offline, allora si che cambia. SE vuoi fare una cosa carina (non so quanto è grande il tuo db) puoi anche crearne un secondo e spostare un po di utenti su quello in modo da bilanciarlo. Resta sempre il fatto che poi devi comunque anche fare la compattazione offline perchè da solo il db di exchange by design non si sgonfia solo archiviando...

    A.

    mercoledì 6 giugno 2012 12:44
    Moderatore
  • Ciao,

    Il Defrag Offline non è una buona idea. Fortunatamente il DB di Exchange si è evoluto nel tempo e con lui le modalità di maintenance :-)

    Se l'Online Maintenance e e l'Online Defragmentation non sono abbastanza è più facile:

    • Fare tutta la pulizia che serve
    • Spostare le mailbox su un nuovo DB (ricordo che la mailbox move in Exchange 2010 è Online per cui il downtime è minimo)
    • Buttare il vecchio DB

    Il comando dovrebbe essere qualcosa di simile:

    get-mailbox | search-mailbox etc., etc....

    L'offline defrag non è una buona idea per i seguenti motivi:

    • Intanto che lo fai l'intero DB è fermo. Nessuno accede a nulla per X ore a seconda della dimensione del DB.
    • Cambia la DB signature per cui ti saltano tutte le copie del DB e devi fare un full reseed. Il cambio di signature non è una transazione per cui non viene replicato. Quando la DB signature all'interno dei transaction log replicati non coinciderà più con quella della copia dle DB la replica salterà.
    • Sempre per il cambio di DB signature ti invalida tutti i backup precedenti (Stesso motivo sopra. la DB signature nei log dei backup non sarà la stessa che trovi in quelli di produzione)

    Questi punti valgono anche per Exchange 2007 ma in questo caso il downtime resta elevato dato che il move mailbox è offline.

    Conclusione: Eseutil /d dovrebbe fare la fine di eseutil /y (nessuno lo usa) :-)

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"

    mercoledì 6 giugno 2012 13:27
  • non mi sognerei mai di andare contro un MCM (WOW!) ci mancherebbe,  ma la risposta alla stessa domanda fatta da me povero ancora forming MCTS a quel tempo su 2007 fu diversa...ed era "smonta e per forza defragga" ed era data da un MVP...su un exchange 2007 sp2. e così ho sempre fatto ed ha sempre funzionato. Vero è che eseguo sempre backup completi del sever quindi non sono mai incocciato nel problema del DB con diversa signature. La mia risposta comunque a confronto della tua anche se valida sembra quella di un aborigeno australinano. ;-) E' sempre un piacere stare qui!!!

    Ciao a tutti!

    A.

     
    mercoledì 6 giugno 2012 14:03
    Moderatore
  • Il tutto è diviso in 3 db, 2 sono da 60 e 80gb, il terzo è irrisorio, 3 gb.

    Nel primo tengo le caselle con limitazioni a 500mb.
    Nel secondo ci sono le mailbox degli utenti disabilitati.
    Nel terzo ci sono gli account senza limiti di spazio.

    Il tutto è sotto un sistema clusterizzato con DAG.

    L'online manutention è schedulata ma non risolve il mio problema.
    Spostando le mailbox dal db piccolo ad un nuovo db ho notato che diminuisce di un bel po da 4.8 a 3.4gb.

    Però non posso e non voglio stare a trasferire tutte le mail da una parte all'altra e poi tornare indietro...
    L'offline defrag è sconsigliata, tra l'altro, in un sistema DAG quindi non so veramente che fare..

    Lo spazio non è effettivo di questo ne son sicuro infatti lanciando uno script vedo questo:

    WhiteSpace (MB)         : 18904
    MailboxCount            : 142
    Server                  : AR-BI-MLB02
    LastFullBackup          : 24/05/2012 04:02:12
    DatabaseSize (GB)       : 50
    DatabaseName            : MBDB01
    AverageMailboxSize (MB) : 182,584507042254


    WhiteSpace (MB)         : 24921
    MailboxCount            : 25
    Server                  : AR-BI-MLB02
    LastFullBackup          : 24/05/2012 04:02:12
    DatabaseSize (GB)       : 67
    DatabaseName            : MBDB03
    AverageMailboxSize (MB) : 1601,04

    Come si recupera il whitespace?
    Esiste un modo per lanciare la manutenzione sui db in maniera MANUALE e non solo schedulata? Magari da un errore e non la fa come dovrebbe...

    Grazie.

    giovedì 7 giugno 2012 13:27
  • Non prendere troppo per i fondelli :-D. Volendo guardare non mi sono ancora aggiornato all'MCM 2010. La risposta "smonta e defragga" è sempre stata una buona risposta ma non è più una necessità in 2010. Tutto qui.

    In 2010 la struttura interna del DB è stata rivoluzionata. La maintenance e il defrag sono migliorati ma continuano a non essere perfetti.
    La move online ti permette di girare attorno al problema senza avere troppo downtime.

    Link interessanti:

    http://technet.microsoft.com/en-us/library/bb125040.aspx

    http://blogs.technet.com/b/exchange/archive/2011/12/14/database-maintenance-in-exchange-2010.aspx

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"


    giovedì 7 giugno 2012 16:24
  • Ciao,

    snip ...

    Però non posso e non voglio stare a trasferire tutte le mail da una parte all'altra e poi tornare indietro...

    snip ...

    Non devi tornare indietro. Sposta le mailbox e cancella il vecchio DB.

    snip ...

    Lo spazio non è effettivo di questo ne son sicuro

    snip ...

    Lo spazio non sarà mai effettivo. All'interno del DB ci sono tanti altri dati necessari al corretto funzionamento di Outlook ed Exchange che non sono effettivamente mail, appuntamenti, etc....

    Facciamo alcuni esempi:

    • Tutta una serie di tabelle che servono ad Outlook ed Exchange per trovare i dati (tabelle, indici, etc...)
    • Il cosiddetto "whitespace" (che cmq. ci sarà sempre) serve per evitare che ad ogni mail inviata/ricevuta il sistema non debba cambiare la dimensione del file .edb cosa che genererebbe un casino di I/O inutile
    • Indici (non mi riferisco a quelli usati da Outlook per trovare le mail)

    snip...

    Esiste un modo per lanciare la manutenzione sui db in maniera MANUALE e non solo schedulata? Magari da un errore e non la fa come dovrebbe...

    snip...

    Non credo che stia fallendo cmq. puoi controllare questo doc:

    http://technet.microsoft.com/en-us/library/bb125040.aspx

    Ciao

    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"


    giovedì 7 giugno 2012 16:38
  • Gabriele, lo so cosa vale una MCM, ogni tanto mi certifico anche ioqui :-) non era uno sfottó, era un reale complimento, sei il primo che conosco. quindi tanta stima! poi vedi, ho pure imparato qualcosa di nuovo!! quindi ti dico, vieni qui più spesso perchè da un mcm c'è solo da imparare.

    A.

    giovedì 7 giugno 2012 16:42
    Moderatore
  • Ci vedremo a qualche cena/aperitivo/conferenza :-)
    Mi piacerebbe venire più spesso ma il tempo è poco :-(
    Quest'anno sto viaggiando davvero tanto.

    G.


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"

    venerdì 8 giugno 2012 03:28
  • Ciao, ma durante lo spostamento delle MBoxs ci sono dei downtime? O meglio, le persone che usano outlook se ne accorgono?
    venerdì 8 giugno 2012 06:22
  • sulla 2010 lo fa a caldo, sulla 2007 va offline la cassetta postale quindi sta giù finchè non ha finito lo spostamento.

    A.

    venerdì 8 giugno 2012 07:41
    Moderatore
  • Il downtime è minimo. Le move in Exchange 2010 sono online.

    Leggi Understanding Move Requests

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"

    venerdì 8 giugno 2012 07:42
  • ty

    Non ho capito se si può lanciare a mano l'online manutention.

    lunedì 11 giugno 2012 08:05
  • Il meglio che puoi fare è impostare la maintenance schedule all'ora che vuoi.

    http://technet.microsoft.com/en-us/library/bb691410.aspx

    Ciao
    Gabriele


    -- Gabriele Tansini [MSFT] Microsoft Certified Master: Exchange 2007 "This posting is provided "AS IS" with no warranties, and confers no rights"

    lunedì 11 giugno 2012 19:30
  • Ah ecco, come immaginavo / sto facendo.

    Ciao!

    martedì 12 giugno 2012 09:32