Artigo original publicado em 30 de maio de 2012, quarta-feira

Hoje mais cedo, a equipe CXP do Exchange lançou o Pacote Cumulativo de Atualizações 3 do Exchange Server 2010 SP2 no Centro de Download.

Essa atualização contém inúmeros problemas relatados por clientes e descobertos internamente. Veja o artigo KB2685289 sobre descrição do Pacote Cumulativo de Atualizações 3 do Exchange Server 2010 Service Pack 2 para saber mais.

Observação: alguns dos seguintes artigos da KB podem não estar disponíveis na época de publicação desta postagem.

Em particular, gostaríamos de observar especificamente as seguintes correções incluídas nesse lançamento:

• KB2689810Corpos de Solicitações de reunião são renderizados em texto sem formatação no Outlook quando criados pelos Serviços Web do Exchange.
• KB2674445É necessária a função para verificar consistência de ACL ao mover caixa de entrada.
• KB2700705RpcClientAccess trava com SocketException ao habilitar notificação por push de UDP.
• KB2705425Vazamento de memória no UMWorkerProcess.exe.
• KB2698976 Assistente MRM não processa uma caixa de correio com um contato criado em outros locatários.

Observações gerais:

Para mudanças DST: http://www.microsoft.com/time.

Observação para usuários do Forefront Protection do Exchange  Quem está executando o Forefront Protection para Exchange precisa verificar se executou estas etapas importantes na linha de comando do diretório Forefront antes e depois desse processo de instalação do pacote cumulativo. Sem essas etapas, os serviços do Exchange para Armazenamento e Transporte de Informações não começarão após a aplicação desta atualização. Antes de instalar a atualização, desabilite o ForeFront usando esse comando: fscutility /disable. Após instalar a atualização, reabilite o ForeFront executando fscutility /enable.

Equipe do Exchange

Esta é uma postagem de blog traduzida. Consulte o artigo original em Released: Update Rollup 3 for Exchange 2010 Service Pack 2

Artigo original publicado em 30 de maio de 2012, quarta-feira

Quase dois anos atrás, eu apresentei uma sessão sobre considerações de design de alta disponibilidade no evento TechEd América do Norte 2010. Durante essa sessão, descrevi as alterações que estávamos fazendo na maneira como a conectividade MAPI deveria ocorrer após transferências de caixas de correio e eventos de failover/switchover de banco de dados intersite. Infelizmente, depois da minha apresentação eliminamos o recurso devido à complexidade das alterações que precisaríamos introduzir e à falta de tempo hábil para testes antes do lançamento do Service Pack 1. E, por mais que eu tivesse priorizado o trabalho, não conseguimos disponibilizar essas alterações no Service Pack 2.

Infelizmente, nem toda eliminação de recurso pode ser feita de maneira cirúrgica, e parte das alterações de código na verdade foram mantidas no SP1. Por exemplo, talvez você tenha percebido que o cmdlet Set-DatabaseAvailabilityGroup tem uma propriedade chamada AllowCrossSiteRPCClientAccess. Você pode alternar essa propriedade booliana à vontade, mas ela não afetará nenhuma alteração comportamental no produto (Eu sei, eu sei… é por isso que acho que esta imagem é estranhamente relevante):

Comportamento da conectividade intersite do Acesso para Cliente RPC (RTM, SP1, SP2 a SP2-RU2)

Mas vamos mudar de assunto. Primeiro, vamos tratar de alguns conceitos básicos.

Com o Exchange 2010, uma alteração importante foi instituída na maneira como os clientes conectam e acessam dados relacionados à caixa de correio. Diferentemente das versões anteriores, os clientes não se conectam mais diretamente ao Armazenamento de Informações na função de servidor Caixa de Correio para acessar dados da caixa de correio. Em vez disso, os clientes se conectam a um conjunto de serviços na função CAS (Servidor de Acesso para Cliente) e de serviços nos dados da caixa de correio de acesso à função CAS que usam MAPI/RPC do servidor Caixa de Correio em nome do usuário conectado. Pense nisso como uma camada de abstração.

