Fila do Exchange &A: Adotando os DAGs

  • Artigo

Usando grupos de disponibilidade do banco de dados é uma ótima idéia, especialmente porque você pode copiar e armazená-los em vários locais — mas se incomoda com os problemas de endereçamento.

Henrik Walther

Endereçamento Conundrum

P: Nós implantou o Exchange 2010 e todos os servidores de caixa de correio altamente disponíveis usando grupos de disponibilidade do banco de dados (DAGs). As coisas estão em bom estado e tudo o que funciona como esperado, exceto um detalhe secundário.

Quando uma pessoa que recebe uma mensagem enviada por um funcionário com uma caixa de correio hospedada em um DAG, por sua vez envia outra mensagem para um funcionário ou um destinatário no cabeçalho da mensagem de Internet do que o servidor de caixa de correio foi configurado usando um endereço APIPA, como 169.254.5.133 de mostra a mensagem recebida de outra organização. Podemos usar endereços IP estáticos para todos os nossos servidores do Exchange 2010, portanto, não sabemos por que ele aparece como um endereço APIPA (consulte do Figura 1). Você pode esclarecer nos?

R: Esta é uma questão interessante. A resposta muito curta é que ele ocorre somente quando os servidores de caixa de correio do Exchange 2010 foram disponibilizados altamente usando um ou mais DAGs e a funcionalidade de DAG baseia-se no componente de cluster de Failover do Windows (WFC). Você não vir esse comportamento com servidores de caixa de correio que não fazem parte de um DAG.

Let’s dê uma olhada mais detalhada o que está acontecendo aqui. O componente WFC no Windows Server 2008 R2 espera que aplicativos que usam WFC — como, por exemplo, SQL, Exchange e servidores de arquivos — para localizar recursos de cluster de uma maneira específica. O aplicativo deve se conectar a um recurso de cluster, localizando as informações apropriadas usando um servidor DNS.

Isso é conhecido como um ponto de acesso do cliente (CAP). Um CAP consiste em um nome NetBIOS e um ou mais recursos de endereço IP. No Windows Server 2008 R2, se o servidor ofereça suporte a atualizações dinâmicas, as informações do CAP estão registradas no DNS depois que o CAP for colocado online na WFC.

Infelizmente, existem aplicativos que ignore a etapa DNS e em vez disso, se conectar diretamente a um nó de cluster usando o primeiro adaptador de rede na lista de ligações. Por padrão, o primeiro adaptador de rede listado na lista de ligação é adaptador virtual do cluster de Failover Microsoft (consulte do Figura 2). Esse adaptador é configurado com um endereço APIPA.

Figure 1 An APIPA address in an Internet header

Figura 1 de APIPA um endereço em um cabeçalho de Internet

Figure 2 The Microsoft Failover Cluster Virtual Adapter

Do Cluster de Failover O Microsoft adaptador virtual, a Figura 2

Portanto, adivinhe qual aplicativo não usa o DNS para localizar e conectar-se um recurso do cluster? Adivinhou-lo: Exchange 2010 (e o Exchange 2007, também).

Como podemos pode corrigir este aborrecimento pouco? Felizmente, isso é fácil com a Ajuda de uma ferramenta pouco conhecida como nvspbind, que pode ser baixado de o MSDN Code Gallery: Code.msdn.microsoft.com/nvspbind. Nvspbind foi desenvolvido especificamente para modificar as ligações de rede de uma linha de comando.

Verifique se a ordem de ligação dos adaptadores do servidor Let’s. Execute nvspbind.exe /o ms_tcpip. Como você pode ver no do Figura 3, Local Area Connection * 9 (que equivale a adaptador virtual do cluster de Failover Microsoft) é listado primeiro.

Figure 3 Viewing a binding order list using nvspbind

A Figura 3 de exibição de uma lista de ordem de ligação usando nvspbind

Em seguida, precisamos mover Local Area Connection * 9 para baixo na lista. Execute o seguinte comando:

nvspbind.exe /- “Local Area Connection* 9” ms_tcpip

Figure 4 Moving Local Area Connection* 9 down the binding order list

Do movimento Local Area Connection * 9 para baixo na lista de ordem de ligação, a Figura 4

Como você pode ver no do Figura 4, Local Area Connection * 9 foi movido para baixo na lista de ordem de ligação. Agora, tente enviar um novo email. O cabeçalho de Internet deve agora mostrar o endereço IP real do servidor (consulte do Figura 5).

Figure 5 An Internet header showing the real IP address of the mailbox server

Do cabeçalho de uma Internet mostrando o endereço IP real do servidor de caixa de correio, a Figura 5

Manuais de cópias

P: Implementamos apenas servidores Exchange 2010. Pretendemos usar DAGs para tornar os nossos bancos de dados de caixa de correio altamente disponível. Estamos planejando para oito cópias de cada banco de dados de caixa de correio. Cada banco de dados de caixa de correio terá cópias em três locais físicos. Vamos nos bancos de dados de aproximadamente 500 GB cada. Por causa da largura de banda limitada a um dos locais físicos, esperamos que um período de tempo de preparação. Dessa forma, em vez disso, estamos perguntando se é possível alguma forma copiar manualmente os arquivos de banco de dados para um local remoto com uma unidade USB?

