Artigo original publicado em 1° de junho de 2012, sexta-feira

Nos últimos meses, recebemos relatórios sobre crescimento excessivo da pasta Itens Recuperáveis (que muitos chamam de Caçamba, apesar se não usarmos mais esse termo). Existem dois cenários principais que podem colaborar com esse crescimento excessivo.

1. Controle de versões de Recuperação de Item Individual e Retenção de Litígio
2. Log de Versões de Calendários

Recuperação de Item Individual e Retenção de Litígio

A Recuperação de Item Individual e Retenção de Litígio permitem a preservação dos dados na caixa de correio. Se você não tiver familiaridade com esses recursos, veja minha postagem anterior Recuperação de Item Individual no Exchange 2010 para saber mais.

Além de reter dados na caixa de correio, tanto a Recuperação de Item Individual quanto a Retenção de Litígio permitem o controle de versões. Basicamente, quando um item é alterado, é feita uma cópia na gravação (COW) para preservar sua versão original. O item original é colocado na pasta Itens Recuperáveis\Versões. Essa pasta não fica exposta aos usuários.

Considerando que o Exchange 2010 inclui uma alteração na maneira como os clientes conectam e acessam dados relacionados à caixa de correio, a atividade de cópia na gravação ocorre na camada XSO (Objeto do Sistema Exchange) no servidor de Acesso para Cliente.

O que dispara uma cópia na gravação?

• Para mensagens e postagens (IPM.Note* e IPM.Post*), a cópia na gravação captura as alterações no assunto, no corpo, nos anexos, nos remetentes/destinatários e nas datas de envio/recebimento.
• Para outros tipos de itens, a cópia na gravação captura qualquer alteração feita no item, com exceção de movimentações entre pastas e alterações no status lidos/não lidos.
• Os rascunhos são ignorados da cópia na gravação para evitar o excesso de cópias quando elas são salvas automaticamente.

O que pode causar o crescimento excessivo na pasta Itens Recuperáveis?

O comportamento da cópia na gravação pode gerar crescimento excessivo. Constatamos o seguinte cenário de uso do Microsoft Outlook como principal causa da cópia na gravação excessiva:

1. Você cria um compromisso de calendário.
2. Você anexa um documento do Office ao compromisso e o salva
3. Mais tarde, você decide abrir o compromisso para fazer referência a algum tópico no documento do Office. Você abre o documento.
4. Em segundo plano, o Outlook começa a salvar automaticamente esse compromisso aberto e o respectivo documento aberto (por padrão, o Outlook salva automaticamente a cada 3 minutos).
5. Cada evento de salvamento automático dispara uma cópia na gravação. Mas como o salvamento automático está salvando o documento do Office e o compromisso, há dois eventos de cópia na gravação. Para cada anexo adicional, uma versão subsequente da cópia na gravação também seria criada.

Puxa, que coisa!

Como os anexos fazem parte da mensagem, não faz sentido criar uma cópia para cada anexo no item. Basicamente, quando você salva um item com anexo, o Outlook executa estes recursos:

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

A cópia na gravação estava ocorendo com SaveAttachment e SaveMessage. Fuçando o código, constatamos que a chamada para SaveAttachment por fim chama o método Flush (uma técnica que o cliente usa para sincronizar o estado com o servidor) na mensagem à qual ele está associado depois que o anexo é salvo. Era essa chamada Flush que estava sinalizando ao código da cópia na gravação para que fosse executado.

Após análise detalhada, percebemos que a lógica da cópia na gravação é disparada na chamada Flush any. Essa foi uma descoberta fantástica porque o Flush pode ser iniciado em muitos cenários, possivelmente resultando na causa dos milhares de eventos de cópia na gravação que vários clientes testemunharam em seus ambientes.

Log de Versões de Calendários

O Log de Versões de Calendários é o processo pelo qual alterações no calendário feitas em uma caixa de correio são salvas mediante a cópia na gravação. O Log de Versões de Calendários foi introduzido no Exchange 2010 para ajudar a resolver e reparar os problemas de confiabilidade dos calendários.