Basicamente, foi feita uma alteração simples de maneira que toda a conectividade MAPI relacionada à caixa de correio passa pelo serviço de Acesso para Cliente RPC na função de servidor CAS. Para facilitar essa camada de abstração, foram feitas alterações de maneira que os objetos de banco de dados não são mais objetos filho dos servidores Caixa de Correio. Uma nova propriedade foi adicionada ao banco de dados Caixa de Correio, RPCClientAccessServer, que define o legacyExchangeDN que deve ser usado para acessar o banco de dados específico. Essa propriedade assume um FQDN como valor. Para garantir que você tenha alta disponibilidade e tolerância a falhas em caso de problema no CAS, esse valor deve ser o FQDN de uma matriz CAS com balanceamento de carga. Esse FQDN com balanceamento de carga é o que chamamos de matriz de Servidor de Acesso para Cliente RPC.

Para saber mais, veja as postagens de Brian Day sobre desmitificação do Objeto de Matriz CAS, Parte 1 e Parte 2.

Típica experiência do Outlook

Todas as versões do Outlook se comportam de maneira constante no cenário de um único datacenter (ou um único site do Active Directory). O ponto de extremidade RPC do perfil do Outlook é a matriz de Servidor de Acesso para Cliente RPC (ou um CAS específico se por algum motivo você não criou uma matriz - mas deveria ter criado -, e se você não sabe por que, vou repetir, leia as postagens de Brian). Sempre que uma falha ocorre no DAG (falha de banco de dados, falha de servidor etc.), o ponto de extremidade RPC não é alterado, assim o Outlook continua se conectando à mesma matriz de Servidor de Acesso para Cliente RPC. Sempre que ocorre uma falha na matriz CAS (falha de CAS, falha do balanceador de carga etc.), o ponto de extremidade RPC não é alterado, assim o Outlook continua tentando se conectar à matriz de Servidor de Acesso para Cliente RPC.

Todas as versões do Outlook se comportam de maneira constante em um cenário de switchover de datacenter também, pressupondo que você siga nossa diretriz. Por que é assim? Bom, em um switchover de datacenter, você altera o endereço IP da entrada DNS da matriz de Servidor de Acesso para Cliente RPC no datacenter primário para apontar para a respectiva matriz no datacenter de espera. A descoberta automática continua distribuindo a matriz do datacenter primário como ponto de extremidade RPC. Os clientes do Outlook existentes não precisam de nenhuma reconfiguração; depois que o cache DNS no cliente é atualizado, o cliente simplesmente se conecta ao ponto de extremidade que agora reside no datacenter de espera. Para entender totalmente por que isso funciona, é necessário assimilar que nem o cliente, nem o CAS realmente se importa com o site em que o CAS existe; eles simplesmente aceitam que podem se conectar e que o CAS ao qual o cliente está conectado pode oferecer acesso à caixa de correio.

Comportamento de failover/switchover de banco de dados intersite

Para entender esse cenário, é importante assimilar que, ao configurar um DAG de vários sites, a propriedade RPCClientAccessServer de um determinado banco de dados normalmente é associada à matriz de Servidor de Acesso para Cliente RPC que está no mesmo site do AD da cópia do banco de dados da caixa de correio com o menor número de preferência de ativação. Por exemplo:

Figura 1: DAG (Grupo de Disponibilidade de Banco de Dados) abrangendo dois sites do Active Directory

No caso de uma cópia do banco de dados ser ativada no datacenter de espera, os usuários continuarão aproveitando a matriz de Servidor de Acesso para Cliente RPC do site do AD em que o banco de dados da caixa de correio com o menor valor de preferência de ativação reside como ponto de extremidade de conectividade.

Figura 2: Banco de dados MDB1 foi ativado no site de espera do Active Directory

Se você examinar os logs de Acesso para Cliente RPC na matriz de Acesso para Cliente RPC de origem, verá:

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

