Fila e A do Exchange Recuperando um servidor de caixas de correio agrupadas, problemas de catálogo de endereços off-line e muito mais

Henrik Walther

QNossa infra-estrutura de mensagens é baseado no Exchange 2007 SP1. Todos os servidores Exchange 2007 SP1 foram instalados no Windows Server 2008. Temos dois datacenters — o data center principal e um backup onde podemos failover deve um desastre alcançar o primário. Em nosso data center principal, todos os servidores de caixa de correio baseiam no (CCR) replicação contínua em cluster para oferecer uma solução de alta disponibilidade local. Para caixa de correio do servidor failovers do data center principal para o datacenter backup, usamos replicação contínua em espera (SCR). Isso significa que todos os com base em CCR em cluster da caixa de correio servidores (CMSs) os datacenters principais também atuam como fontes da SCR. Cada origem SCR tem destinos da SCR correspondentes no data center backup na forma de clusters em espera no qual somente a função passiva de servidor Caixa de correio tem sido instalada

Recentemente fizemos um teste de failover de site entre os dois datacenters e, infelizmente, nós teve um problema quando tentar recuperar os CMSs para os clusters em espera. Ao executar Setup.com com o /RecoverCMS alternar, temos a mensagem de erro mostrada na Figura 1 .

Figura 1 erro de instalação ao recuperar o CMS a um cluster em espera

Eu era se perguntando se você já viu esse erro ao recuperar um CMS para um cluster em espera e, mais importante, se você tem uma resolução para ele.

ASim, eu tinha o misfortune de enfrentando esse problema ao tentar recuperar um CMS a um cluster em espera. Felizmente, isso foi também durante um teste de failover de nível de site. (Eu preciso explicar por que testar as soluções de failover é importante?)

Algo que me fez pensar era que havia testei a mesma configuração várias vezes antes sem problemas. No entanto, todos os testes de recuperação anteriores foram com o Exchange 2007 SP1 instalado no Windows Server 2003 e não o Windows Server 2008 como era o caso quando eu atinge esse problema.

Isso levou-me para descobrir como trabalho em comparação comparado clusters baseado no Windows Server 2003 de clusters de failover do Windows Server 2008. No Windows Server 2003, você criou e dedicado a uma conta de serviço cluster ao cluster. No Windows Server 2008, você não fazer isso; em vez disso, o cluster de failover é executado sob o "sistema local". Após examinando o aplicativo e sistema logon o cluster em espera no qual eu tentei recuperar o CMS, encontrei o erro mostrado na Figura 2 .

A Figura 2 erro de recuperação devido a permissões inadequadas

Esse erro de identificação de evento explica se o cluster de failover do Windows não tem as permissões necessárias para atualizar a conta de computador CMS no Active Directory. Ele também lista três motivos possíveis. Desde que está recuperando um CMS existente em um cluster em espera, pode ignorar primeiro. Desde que ainda não tiver atingido todas as cotas para o número de objetos de computador, pode ignorar número dois bem. O último item, no entanto, é muito interessante. Ele informa a nós para verificar se o cluster de failover do Windows na qual é recuperar o CMS possui permissões de "controle total" para o objeto de conta de computador do CMS.

Uma olhada na guia Segurança na página de propriedades do objeto de computador CMS no Active Directory Users and Computers revela que o cluster em espera não tem permissões de "controle total" (Figura 3).

A Figura 3 O cluster em espera não têm permissões “ Controle total ”

Adicionando o cluster em espera com permissões de controle total ao objeto de computador CMS resolvido o problema para mim e ele deve fazer o mesmo em seu ambiente.

No momento da elaboração deste documento (a fim de fevereiro), não há nenhum informações sobre esse problema em locais públicos como TechNet ou em qualquer artigos da base de dados de conhecimento. No entanto, meu bom amigo Tim McMichael dos serviços de suporte de cliente do Microsoft tenha escrito uma postagem de blog sobre esse tópico que vai em muito mais detalhes do que consigo fazer aqui. Portanto, por favor vá check-out do Tim blog para obter mais informações " Permissões recomendadas para o CNO (objeto de nome de cluster) no Windows 2008 para operações de instalação do Exchange 2007 SP1.").