O design do Log de Versões de Calendários serve para criar um log sempre que um item de calendário é alterado. Esses logs fornecem um histórico da reunião. Você pode usar o cmdlet Get-CalendarDiagnosticLog para examinar o histórico e determinar quais clientes executaram uma ação destrutiva. O segundo uso do Log de Versões de Calendários é feito pelo Assistente para Reparo de Calendário, que usa os logs ao tentar determinar o histórico de um determinado item de calendário para fins de detecção de inconsistência.

O Log de Versões de Calendários é habilitado por padrão nas caixas de correio do Exchange 2010. Você pode desabilitar ou habilitar esse recurso em uma caixa de correio com a propriedade CalendarVersionStoreDisabled. Observe que o nome da propriedade é CalendarVersionStoreDisabled, por isso o  valor padrão de $false significa que o Log de Versões de Calendários é habilitado por padrão.  Dependendo da configuração da caixa de correio, um processo diferente é seguido para armazenar cópias dos itens de calendário:

1. Se a caixa de correio não estiver habilitada para Recuperação de Item Individual ou Retenção de Litígio, as versões reduzidas dos itens de calendário serão mantidas na raiz da pasta Itens Recuperáveis por 120 dias. As versões reduzidas (o corpo e anexos de tipo de mensagem não interna ou não de primeiro nível) são criadas usando cópia na gravação.
2. Se a caixa de correio estiver habilitada para Recuperação de Item Individual ou Retenção de Litígio, cópias integrais dos itens de calendário estarão mantidas nas pastas Itens Recuperáveis\Exclusões ou Itens Recuperáveis\Versões. Uma versão reduzida é criada com a infraestrutura de cópia na gravação sempre que uma operação de exclusão irreversível é executada com base no item de calendário nas pastas Itens Recuperáveis\Exclusões ou Itens Recuperáveis\Versões. Essa versão reduzida é colocada na raiz da pasta Itens Recuperáveis e mantida por 120 dias. A única vez em que uma versão reduzida não é criada é quando o tempo do item na pasta Itens Recuperáveis\Exclusões ou Itens Recuperáveis\Versões é superior a 134 dias (120 + 14). Isso pode acontecer se você alterar o período de retenção, se o Assistente de Pastas da Caixa de Correio não estiver sendo executado, se a Retenção de Litígio estiver desabilitada etc.).

Devido ao problema mencionado de como a lógica da cópia na gravação não fez distinção entre as operações Flush e Save, o Log de Versões de Calendários, em alguns casos, poderia consumir uma alta porcentagem da cota da pasta Itens Recuperáveis (e, se você lembrar, o limite de aviso é de 20GB e a cota irreversível é de 30GB).

Se o tamanho da pasta for maior do que RecoverableItemsWarningQuota, o Log de Versões de Calendários será desabilitado para a caixa de correio. O valor RecoverableItemsWarningQuota que é usado depende das configurações da caixa de correio:

1. Se a caixa de correio tiver UseDatabaseQuotaDefaults definido como $true, será usado RecoverableItemsWarningQuota, do banco de dados da caixa de correio.
2. Se a caixa de correio tiver UseDatabaseQuotaDefaults definido como $false, será usado RecoverableItemsWarningQuota, da caixa de correio.

Quando o Log de Versões de Calendários está desabilitado, o seguinte evento é gerado no log de eventos Aplicativo no servidor de Acesso para Cliente:

ID de Evento: 5003
Fonte: Armazenamento de Camada Intermediária do MSExchange
Categoria da Tarefa: CopyOnWrite
Nível: Informações
Descrição: caixa de correio do usuário <legacyExchangeDN> excedeu a cota de aviso da caçamba. O log de calendários foi desabilitado para a caixa de correio.

E não é só isso que estamos fazendo. Não vou entrar em detalhes nesta etapa inicial de desenvolvimento, mas estamos trabalhando para melhorar ainda mais o Log de Versões de Calendários para minimizar o impacto desse recurso em sua implantação. Quando eu puder contar mais novidades, vou escrever neste blog.

Ross Smith IV
Gerente Principal do Programa
Experiência do cliente Exchange

Esta é uma postagem de blog traduzida. Consulte o artigo original em Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3