No caso de a matriz de Servidor de Acesso para Cliente RPC do site do AD em que o banco de dados da caixa de correio com o menor valor de preferência de ativação reside ficar inacessível a outros usuários, os clientes do Outlook não poderão se conectar à caixa de correio que reside no datacenter oposto. Em outras palavras, há um evento de falha no datacenter e o processo de switchover de datacenter precisa ser executado.

Uma maneira mais simples de analisar esse comportamento é que o Outlook sempre se conecta ao ponto de extremidade RPC configurado (pressupondo que seja alcançável) independentemente do valor da propriedade RPCClientAccessServer do banco de dados.

O sistema alguma vez pode alterar o valor RPCClientAccessServer automaticamente?

A única vez em que o sistema altera o valor RPCClientAccessServer no banco de dados é quando o administrador altera o número ActivationPreference na cópia de banco de dados ativada de maneira que agora tenha o valor menor (significando que ela se torna a cópia preferida), conforme visto na Figura 3.

Figura 3: O banco de dados MDB1 foi ativado no site de espera do Active Directory e a propriedade RPCClientAccessServer foi alterada

Entretanto, os clientes do Outlook com um perfil do Outlook existente continuavam usando o antigo ponto de extremidade RPC em vez do novo ponto de extremidade RPC (mesmo se a Descoberta Automática detectasse a alteração). Isso ocorre porque o antigo ponto de extremidade RPC não retorna uma resposta ecWrongServer ao cliente. O ponto de extremidade RPC aceita a conexão; portanto, o Outlook ignora a resposta da Descoberta Automática porque ela tem uma conexão funcional. No caso de o antigo ponto de extremidade RPC ficar inacessível, o Outlook 2007/2010 atualizava suas configurações (o Outlook 2003, em contrapartida, não aproveitava e não aproveita a Descoberta Automática). A qualque momento, era possível forçar o Outlook a usar o novo ponto de extremidade RPC com um reparo de perfil.

O que acontece se o administrador atualizar manualmente o valor RPCClientAccessServer após um evento de failover/switchover de banco de dados intersite?

Voltando à Figura 2, se o administrador atualizar manualmente o valor RPCClientAccessServer para apontar para cas-sec.contoso.com no caso de MDB1 depois que a cópia do banco de dados da caixa de correio em MBX-C é ativada (cujo valor ActivationPreference é maior do que 1), os clientes do Outlook com um perfil existente continuarão usando o antigo ponto de extremidade RPC em vez do novo ponto de extremidade RPC, desde que o antigo ponto de extremidade RPC continue disponível (os reparos de perfil corrigirão o problema). Os perfis do Outlook criados após a alteração do valor RPCClientAccessServer usariam o novo ponto de extremidade RPC.

Transferindo caixas de correio intersite do Active Directory

Antes do Exchange 2010, quando você transferia caixas de correio entre servidores, o ponto de extremidade RPC do Outlook era atualizado para que apontasse para o servidor Caixa de Correio (ou uma instância do servidor Caixa de Correio em cluster) que hospedava o banco de dados em que a caixa de correio residia. Depois que a transferência de caixas de correio era concluída, o usuário do cliente do Outlook recebia a mensagem “O administrador do Exchange fez uma alteração que exige que o Outlook seja encerrado e reiniciado”. Depois de reiniciar o Outlook, o cliente era conectado ao novo ponto de extremidade RPC.

Com o Exchange 2010, talvez você tenha percebido que, ao transferir caixas de correio intersite do AD, os usuários não viam essa caixa de diálogo. Além disso, também não tinham o ponto de extremidade RPC atualizado para refletir a matriz de Servidor de Acesso para Cliente RPC associada ao banco de dados da caixa de correio no site do AD em que a caixa de correio residia. Isso ocorre porque o antigo ponto de extremidade RPC não retorna uma resposta ecWrongServer ao cliente. O ponto de extremidade RPC aceita a conexão; portanto, o Outlook ignora a resposta de Descoberta Automática porque tem uma conexão funcional. No caso de o antigo ponto de extremidade RPC ficar inacessível, o Outlook atualizava suas configurações (o Outlook 2003, em contrapartida, não aproveitava e não aproveita a Descoberta Automática). A qualquer momento, era possível forçar o Outlook a usar o novo ponto de extremidade RPC com um reparo de perfil.