R: Sim, isso pode ser feito-lo nisso, bem como um método com suporte. Para copiar manualmente um banco de dados off-line, desabilite o log circular para os respectivos bancos de dados. Para fazer isso executando:

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false

Em seguida, desmonte os bancos de dados usando:

Dismount-Database MDB01 -Confirm $false

Em seguida, copie o banco de dados e todos os arquivos de log em um segundo local, como, por exemplo, uma unidade USB.

Quando o processo de cópia for concluído, monte a cópia do banco de dados ativo novamente usando:

Mount-Database MDB01

Agora, conecte o disco USB para o servidor que irá hospedar o banco de dados e copie os arquivos de log e banco de dados para o mesmo caminho usado no servidor de origem do qual os arquivos foram copiados.

Agora, adicione a cópia do banco de dados usando o Add-MailboxDatabaseCopy - parâmetro SeedingPostponed. O comando seria algo parecido com isto:

Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed

Observe que não há nenhum processo de preparação porque o arquivo EDB e arquivos de log associados já estão em vigor. Finalmente, ative registro em log circular novamente usando:

Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true

Bicicleta de estrada GUERREIROS

P: Esteja executando o Exchange 2010 e temos muitos “ estrada itinerantes ” quem são altamente dependentes de aplicativo de Web do Outlook ou o OWA (o que usado deve ser chamado de Outlook Web Access). Esses usuários não podem fazer logon no OWA quando sua senha expirou. Também descobrimos que novos funcionários para os quais a conta foi definida como “ usuário deve alterar a senha no próximo logon ” quando a conta de usuário é criada pela primeira vez (veja do Figura 6), não é possível fazer logon no OWA antes que eles alteram a senha usando outros mecanismos.

Figure 6 User must change password at next logon enabled

Figura 6 de usuário deve alterar a senha no próximo logon habilitado

Nós tenha vivido desse aborrecimento, já que mudamos da Lotus Domino para o Exchange 2003 há muitos anos. Você sabe como é possível corrigir isso?

R: Um bom tempo para esta pergunta. Quando a equipe do Exchange começou a planejar o SP3 do Exchange 2007, bem como o Exchange 2010 SP1, eles decidiram corrigir a falta de poder fazer logon no OWA quando a senha um usuário expirou ou a conta de usuário tiver sido definida para o usuário deve alterar a senha no próximo logon. Eles surgiu com a ferramenta de redefinição de senha do OWA. Este é um módulo do IIS 7 que detecta senhas expiradas e redireciona os usuários para uma página totalmente nova alteração de senha.

Figure 7 The Outlook Web App 2010 forms-based authentication logon page

A Figura 7 do App 2010 do Outlook Web página de logon de autenticação com base em formulários

Let’s ver isso em ação, deverá nós? O usuário tentar fazer logon no OWA 2007 ou 2010 usando a página de logon da autenticação baseada em formulários (FBA), conforme mostrado no do Figura 7. Agora, o usuário é redirecionado para a nova página de alterar a senha mostrada no do Figura 8. Aqui, ele precisará digitar a senha atual, bem como uma nova e, em seguida, clique no botão Enviar.

Figure 8 The Outlook Web App 2010 Change Password page

A Figura 8 do Outlook Web App 2010 página Alterar senha do

Agora, a senha for alterada e o usuário pode fazer logon usando a nova senha. Simples e amigável, certo?

Lembre-se de que a página de alteração de senha não está habilitada por padrão depois de instalar o SP3 do Exchange 2007 SP1 do Exchange 2010. Você precisa ativar isso com uma chave do registro. Mais especificamente, você precisará efetuar logon em cada Exchange 2007 ou o Exchange 2010 cliente servidor de acesso (CAS) e inicie o editor do registro.

Dentro do editor do registro, navegue até: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA. Aqui, você precisará criar uma nova chave REG_DWORD denominada ChangeExpiredPasswordEnabled. Ative isso definindo o valor de dados para a “ 1 ”, conforme mostrado no do Figura 9.

Figure 9 The registry key required to enable Change Password for OWA

A Figura 9 da chave do registro necessária para ativar a alterar a senha para o OWA

Agora seus itinerantes estrada podem fazer logon no OWA, independentemente de sua senha expirou ou precisará ser alterada.

_***Henrik Walther****é um Microsoft Certified Master: O Exchange 2007 e MVP em Exchange com mais de 15 anos experiência na atividade de TI. Ele trabalha como um arquiteto de tecnologia forTimengoConsulting (um Microsoft Gold Certified Partner na Dinamarca) e como redator técnico da Biblioso Corporation(gerenciada por uma empresa com base nos EUA especializada em documentação e serviços de localização). Você pode enviar por email Walther em v-henwal@microsoft.com de . * _

Conteúdo relacionado