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):
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.
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.
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.
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.
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.
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.
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.
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”?
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
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.
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 05 de junho de 2012, terça-feira
Se você acha um mistério o funcionamento interno dos backups de dados do Exchange ao usar a VSS (Cópia de Sombra de Volume), não se preocupe, pois você não é o único. Os administradores podem imaginar: “O que são estas “congeladas” e “descongeladas” que percebo em meus logs de eventos? O que é realmente o Gravador VSS do Exchange e o que ele faz com meus bancos de dados? Como ele cria um instantâneo de um banco de dados com 135GB em menos de 60 segundos?”
Se você alguma vez teve essas indagações, mas só ficou mais confuso com as respostas, a seguir está um guia para esclarecer algumas delas. Para entender como funciona um backup de VSS do Exchange, é essencial entender os fundamentos básicos do próprio VSS. Há uma excelente documentação sobre o assunto disponível no TechNet e MSDN, além do blog do Windows Server Core Team intitulado “Ask the Core Team”. Meu estimado colega Randy Monteleone resume muito bem os fundamentos básicos do VSS no início de sua postagem, além de fornecer links (repetidos aqui) para alguns ótimos textos didáticos do TechNet sobre o VSS:
Instruções: rastreamento do VSS – Randy Monteleone http://blogs.technet.com/b/askcore/archive/2012/04/29/how-to-vss-tracing.aspx
Como funciona o Serviço de Cópias de Sombra de Volume http://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx
Serviço de Cópias de Sombra de Volume http://technet.microsoft.com/en-us/library/ee923636.aspx
Se você já tem familiaridade com pelo menos os fundamentos básicos do VSS, avance para a Parte 2 desta série, em que esmiuçaremos os eventos que ocorrem em um backup do VSS Exchange e como o Exchange os registra no log de eventos de aplicativo.
Se você precisar de um breve texto didático ou mnemônico sobre os fundamentos básicos do VSS e do Exchange Writer, eu os condensei em alguns recursos visuais a seguir para complementar as referências anteriores.
Lembre-se de que as soluções de VSS para o Exchange, e para todos os aplicativos, variam bastante entre diferentes configurações de hardware e software. Há instantâneos clonados e COW (cópia na gravação), soluções de hardware e software, simplesmente uma ampla variedade de tecnologias que se baseiam no subsistema principal do VSS. Para a finalidade de entender os backups do Exchange, vamos ilustrar somente um tipo específico de solução dentre várias. A seguir detalhei o que se chama de instantâneo de “cópia na gravação” ou “COW”.
Em um backup de VSS do Exchange baseado em instantâneo COW, temos a criação de instantâneos dos discos em que os dados do Exchange são hospedados. Independentemente do conteúdo submetido a backup, mesmo se for um único arquivo de banco de dados e alguns logs, o VSS criará um instantâneo do disco inteiro em que os dados estão armazenados. Se os dados residirem em vários discos, por exemplo quando um banco de dados do Exchange está em um disco, e os logs estão em outro, o VSS criará instantâneos de todos os discos.
Então o que é um “instantâneo”? Um instantâneo de volume é uma área de espaço dentro do que é chamado “armazenamento de sombra”, que é uma área geralmente pequena do espaço no disco localizada em sua pasta de Informações de Volume do Sistema.
Depois que um instantâneo do disco é criado, qualquer alteração feita em qualquer bloco de dados a partir desse momento não pode ser gravada enquanto uma cópia dos dados desse bloco antes da alteração (como eles estavam quando o instantâneo foi criado) não for gravada na área diferenciadora no armazenamento de sombra. Dessa maneira, os dados no disco no momento em que o instantâneo foi criado ficam preservados, bloco por bloco, na área de armazenamento de sombra. Os dados do instantâneo ficam então disponíveis no disco original, se os blocos de dados solicitados não tiverem sido alterados, ou na área diferenciadora se tiverem sido alterados. Os fundamentos disso estão ilustrados a seguir:
O disco E: tem um instantâneo criado às 13h00:
Um minuto mais tarde um dos blocos é gravado, mas não antes de os dados conforme estavam às 13h00 serem preservados na área diferenciadora:
À medida que o disco real é alterado, os dados conforme estavam às 13h00 são gravados no armazenamento de sombra, preservando um registro do disco conforme estava naquele momento:
A etapa seguinte:
Na figura anterior, um servidor de backup solicita dados do instantâneo dos blocos 2 e 53. O bloco 53 das 13h00 é preservado no instantâneo, por isso é copiado diretamente do armazenamento de sombra. O bloco 2 não tem alterações desde as 13h00, por isso é copiado pelo driver de VSS VOLSNAP.SYS, que opera de maneira muito semelhante a um driver de filtro subjacente ao driver do sistema de arquivos NTFS.SYS. Trabalhando na pilha IRP (a parte da memória do kernel que gerencia o E/S de disco) subjacente ao sistema de arquivos, ele pode ler blocos de dados sem que o NTFS conteste que um arquivo está sendo usado. VOLSNAP.SYS também é responsável por garantir que os blocos sejam copiados para um armazenamento de sombra se uma gravação é solicitada a eles, daí o termo “Cópia na Gravação”. A seguir estão mais informações sobre VOLSNAP.SYS de Tim McMichael:
Exchange / VSS / e tamanho do bloco diferencial… http://blogs.technet.com/b/timmcmic/archive/2011/07/12/exchange-vss-and-differential-block-size.aspx
Agora que temos os fundamentos básicos de um instantâneo COW, vamos analisar como ele funciona com o Exchange e alguns outros conceitos importantes:
Pois bem. Sabemos que o VSS cria um instantâneo dos dados do Exchange armazenados em um disco. Como exatamente um aplicativo de backup descobre quais são os discos? Geralmente um administrador escolhe os bancos de dados para backup sem especificar nada sobre quais discos contêm os arquivos de dados. Assim é necessário usar alguma técnica para fornecer as informações sobre onde estão os arquivos de dados e então de quais discos o VSS precisa criar instantâneos. Essas informações também dizem a um aplicativo de backup, também conhecido como solicitante de VSS, quais arquivos de dados específicos devem ser copiados desses instantâneos para fins de preservação em mídia de backup, porque não queremos copiar nada do disco que seja desnecessário.
O mecanismo em ação aqui é o Gravador de VSS do Microsoft Exchange. Como o gravador de VSS de qualquer aplicativo (existem muitos, por isso basta executar VSSADMIN LIST WRITERS para vê-los), sua primeira missão é informar ao aplicativo de backup sobre os dados necessários para backup, principalmente o arquivo EDB, os logs e o arquivo de ponto de verificação para cada banco de dados solicitado. As informações sobre esses arquivos de dados específicos do Exchange são conhecidas como metadados de gravador.
(clique na miniatura para obter uma versão em tamanho inteiro)
Na figura anterior, vemos as etapas iniciais de um backup do Exchange. O Exchange Writer informa ao servidor de backup (o solicitante) que há um banco de dados localizado em uma pasta no volume E: e que os logs de transação desse banco de dados estão em uma pasta no volume D:. Com base nessas informações, o aplicativo de backup solicitará instantâneos dos volumes D: e E: quando o trabalho avançar.
O Gravador de VSS do Exchange serve outra função crucial além de fornecer metadados aos solicitantes de VSS. Ele também tem a função de interromper as gravações nos bancos de dados e os logs em disco ou “congelá-los” durante o tempo necessário para criar os instantâneos. Um instantâneo COW normalmente leva pouco tempo para ser criado, porque ele inicialmente consiste apenas em designar uma área no armazenamento de sombra na qual os blocos serão preservados quando forem alterados no disco real. Apesar de essa operação ser relativamente rápida, ela pode levar até um minuto, o que é bastante tempo para que os blocos de dados sejam alterados em um disco entre o início e o final do processo de criação do instantâneo. Se os blocos de dados forem alterados, mas não tiverem o estado original preservado a partir do momento exato em que a criação do instantâneo começou, esses blocos poderão ficar irregulares em comparação com outros dados do instantâneo, principalmente entre logs, arquivos de banco de dados e arquivos de ponto de verificação. Por isso, o Exchange Writer impede que o Serviço de Armazenamento de Informações ou o Serviço de Replicação do Microsoft Exchange, grave o conteúdo da RAM nos arquivos de banco de dados congelados. No caso do Serviço de Armazenamento de Informações, o arquivo de log de transações (Exx.log) atual é implementado e fechado antes que o Exchange Writer permita que o VSS obtenha o instantâneo. Isso garante que nada seja alterado nos dados dos arquivos entre o início de um instantâneo e a conclusão, momento em que os bancos de dados são “descongelados”. Quando os bancos de dados são descongelados, o E/S de gravação retido na RAM recebe permissão para acessar o disco novamente.
A seguir estão mais informações sobre como o gravador de VSS de um aplicativo interage com o VSS em relação a congelamento, descongelamento e o tempo necessário para que um instantâneo seja concluído:
Método CVssWriter::OnFreeze http://msdn.microsoft.com/en-us/library/windows/desktop/aa381563(v=vs.85).aspx
A última responsabilidade crucial do Exchange Writer é informar ao Serviço de Armazenamento de Informações (Serviço de Replicação do Microsoft Exchange no caso de um backup de cópia passiva) que o backup foi concluído e, se aplicável, executar tarefas de pós-backup como truncamento de logs, marcação do banco de dados com o status de que não há mais backups em andamento etc.
Nas partes dois e três desta série, analisaremos uma divisão detalhada de como os elementos descritos anteriormente são combinados em um backup do Exchange, os eventos de log de aplicativo que são gerados, e compararemos o processo de um banco de dados montado com aquele de uma cópia de banco de dados passiva.
Um obrigado pela colaboração no conteúdo destas postagens vai para Michael Blanton, Tim McMichael, Randy Monteleone, Dave Vespa e Tom Kern.
Jesse Tedoff
Esta é uma postagem de blog traduzida. Consulte o artigo original em Everything You Need to Know About Exchange Backups* - Part 1
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 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.
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.
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:
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
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:
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
Temos o prazer de anunciar que lançamos a versão mais recente do pacote de idiomas do Exchange 2010 e que ele está disponível para download aqui.
Esse pacote de idiomas resolve três principais problemas que alguns clientes tinham:
Observe que o Exchange 2010 Service Pack 2 inclui o pacote de idiomas completo, e se você não está tendo problemas ou não instalou nenhum pacote de idiomas depois do SP2, não é necessário aplicar esse pacote de idiomas.
Equipe de Atendimento ao Cliente do Exchange
Esta é uma postagem de blog traduzida. Consulte o artigo original em Exchange 2010 Service Pack 2 Language Pack Available for Download
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 AndakerGerente de Programas de Grupo da Microsoftem 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.
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 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:
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:
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.
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:
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:
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 ProgramaExperiê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 06 de junho de 2012, quarta-feira
O evento TechEd América do Norte 2012 está chegando e os profissionais da equipe do Exchange estarão lá para falar sobre implantações híbridas do Exchange e migrações do Exchange Online! Recebemos um monte de dúvidas sobre implantações híbridas, principalmente após o lançamento do Exchange 2010 SP2 com o Assistente de Configuração Híbrida e a atualização do Assistente de Implantação do Exchange com mais instruções simplificadas para implantação híbrida. A seguir estão algumas respostas:
Recentemente Ben Appleby e eu criamos uma série de três podcasts em vídeo da Rádio TechNet para esclarecer um pouco mais a questão das implantações híbridas como parte da série "Road to TechEd 2012". Esses podcasts devem ajudar a dar algumas ideias sobre nossas sessões híbridas do TechEd se você estiver participando do evento, mas também oferecem orientações e informações concretas se você não pretende participar neste ano.
O segundo podcast é sobre o funcionamento do mecanismo de configuração híbrida no Exchange Server para dar uma ideia do que o Assistente de Configuração Híbrida realmente faz depois que você clica em 'atualizar' e dispara o cmdlet Update-HybridConfiguration para iniciar o mecanismo de configuração híbrida. Vamos tratar desse assunto com mais profundidade durante o evento TechEd 2012, além de oferecer uma demonstração do assistente atualizado.
O último podcast contém perguntas frequentes e armadilhas comuns com uma implantação híbrida do Exchange que tratam de assuntos muito importantes. Nesse episódio, Ben menciona o white paper do guia de desempenho de migração do Exchange Online, que é um ótimo ponto de referência. Ou se você às vezes é descuidado em ler a documentação atentamente (como eu, hehe!), é altamente recomendável conferir o artigo sobre entendimento dos requisitos de certificado para implantações híbridas no TechNet.
Espero que esses podcasts deem uma pincelada sobre alguns dos tipos de conteúdo surpreendentes que estão chegando no evento TechEd 2012 deste mês, além de pontos de referência que aprofundam alguns temas de implantação híbrida cruciais.
A seguir estão as sessões de migração e implantação híbrida do TechEd que você deve conferir:
Também participaremos do evento MEC e estaremos empolgados em falar sobre esses assuntos ainda este ano. Então, se você ainda não se cadastrou e quer bater um papo conosco sobre implantação híbrida, migração e Exchange 15, cadastre-se já!
Ann Vu
Esta é uma postagem de blog traduzida. Consulte o artigo original em Check Out Some TechNet Radio Podcasts on Hybrid Deployments