Agora sim tenho certeza de que você entende a imagem do gatinho anterior.

O futuro… SP2 RU3 e versões posteriores

Eu nunca perdi as esperanças em abordar esses problemas. Alguns de nós ficaram feridos, mas a equipe de desenvolvimento do Acesso para Cliente RPC, a Equipe de Manutenção do Exchange e eu trabalhamos incansavelmente para fazer as duas alterações necessárias no produto. A primeira foi corrigir o perfil do Outlook quando uma caixa de correio simplesmente é transferida entre bancos de dados em diferentes sites do AD, enquanto a segunda alteração foi quando um banco de dados intersite executou failover/switchover dos resultados no Outlook usando um CAS que não é a escolha mais adequada para o local do banco de dados ativado no momento.

Transferências de caixas de correio

Por padrão, depois da instalação do SP2 RU3, quando você transfere caixas de correio intersite do AD, todas as versões do Outlook precisam ser reiniciadas e o ponto de extremidade RPC do perfil do Outlook é atualizado.

Se você examinar os logs do Acesso para Cliente RPC na matriz de Acesso para Cliente RPC de origem, verá:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Observe que a ROP (Operação RPC) é WrongServer (também conhecido como ecWrongServer). Isso força o cliente do Outlook a fazer uma descoberta de perfil e atualizá-lo com base nas novas informações encontradas no diretório. O perfil é atualizado e depois que o cliente é reiniciado, o cliente estabelece suas conexões com o novo ponto de extremidade RPC.

E, como já sei que farão esta pergunta: Quais outras condições garantirão a exibição da caixa de diálogo “O administrador do Exchange fez uma alteração que exige que o Outlook seja encerrado e reiniciado”?

1. Quando você especifica a propridade DoNotPreserveMailboxSignature em New-MoveRequest.
2. Quando os bancos de dados da caixa de correio de origem e de destino têm um armazenamento de hierarquia de pastas públicas diferente.
3. Quando você transfere a caixa de correio de uma versão existente do Exchange para o Exchange 2010.

Eventos de failover/switchover do banco de dados intersite

O comportamento dos eventos de failover/switchover do banco de dados intersite dependerá da propriedade do DAG AllowCrossSiteRPCClientAccess.  Se você definir o valor da propriedade AllowCrossSiteRPCClientAccess como $true, o comportamento que descrevi na seção anterior será o padrão - no caso de esse banco de dados ser ativado no datacenter de espera, os usuários continuarão aproveitando a matriz de Acesso para Cliente RPC no site do AD em que o banco de dados da caixa de correio com o menor valor de preferência de ativação reside como ponto de extremidade de conectividade.

Se você definir o valor da propriedade AllowCrossSiteRPCClientAccess como $false (o valor padrão da propriedade é $false), o ponto de extremidade RPC do perfil Outlook será atualizado para ser a matriz de Servidor de Acesso para Cliente RPC que está no mesmo site do AD em que o banco de dados está ativo e montado. Observe que a propriedade RPCClientAccessServer não é atualizada porque isso define o site preferencial.

Figura 4: o banco de dados MDB1 foi ativado no site de espera do Active Directory e o perfil do Outlook foi atualizado automaticamente

Se você examinar os logs de Acesso para Cliente RPC na matriz de Acesso para Cliente RPC de origem, verá:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Assim como no cenário de transferência de caixas de correio, o ROP WrongServer força o cliente do Outlook a fazer uma descoberta de perfil e atualizar o perfil com base nas novas informações encontradas no diretório. O perfil é atualizado e depois que o cliente é reiniciado, o cliente estabelece suas conexões com o novo ponto de extremidade RPC.