QEstamos no momento no processo de criar uma solução de failover do nível do site. Infra-nossa Exchange 2007 SP1 mensagens estrutura, vamos usar a replicação contínua em espera (SCR) como a solução de recuperação de desastres entre nosso datacenter primário e de backup. Desde que apenas alguns dos nossos usuários finais foram atualizados para o Office Outlook 2007 com o restante continua no Outlook 2003, temos uma pergunta. Quando ocorre um failover dos servidores Exchange 2007 SP1 do data center principal para o datacenter backup, será a ambas as versões do Outlook retiradas apenas as alterações após executar as etapas de failover de site da SCR necessárias?

AMuito boa pergunta e, na verdade, a resposta depende se você estiver usando portabilidade RecoverCMS ou banco de dados para failover os servidores de caixa de correio para o datacenter backup. Se você tiver servidores de caixa de correio de autônomos no data center principal e replica esses servidores de caixa de correio autônomos no data center backup usando a SCR, então você usaria a portabilidade do banco de dados para o failover a Mailbo x bancos de dados. Se você tiver cluster de cópia única (SCC) ou servidores de caixa de correio de CCR no seu data center de backup principal e os clusters em espera em seu datacenter backup, você usaria a opção RecoverCMS para recuperar o CMS inteiro para o datacenter backup. Ao usar RecoverCMS como o mecanismo de failover, você normalmente não precisará se preocupar sobre conectividade do cliente Outlook após o failover. Tenha em mente que o endereço IP do CMS será alterada. Mas se você tiver configurado o tempo de DNS Live valor de vida (TTL) para cinco minutos de acordo com a práticas recomendadas, observe que haverá um ligeiro atraso antes que os clientes Outlook possam se reconectar ao CMS.

Se você estiver usando a portabilidade do banco de dados como o mecanismo de recuperação, a situação é um pouco diferente, dependendo da versão de cliente do Outlook. Os clientes do Outlook 2007 refletirá as alterações automaticamente por meio do serviço de descoberta automática compatível com os servidores de acesso para cliente. Isso significa que você não precisa fazer alterações manuais para esta versão do Outlook. Entretanto, essa não é necessariamente o caso com os clientes do Outlook 2003. Quando uma caixa de correio foi recuperada em outro servidor, o nome do servidor armazenando os bancos de dados da caixa de correio obviamente será diferente.

Talvez você esteja se perguntando, esta questão ao usar o cmdlet Move-Mailbox com o –ConfigurationOnly alternar após o failover? Sim, ele ainda importa porque Outlook 2003 não suporta o serviço de descoberta automática. Isso significa que o servidor original em que as caixas de correio foram armazenadas antes do failover deve estar online para que o nome do servidor no perfil MAPI do Outlook pode ser atualizado. Se o servidor original estiver offline, o nome do servidor não pode ser atualizado automaticamente.

Portanto, se você está enfrentando um desastre em todos os servidores do seu data center principal estiver offline, será necessário reconfigurar os perfis MAPI do Outlook 2003 usando uma ferramenta como o Microsoft Exchange Server perfil redirecionador (ExProfre) em combinação com um script de logon para refletir as alterações. Vale a pena observar que se todos os seus clientes foram localizados no data center principal, você precisará recriá-los mesmo assim.

