Perguntas e respostas sobre o Exchange: Enigmas da configuração

Replicação, configuração e migração continuarão mentes dos administradores do Exchange.

Henrik Walther

Rotas de replicação

P: no momento, estamos esteja implantando uma infra-estrutura de mensagens do Exchange 2010. Estamos planejando nossa migração ainda este ano. Podemos estiver configurando os servidores de caixa de correio em um grupo de disponibilidade do banco de dados grande (DAG). Os servidores membro de DAG se espalham por vários sites do Active Directory e sub-redes. Cada servidor de membro DAG terá duas interfaces de rede — um para MAPI (Messaging Application Programming Interface) e outro para replicação.

Durante os testes em nosso ambiente de laboratório, notamos replicação sempre acontece através da rede MAPI. Configuramos as rotas estáticas para a rede de replicação pelas instruções em uma das suas respostas anteriores do Exchange & Um colunas. Você tem qualquer idéia que poderia causar isso?

R: mencionar que você tem servidores membros de DAG de diferentes sites do Active Directory e sub-redes. Isso significa que uma rede DAG será criada para cada rede/sub-rede da interface mantendo DAG servidores membro (consulte a Figura 1).

There are multiple networks for each DAG member server

Figura 1 há várias redes para cada servidor de membro DAG.

A princípio, isso parece certa, mas há um problema oculto. Isso fará com que todo o tráfego de replicação em execução na rede de MAPI. Para resolver esse problema, você deve recolher as redes DAG. Se você tiver um servidor membro de DAG localizado em dois sites do Active Directory, por exemplo, e cada servidor tem duas interfaces de rede, como mostrado na a Figura 1, você precisaria colapsada dois as quatro redes DAG (consulte Figura 2). Ao mesmo tempo, seria uma boa idéia renomear a rede de DAG adequadamente.

Collapse the DAG networks into smaller groups to resolve traffic routing issues

Figura 2 redes de recolher o DAG em grupos menores para resolver problemas de roteamento tráfego.

Memória dinâmica

P: somos uma loja de médio porte que executam o Exchange 2010. Todos os servidores Exchange 2010 são virtuais, executando em uma infra-estrutura de virtualização baseadas em Hyper-V. Recentemente, atualizamos os servidores raiz do Hyper-V para Windows Server 2008 R2 SP1. Como você provavelmente sabe, um dos novos recursos do Hyper-V-específico neste service pack é a memória dinâmica. Isso ajuda a usar a memória física com mais eficiência.

Você sabe se ele tem/suportado ou recomendável para ativar a memória dinâmica em servidores baseados no Hyper-V 2010 do Exchange para usar os recursos de memória no servidor da raiz do Hyper-V com mais eficiência?

R: Infelizmente, a posição de apoio ainda é o mesmo: não tem suporte (para seleção aqui para obter mais detalhes). Mesmo que eram suportados, ele realmente não faz muito sentido para um aplicativo como o Exchange.

Memória dinâmica faz sentido aplicativos projetados para cargas de trabalho onde a memória é necessária por breves períodos de tempo. Exchange Server foi projetado para usar a memória de forma contínua. Por exemplo, o processo Store. exe em um servidor Exchange 2010 com a função de servidor caixa de correio instalada alocará a maioria da memória disponível (para o cache do banco de dados) no servidor físico ou virtual.

A lógica por trás disso é ser capaz de oferecer melhor desempenho para o usuário, enquanto ainda colocando os bancos de dados no armazenamento relativamente lento, como discos de rotação de 7200 SATA em uma configuração JBOD. Mesmo se os bancos de dados foram colocados em discos super-rápido, o desempenho nunca seria tão boa quanto quando dados são lidos diretamente no espaço de endereço virtual. Você sempre deseja estar lendo tantos dados quanto possível diretamente do cache do banco de dados, em vez do subsistema de armazenamento subjacente.

Quando se trata de outras funções do servidor Exchange (acesso para cliente, transporte de Hub e transporte de borda), memória dinâmica ainda não faz muito sentido devido dos que Exchange foi projetado para usar a memória. Uma observação mais: virtualizar a Unificação de mensagens a função de servidor não é suportado qualquer um.

A consolidação de florestas