Conclusão

E aí está – com o SP2 RU3 (ou posterior) você pode garantir que as caixas de correio entre os sites do AD terão o perfil atualizado corretamente. Além disso, no cenário de failover/switchover do banco de dados intersite, você pode controlar se permitirá conectividade RPC intersite ou forçar o cliente do Outlook a usar a matriz de Servidor de Acesso para Cliente RPC que está no mesmo site do AD do banco de dados ativado e montado (o comportamento padrão). Acho apropriado encerrar assim:

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

Esta é uma postagem de blog traduzida. Consulte o artigo original em RPC Client Access Cross-Site Connectivity Changes

Artigo original publicado em 17 de maio de 2012, quinta-feira

Recentemente, os clientes que usam o OWA (Outlook Web App) têm ressaltado o assunto da acessibilidade de aplicativos Web como sendo de alta prioridade. Uma das causas dessa muvuca em torno do assunto é o padrão criado pelo W3C denominado ARIA (Aplicativos da Internet Ricos Acessíveis). Apesar de o padrão existir já faz algum tempo, o suporte a ARIA na maioria dos navegadores da Web mais comuns foi aprimorado recentemente. Queremos compartilhar nossas ideias sobre o tema e comunicar que o suporte a ARIA está chegando nas versões futuras do OWA!

Acessibilidade é um termo relacionado à maneira como usuários com alguma limitação na visão, mobilidade, audição etc. podem ter acesso a todas as funcionalidades de um aplicativo por meio de uma interface do usuário otimizada para as circunstâncias desse usuário. Por exemplo, muitos usuários cegos interagem com computadores por meio de leitores de tela, que leem o texto da interface do usuário em voz alta. Outro exemplo são usuários com mobilidade reduzida que não conseguem usar um mouse e dependem do reconhecimento por voz para ditar as palavras, além de designs alternativos de teclado que navegam pela interface do usuário somente por entrada pelo teclado.

O Microsoft Office, incluindo o Microsoft Outlook, que é um complemento do OWA, oferece alto nível de suporte a acessibilidade há muitos anos pela tecnologia MSAA (Microsoft Active Accessibility) e mais recentemente pelas estruturas UIA (Automação da Interface do Usuário) na plataforma Windows. Só que a acessibilidade é mais difícil no caso das experiências de email baseado na Web devido à incompatibilidade entre muitas tecnologias de acessibilidade e aos comportamentos dos novos aplicativos Web dinâmicos/complexos. Temos uma dura escolha entre: ficar de fora da maioria dos comportamentos de aplicativos Web dinâmicos e complexos e garantir excelente acessibilidade; ou criar modernos aplicativos Web 2.0 sem total suporte a acessibilidade. Para o OWA 2007 e 2010, essa não era uma escolha que podíamos fazer, por isso nossa solução foi permitir as duas situações. Criamos o OWA Premium, que usa todo o potencial do Web 2.0, e o OWA Light, que é uma interface do usuário bastante acessível criada quase que exclusivamente em HTML 4.0. Quando as pessoas acessam suas caixas de correio do Exchange pela primeira vez com o OWA, precisam informar se gostariam de usar a experiência do OWA otimizada para acessibilidade.

Ao longo dos anos, os recursos de interoperabilidade do leitor de tela e de navegação pelo teclado do OWA Light passaram a oferecer uma solução de acessibilidade única em relação à maioria dos aplicativos Web modernos e apreciada pelas pessoas que dependem dela no dia a dia. Mas os padrões da Web estão evoluindo. As pessoas imaginam se o ARIA está maduro o suficiente para migrarmos de uma solução de dupla interface do usuário e aprimorarmos a acessibilidade do OWA. Depois de testemunharmos a evolução do ARIA e de o testarmos em versões recentes dos navegadores da Web com suporte, a resposta é clara: em breve implementaremos o ARIA nas versões futuras do Outlook Web App.

