COW: modifiche al controllo delle versioni degli elementi ripristinabili in Exchange 2010 SP2 RU3

Articolo originale pubblicato venerdì 1° giugno 2012

Negli ultimi mesi abbiamo ricevuto segnalazioni di una crescita eccessiva della cartella degli elementi ripristinabili (anche nota come Dumpster, sebbene non usiamo più questo termine). Esistono due scenari principali che contribuiscono a questa crescita eccessiva.

1. Controllo delle versioni per il ripristino di singoli elementi e conservazione a fini giudiziari
2. Registrazione della versione del calendario

Ripristino di singoli elementi e conservazione a fini giudiziari

Il ripristino di singoli elementi e la conservazione a fini giudiziari consentono di conservare i dati nella cassetta postale. Se non avete familiarità con queste caratteristiche, consultate il mio post precedente sul ripristino di singoli elementi in Exchange 2010 per ulteriori informazioni.

Oltre a conservare i dati nella cassetta postale il ripristino di singoli elementi e la conservazione ai fini giudiziari consentono anche il controllo delle versioni. In pratica, quando un elemento viene modificato, si esegue una copia in scrittura (COW) per conservare la versione originale dell'elemento. L'elemento originale viene posizionato nella cartella Elementi ripristinabili\Versioni, che non è esposta agli utenti.

Considerato che Exchange 2010 include un cambiamento nel modo in cui i client si connettono e accedono ai dati delle cassette postali, l'attività di copia in scrittura si verifica nel livello degli oggetti di sistema di Exchange (XSO) nel server di accesso Accesso client.

Cosa attiva la copia in scrittura?

• Nel caso dei messaggi e dei post (IPM.Note* e IPM.Post*), la copia in scrittura acquisisce le modifiche apportate all'oggetto, al corpo del messaggio, agli allegati, ai mittenti/destinatari e alle date di invio/ricezione.
• Per altri tipi di elementi, la copia in scrittura acquisisce qualsiasi modifica dell'elemento ad eccezione degli spostamenti tra cartelle e dei cambiamenti di stato (letto/non letto).
• Le bozze sono escluse dalla copia in scrittura per impedire il proliferare di copie quando vengono salvate automaticamente.

Cosa può causare la crescita eccessiva della cartella degli elementi ripristinabili?

Il comportamento di copia in scrittura può determinare una crescita eccessiva. Abbiamo scoperto che lo scenario con Microsoft Outlook rappresenta una delle cause principali dell'eccesso di copia in scrittura:

1. Si crea un appuntamento nel calendario.
2. Si allega un documento di Office all'appuntamento e si salva.
3. Successivamente si decide di aprire l'appuntamento per consultare qualche elemento nel documento di Office, quindi si apre il documento.
4. Nel frattempo, Outlook inizia a salvare automaticamente questo appuntamento aperto e il corrispondente documento aperto (per impostazione predefinita, Outlook esegue il salvataggio automatico ogni 3 minuti).
5. Ogni salvataggio automatico attiva una copia in scrittura. Ma poiché il salvataggio automatico riguarda sia il documento di Office che l'appuntamento, si verificano due eventi di copia in scrittura. Per ogni allegato aggiuntivo viene creata anche una versione successiva di copia in scrittura.

Immaginate il risultato.

Poiché gli allegati fanno parte del messaggio, non ha alcun senso creare una copia di ogni allegato come elemento a parte. In pratica quando salvate un elemento con un allegato, Outlook esegue le operazioni seguenti:

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

La copia in scrittura viene eseguita sia per SaveAttachment che per SaveMessage. Esaminando il codice abbiamo scoperto che la chiamata a SaveAttachment in realtà chiama il metodo Flush (uno strumento mediante il quale il client sincronizza lo stato con il server) per il messaggio a cui è associato l'allegato dopo che quest'ultimo viene salvato. È questo metodo Flush che indica al codice di copia in scrittura di agire.

Dopo un'ulteriore analisi abbiamo realizzato che la logica di copia in scrittura viene attivata per qualsiasi chiamata al metodo Flush. Questa è stata una rivelazione in quanto il metodo Flush può essere usato in molti scenari e pertanto può essere la causa degli innumerevoli eventi di copia in scrittura che vari clienti hanno notato nei propri ambienti.

Con Exchange 2010 SP2 RU3 e versioni successive, l'evento di copia in scrittura ora comprende la differenza tra operazioni Flush e Save, e viene attivato solo quando si verifica un'operazione Save.

Registrazione della versione del calendario

La registrazione della versione del calendario è il processo in base al quale i cambiamenti del calendario che si verificano in una cassetta postale vengono salvati tramite la copia in scrittura. Questo processo è stato introdotto in Exchange 2010 per agevolare la risoluzione dei problemi e il ripristino in caso di problemi di affidabilità del calendario.