P: estamos no processo de consolidação de várias florestas do Active Directory com o Exchange 2003 para uma nova floresta do Active Directory com Exchange 2010. A abordagem de migração que adotamos é usar primeiro o script de MoveRequest.ps1 de preparação para preparar as caixas de correio de origem para uma movimentação entre florestas. Usamos o parâmetro "linkedmailuser" para criar um objeto vinculado do MailUser na floresta de destino.

Em seguida, mova a caixa de correio e tê-lo configurado como uma caixa de correio vinculada, portanto, o usuário pode fazer logon na caixa de correio do Exchange 2010 usando sua conta de usuário do Active Directory da floresta de origem até que sua conta de usuário do Active Directory é migrada para a floresta de destino. Devido essa abordagem de migração, às vezes, precisamos converter uma caixa de correio em uma caixa de correio vinculada e converter uma caixa de correio vinculada em uma caixa de correio desvinculada.

Estamos cientes das etapas a Documentação do Exchange 2010 no TechNet que explicam como converter uma caixa de correio em uma caixa de correio vinculada, mas não é uma abordagem muito elegante. Desabilitar a caixa de correio e conectar-se a um usuário na floresta de origem respectivos. Essa abordagem remove todos os atributos do Exchange e deixa a caixa de correio desabilitada por um período de tempo. Você sabe de uma forma mais elegante de fazer isso?

R: Exchange se tornou um grande produto, para que o repositório de documentação é bastante extenso. Há uma equipe de gravador Exchange apaixonada e dedicada que desenvolve o novo conteúdo e mantém o conteúdo existente atualizado, mas alguns tópicos são esquecidos — que é o que aconteceu quando se trata de conversão de caixas de correio do usuário para caixas de correio vinculadas e vice-versa. Com o Exchange 2007 SP1, o Os desenvolvedores do Exchange melhorou o cmdlet Set-usuário, para que ele possa cuidar das situações em que uma caixa de correio do usuário precisa ser convertido em uma caixa de correio vinculada e vice-versa.

Se você desejar converter um UserMailbox em um objeto LinkedMailbox, você pode usar o seguinte comando:

Set-User - identidade <mailbox> -LinkedDomainController < controlador de domínio na floresta de conta > LinkedCredential-$(Get-Credential < conta de administrador de domínio na floresta de conta >) - LinkedMasterAccount < conta de usuário na floresta de conta >

Isso adiciona o atributo msExchMasterAccountSid à conta na floresta de destino e altera o tipo de destinatário e outros detalhes, conforme apropriado. Para converter um objeto LinkedMailbox em um objeto UserMailbox, use o seguinte comando:

Set-User - identidade <linkedMailbox> LinkedMasterAccount-$null.

Isso irá converter o tipo de destinatário para um UserMailbox e limpa o msExchMasterAccountSidattribute conforme apropriado. Observação: Você deve ativar a conta do Active Directory manualmente. O comando de usuário de conjunto fornecido aqui não faz isso para você. Graças ao William Rall da equipe do Exchange, de quem eu aprendi esse truque originalmente.

Suporte à autenticação do ADFS

P: apenas atualizamos nossa infra-estrutura de mensagens do Exchange 2003 para Exchange 2010. Também estamos no processo de implementação de single sign-on (SSO) por meio da autenticação baseada em declarações entregue pelos serviços de Federação do Active Directory (AD FS). Eu estava me perguntando se você sabe se o AD FS-based authentication é suportado pelo Exchange 2010 ou se ela será suportada em uma versão futura?

R: no momento, o OWA (Outlook Web App) 2010 podem se beneficiar da autenticação baseada em declarações (e o protocolo WS-Federation) por meio do AD FS 2.0. Tempo essa pergunta muito bem, porque a Microsoft França publicou recentemente um ótimo passo a passo do white paper o que orienta o processo de configuração 2010 do OWA para utilizar autenticação baseada em declarações.

Henrik Walther

Henrik Walther é um Microsoft Certified Master: Exchange 2007 e MVP em Exchange com mais de 15 anos de experiência em negócios de TI. Ele trabalha como arquiteto de tecnologia TimengoConsulting (um Microsoft Gold Certified Partner na Dinamarca) e como redator técnico da Biblioso Corp. (uma empresa nos EUA especializada em gerenciado documentação e serviços de localização). Você pode enviar um e-mail Walther em v-henwal@Microsoft.com.

Conteúdo relacionado