Kristian Andaker
Gerente de Programas de Grupo da Microsoft
em nome da equipe do OWA

Esta é uma postagem de blog traduzida. Consulte o artigo original em Is ARIA ready to make Web 2.0 accessible? The OWA team says "YES!"

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

Artigo original publicado em 24 de maio de 2012, quinta-feira

Temos o prazer de anunciar que o ExDeploy (Assistente de Implantação do Exchange Server) agora inclui total suporte a lista de verificação para configurar implantações híbridas para organizações com Exchange 2010 SP2.

Esse cenário recém-incluído serve para organizações com Exchange 2010 SP2 interessadas em manter alguns usuários locais e outros hospedados na nuvem pelo Microsoft Office 365 voltado a empresas. Como o cenário do Exchange 2003 lançado em março e o cenário do Exchange 2007 lançado em abril, este cenário do Exchange 2010 também usa assistentes de Configuração Híbrida para simplificar a implantação.

Informações importantes sobre esse novo cenário do Exchange 2010:

• As informações estão disponíveis somente em inglês por enquanto.
• Você precisará adicionar quaisquer outros servidores Exchange 2010 à sua atual organização com Exchange. Os servidores Exchange 2010 locais existentes serão configurados para dar suporte à implantação híbrida.
• Se você tiver configurado anteriormente uma implantação híbrida usando o ExDeploy e o Exchange 2010 SP1 e ainda precisar de orientação, não se preocupe, pois não esquecemos você! Para sua conveniência, as listas de verificação para configurar implantações híbridas com o Exchange 2010 SP1 estão aqui.

As implantações híbridas oferecem às organizações a capacidade de estender para a nuvem a experiência ampla em recursos e o controle administrativo disponíveis em sua organização com Microsoft Exchange local existente. Elas proporcionam a aparência tranquila de uma única organização com Exchange entre uma organização local e uma organização com Exchange Online. Além disso, as implantações híbridas podem servir de etapa intermediária para migrar completamente para uma organização com Exchange Online baseada na nuvem. Essa abordagem é diferente da simples migração do Exchange (“migração absoluta”) e das opções de migração preparada do Exchange atualmente oferecidas pelo Office 365 descrito no artigo sobre visão geral de migração de emails.

Sobre o Assistente de Implantação do Exchange Server

O ExDeploy (Assistente de Implantação do Exchange Server) é uma ferramenta baseada na Internet que ajuda a atualizar para o Exchange 2010 local, configurar uma implantação híbrida entre uma organização local e uma organização com Exchange Online ou migrar para o Exchange Online.

Figura 1: O Assistente de Implantação do Exchange gera instruções personalizadas para ajudá-lo a atualizar para o Exchange 2010 local ou na nuvem

Ele pede para responder a algumas perguntas simples e, com base nas respostas, fornece uma lista de verificação com instruções para implantar ou configurar o Exchange 2010 personalizado para o seu ambiente. Esses ambientes são:

• Instalações ou atualizações do Exchange locais autônomas
• Configurações de implantação híbrida e
• Cenários de implantação do Exchange somente na nuvem.

Além de obter a lista de verificação online, também é possível imprimir as instruções para tarefas individuais e baixar um arquivo PDF da lista de verificação de configuração na íntegra.

Seus comentários são muito importantes para a melhoria contínua dessa ferramenta. Vamos adorar receber seus comentários sobre esse novo cenário e qualquer outra área do Assistente de Implantação. Poste comentários neste blog, na comunidade do Office 365 sobre o fórum de migração e implantação híbrida do Exchange Online ou envie um email para edafdbk@microsoft.com pelo link Comentários (Feedback) localizado no cabeçalho de cada página do Assistente de Implantação.

Equipe do Assistente de Implantação do Exchange

Esta é uma postagem de blog traduzida. Consulte o artigo original em Exchange Server Deployment Assistant Update for Exchange 2010 Hybrid Deployments with Office 365