Lo scopo della registrazione della versione del calendario è creare un registro ogni volta che un elemento di calendario viene modificato. Questi registri costituiscono una cronologia della riunione. È possibile usare il cmdlet Get-CalendarDiagnosticLog per esaminare la cronologia e determinare quali client hanno svolto un'azione distruttiva. Il secondo uso della registrazione della versione del calendario è ad opera dell'Assistente di ripristino calendario, che usa i registri nel tentativo di determinare la cronologia di un determinato elemento di calendario per rilevare eventuali problemi di coerenza.

La registrazione della versione del calendario è abilitata per impostazione predefinita nelle cassette postali di Exchange 2010. È possibile disabilitare o abilitare questo processo per una cassetta postale tramite la proprietà CalendarVersionStoreDisabled. Il nome della proprietà è CalendarVersionStoreDisabled, quindi il valore predefinito $false implica che la registrazione della versione del calendario è abilitata per impostazione predefinita. In base alla configurazione della cassetta postale, si segue un processo diverso per archiviare le copie degli elementi di calendario:

1. Se la cassetta postale non è abilitata per il ipristino di singoli elementi o la conservazione a fini giudiziari, nella radice della cartella degli elementi ripristinabili vengono conservate versioni estratte degli elementi di calendario per 120 giorni. Le versioni estratte (il corpo e gli allegati del messaggio non di primo livello o non incorporati vengono rimossi) vengono create tramite la copia in scrittura.
2. Se la cassetta postale è abilitata per il ripristino di singoli elementi o la conservazione a fini giudiziari, nelle cartelle Elementi ripristinabili\Eliminazioni o Elementi ripristinabili\Versioni vengono conservate copie complete degli elementi di calendario. Una versione estratta viene creata tramite l'infrastruttura di copia in scrittura ogni volta che viene eseguita un'operazione di eliminazione definitiva di un elemento di calendario nelle cartelle Elementi ripristinabili\Eliminazioni o Elementi ripristinabili\Versioni. Tale versione estratta viene posizionata nella radice della cartella degli elementi ripristinabili e conservata per 120 giorni. L'unico caso in cui non viene creata una versione estratta è quando l'elemento è presente nella cartella Elementi ripristinabili\Eliminazioni o Elementi ripristinabili\Versioni da più di 134 giorni (120 + 14). Ciò può verificarsi se modificate il periodo di conservazione, se l'Assistente cartelle gestite non è stato eseguito, se disabilitate la conservazione a fini giudiziari e così via.

A causa del problema descritto in precedenza per cui la logica della copia in scrittura non distingue tra le operazioni Flush e Save, la registrazione della versione del calendario può, in alcuni casi, consumare un'elevata percentuale della quota della cartella Elementi ripristinabili (se ricordate, la soglia di avviso è 20 GB e la quota rigida è 30 GB).

Sebbene il SP2 RU3 risolva i problemi della copia in scrittura, per far fronte al rischio che la registrazione della versione del calendario consumi tutta la quota della cartella Elementi ripristinabili, nel SP2 RU2 abbiamo introdotto un cambiamento nell'architettura in base al quale la registrazione della versione del calendario ora tiene in considerazione le dimensioni della cartella Elementi ripristinabili prima di avviare una copia in scrittura.

Se la dimensione della cartella è superiore al valore RecoverableItemsWarningQuota, la registrazione della versione del calendario viene disabilitata per la cassetta postale. Il valore RecoverableItemsWarningQuota usato dipende dalle impostazioni della cassetta postale:

1. Se il valore UseDatabaseQuotaDefaults della cassetta postale è impostato su $true, viene usato il valore RecoverableItemsWarningQuotadel database della cassetta postale.
2. Se il valore UseDatabaseQuotaDefaults della cassetta postale è impostato su $false, viene usato il valore RecoverableItemsWarningQuota della cassetta postale.

Se la registrazione della versione del calendario è disabilitata, nel registro eventi dell'applicazione viene generato l'evento seguente sul server Accesso client:

ID evento: 5003
Source: MSExchange Mid-Tier Storage
Task Category: CopyOnWrite
Level: Information
Description: User mailbox <legacyExchangeDN> has exceeded the dumpster warning quota. Calendar logging has been disabled for the mailbox.

Ma non finisce qui. Non entrerò nei dettagli in questa fase dello sviluppo, ma stiamo attualmente migliorando la registrazione della versione del calendario per ridurre al minimo l'impatto che questa caratteristica ha nelle distribuzioni. Appena potrò parlarne, lo farò tramite questo blog.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Questo è un post di blog localizzato. L'articolo originale è disponibile in Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3