QNo infra-nossa Exchange 2007 SP1 estrutura de mensagens, todos os nossos servidores de caixa de correio são (CCR) replicação contínua em cluster - ativado. Nós instalou quatro placas de interface de rede (NICs) em cada nó de cluster. Duas NICs tiverem sido agrupadas e estão conectados à rede pública, que aceita as solicitações de cliente do Outlook e assim por diante. A terceira NIC é usada para a rede de pulsação entre os nós de cluster de dois na CCR. A quarta NIC existe é especificamente para fins de envio de log. Usando o cmdlet de Enable-ContinuousReplicationHostName introduzido no Exchange 2007 SP1, é ter (para obter redundância de envio de log) especificado que tanto a pulsação a rede de envio de log dedicado podem ser usados para remeter os arquivos de log do ativo para o nó passivo. Isso funciona muito bem e, na verdade, reduz o tráfego na rede pública, especialmente em situações onde uma nova propagação de um ou mais bancos de dados da caixa de correio são necessários (embora isso deve ser muito raro).

Também temos a SCR habilitada entre esses servidores de caixa de correio com a CCR e vários destinos da SCR em nosso datacenter backup. Isso leva à nossa pergunta. É possível usar o cmdlet Enable-ContinuousReplicationHostName com a SCR?

AEstou contente por ter que o cmdlet EnableContinuousReplicationName foi útil para você. No entanto, desde que esse cmdlet foi especificamente criado para soluções CCR, a resposta à sua pergunta é, infelizmente, não, no momento não há suporte para isso em uma solução da SCR.

QNós ter há uma transição apenas do Exchange 2003 para o Exchange 2007 SP1. Todas as funções de servidor do Exchange 2007 SP1 estão executando no Windows Server 2008 e nossos servidores de caixa de correio do Exchange 2007 se baseiam em CCR.

Coisas funcionam muito bem até o momento mas nós ter observado um problema com o off-line catálogo de endereços (OAB). Quando ele é atualizado com novos objetos de email, as atualizações não são refletidas no Outlook 2007 em que os usuários finais. Nós ter sido solucionar o problema e descobriu 1021 de identificação de evento no log do aplicativo em servidores de acesso a cliente com a seguinte descrição:

Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location> 
This is normal if the directory has never been generated. Otherwise, make sure this directory
and share has read permission for the "Exchange Servers" group.

Nós tentou copiar o OAB manualmente do servidor de caixa de correio com CCR onde ele está hospedado para o servidor acesso para cliente. Isso resulta em atualizações no Outlook, mas gostaríamos de obter o problema corrigido permanentemente. Você tem a receita?

AEu estive abaixo dessa viagem, muito. O motivo para esse problema é devido à maneira como se comportam Windows clusters de failover de 2008. Clusters de failover do Windows 2008 apresenta um novo conceito chamado escopo compartilhado. Basicamente, compartilhada escopo significa que um compartilhamento de arquivo é específico ao nome do nó ou a uma do cluster nomear objetos que os hosts de compartilhamento. Quando um compartilhamento é compartilhado pelo nome do nó, ele não pode ser acessado pelo nome do servidor de caixa de correio em cluster (CMS). Para obter detalhes mais geeky sobre o escopo de compartilhamento de arquivo, consulte esta postagem em fazer o blog da equipe principal " Arquivo compartilhamento 'Escopo' clusters de failover do Windows Server 2008").

Para resolver o problema, você precisará instalar o Exchange 2007 SP1 Rollup Update 5 ou posterior, que inclui a correção de bug necessária. Também consulte o artigo" CAS do Exchange 2007 não é possível copiar o OAB do compartilhamento OAB em clusters do Windows Server 2008 Exchange 2007 CCR." Como este Update Rollup traz alguns regressões com ele, é importante que você leia o artigo 5 de Update Rollup KB perto antes de usar essa solução.

Henrik Walther é um Microsoft Certified mestre: o Exchange 2007 e MVP do Exchange com mais de 15 anos de experiência no negócio IT. Ele trabalha como arquiteto de tecnologia para Trifork infra-estrutura Consulting (um parceiro Microsoft Gold com base na Dinamarca) e como redatora técnica da Biblioso Corporation (uma empresa de US com base em especializada em serviços de documentação e localização gerenciados).