Partilhar via

Gerenciar grupos de disponibilidade de banco de dados em Exchange Server

  • Artigo

Um DAG (grupo de disponibilidade de banco de dados) é um conjunto de até 16 servidores da Caixa de Correio do Exchange que fornecem recuperação automática no nível do banco de dados de uma falha de banco de dados/servidor/rede. Os DAGs utilizam replicação contínua e uma sub-rede de tecnologias de cluster de failover do Windows para fornecer alta disponibilidade e resiliência de site. Servidores de caixa de correio em um DAG monitoram-se por falhas. Quando um servidor de caixa de correio é adicionado a um DAG, esse servidor funciona com os outros servidores no DAG para fornecer recuperação automática no nível do banco de dados de falhas de banco de dados.

Quando criado, um DAG está vazio. Quando você adiciona o primeiro servidor a um DAG, um cluster de failover é criado automaticamente para o DAG. Além disso, é iniciada a infraestrutura que monitora os servidores em busca de falhas de rede ou servidor. O mecanismo de pulsação de cluster de failover e o banco de dados de cluster são usados para rastrear e gerenciar informações sobre o DAG que podem ser alteradas rapidamente, como status de montagem de banco de dados, status de replicação e local montado na última.

Criando DAGs

Um DAG pode ser criado usando o assistente Novo Grupo de Disponibilidade de Banco de Dados no Centro de Administração do Exchange (EAC) ou executando o cmdlet New-DatabaseAvailabilityGroup no Shell de Gerenciamento do Exchange. Ao criar um DAG, você fornece um nome para o DAG e configurações opcionais de servidor de testemunha e diretório de testemunhas. Além disso, atribua um ou mais endereços IP ao DAG, usando endereços IP estáticos ou permitindo que os endereços IP necessários sejam atribuídos automaticamente ao DAG, usando o protocolo DHCP. Você pode atribuir manualmente endereços IP ao DAG usando o parâmetro DatabaseAvailabilityGroupIpAddresses . Se você omitir esse parâmetro, o DAG tentará obter um endereço IP usando um servidor DHCP na rede.

Se você estiver criando um DAG que conterá servidores de caixa de correio que estão executando Windows Server 2012 R2, você também terá a opção de criar um DAG sem um ponto de acesso administrativo de cluster. Nesse caso, o cluster não terá um objeto de nome de cluster (CNO) no Active Directory e o grupo de recursos do cluster core não conterá um recurso de nome de rede ou um recurso de endereço IP.

Para obter etapas detalhadas sobre como criar um DAG, consulte Criar um grupo de disponibilidade de banco de dados.

Quando você cria um DAG, um objeto vazio que representa o DAG com o nome especificado e uma classe de objeto do msExchMDBAvailabilityGroup são criados no Active Directory.

Os DAGs usam um subconjunto de tecnologias de failover do Windows clustering no Windows Server 2008 R2 ou posterior, como os batimentos cardíacos de cluster, redes de cluster e banco de dados de cluster (para armazenar dados que mudam ou podem ser alterados rapidamente, como alterações de estado de banco de dados de ativo para passivo ou reverso, ou de montado para desmontado ou reverso). Portanto, você pode criar DAGs somente em servidores do Exchange Mailbox instalados em versões com suporte do Windows que incluem clustering de failover do Windows.

Observação

O cluster de failover criado e usado pelo DAG deve ser dedicado ao DAG. O cluster não pode ser usado por nenhuma outra solução de alta disponibilidade ou para qualquer outra finalidade. Por exemplo, o cluster de failover não pode ser usado para armazenar em cluster outros aplicativos ou serviços. O uso do cluster de failover subjacente do DAG para finalidades que não sejam o DAG não tem suporte.

Servidor testemunha do DAG e diretório testemunha

Ao criar um DAG, você precisa especificar um nome para o DAG não mais do que 15 caracteres exclusivos na floresta do Active Directory. Além disso, cada DAG é configurado com um servidor testemunha e um diretório testemunha. O servidor testemunha e seu diretório são usados somente quando há um número par de membros no DAG e apenas para fins de quorum. Você não precisa criar o diretório testemunha com antecedência. O Exchange cria e protege automaticamente o diretório para você no servidor testemunha. O diretório de testemunhas não deve ser usado para qualquer finalidade que não seja para o servidor de testemunhas DAG.

Observação

Na topologia de espelhamento de banco de dados, você pode ter um terceiro servidor chamado "testemunha". O servidor testemunha habilita o failover automático da entidade para espelho servidor ou vice-versa. Ao contrário dos servidores principal e espelho, o servidor testemunha não serve o banco de dados. A função da testemunha é verificar se um determinado servidor parceiro está funcionando. O suporte ao failover automático é a única função para o servidor testemunha e identifica qual servidor contém a cópia principal e qual servidor contém a cópia espelho do banco de dados.

Os requisitos do servidor de testemunha são os seguintes:

  • O servidor testemunha não pode ser um membro do DAG.

  • O servidor testemunha deve estar na mesma floresta do Active Directory do DAG.

  • O servidor testemunha deve estar executando o Windows Server 2008 ou posterior.

  • Um único servidor pode funcionar como testemunha para vários DAGs. Entretanto, cada DAG requer seu próprio diretório testemunha.

Independentemente de qual servidor seja usado como servidor testemunha, se o Firewall do Windows estiver habilitado no servidor testemunha pretendido, você deverá habilitar a exceção do Firewall do Windows para Compartilhamento de Arquivos e Impressoras. O servidor testemunha usa a porta SMB 445.

Importante

Se o servidor testemunha especificado não for um servidor do Exchange 2010 ou posterior, você deverá adicionar o USG (grupo de segurança universal) do Subsistema Confiável do Exchange ao grupo administradores locais no servidor testemunha antes de criar o DAG. Essas permissões de segurança são necessárias para assegurar que o Exchange possa criar um diretório e compartilhar o servidor testemunha conforme necessário.

Nem o servidor testemunha nem o diretório testemunha precisa ser tolerante a falhas ou usar uma forma de redundância ou de alta disponibilidade. Não há nenhuma necessidade de usar um servidor de arquivo em cluster para o servidor testemunha ou empregar qualquer outra forma de resiliência para o servidor testemunha. Há várias razões para isso. Com DAGs maiores (por exemplo, seis membros ou mais), várias falhas são necessárias para que haja a necessidade do servidor testemunha. Como um DAG com seis membros podem tolerar até duas falhas de votante sem perder quorum, seriam necessários até três votantes com falha para que o servidor testemunha fosse exigido a fim de manter um quórum. Além disso, se houver uma falha que afete o servidor testemunha atual (por exemplo, você perde o servidor testemunha por conta de uma falha de hardware), será possível usar o cmdlet Set-DatabaseAvailabilityGroup para configurar um novo servidor testemunha e um diretório testemunha (desde que você tenha um quórum).

Observação

Também será possível usar o cmdlet Set-DatabaseAvailabilityGroup para configurar o servidor testemunha e o diretório testemunha no local original, se o servidor testemunha tiver perdido seu armazenamento ou se alguém tiver alterado o diretório testemunha ou as permissões de compartilhamento.

Considerações colocação servidor testemunha

O posicionamento de um servidor testemunha do DAG dependerá dos seus requisitos de negócios e das opções disponíveis na organização. O Exchange agora inclui suporte para novas opções de configuração da DAG que não são recomendadas ou não são possíveis no Exchange 2010. Essas opções incluem o uso de um terceiro local, como um terceiro datacenter, uma filial ou uma rede virtual do Microsoft Azure.

A tabela a seguir lista recomendações de posicionamento de servidor testemunha gerais para diferentes cenários de implantação.

Cenário de implantação Recomendações
Único DAG implantado em um único datacenter Localize servidor testemunha no mesmo datacenter como membros do DAG
Único DAG implantado em dois datacenters; há locais adicionais disponíveis Localizar o servidor testemunha em uma rede virtual do Microsoft Azure para habilitar o failover automático do datacenter ou

Localizar o servidor testemunha no datacenter primário
Vários DAGs implantado em um único datacenter Localize servidor testemunha no mesmo datacenter como membros do DAG. As opções adicionais incluem:
  • Usando o mesmo servidor testemunha para vários DAGs
  • Usando um membro do DAG para agir como um servidor de testemunha para um DAG diferente
Vários DAGs implantado em dois datacenters Localizar o servidor testemunha em uma rede virtual do Microsoft Azure para habilitar o failover automático do datacenter ou

Localizar o servidor testemunha no datacenter, que é considerada primária para cada DAG. As opções adicionais incluem:

  • Usando o mesmo servidor testemunha para vários DAGs
  • Usando um membro do DAG para agir como um servidor de testemunha para um DAG diferente
DAGs única ou múltipla implantado em mais de dois datacenters Nesta configuração, o servidor testemunha deve estar localizado no datacenter onde deseja que a maioria dos votos de quorum de existir.

Quando um DAG foi implantado em dois datacenters, agora você pode usar um terceiro local para hospedar o servidor testemunha. Se sua organização tiver um terceiro local com uma infraestrutura de rede isolada de falhas de rede que afetam os dois datacenters em que o DAG é implantado, você poderá implantar o servidor testemunha do DAG nesse terceiro local, configurando o DAG com a capacidade de failover automático de bancos de dados para o outro datacenter em resposta a um evento de falha no nível do datacenter. Se sua organização tiver apenas dois locais físicos, você poderá usar uma rede virtual do Microsoft Azure como um terceiro local para colocar o servidor testemunha.

Especificar um servidor testemunha e um diretório testemunha durante a criação do DAG

Ao criar um DAG, você deve fornecer um nome para o DAG. Também é possível especificar um servidor e um diretório testemunha.

Quando você cria um DAG, as seguintes combinações de opções e comportamentos estão disponíveis:

  • É possível especificar apenas um nome para o DAG e deixar os campos Servidor testemunha e Diretório testemunha em branco. Nesse cenário, o assistente pesquisa o site local do Active Directory para um servidor de Acesso ao Cliente que não tem o servidor mailbox instalado e cria automaticamente o diretório padrão (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) e o compartilhamento padrão (<DAGFQDN>) nesse servidor e usa esse servidor de Acesso ao Cliente como o servidor testemunha. Por exemplo, considere o CAS3 do servidor testemunha no qual o sistema operacional foi instalado na unidade C. Um DAG chamado DAG1 no domínio contoso.com usaria um diretório testemunha padrão de C:\DAGFileShareWitnesses\DAG1.contoso.com, que seria compartilhado como \CAS3\DAG1.contoso.com.

  • É possível especificar um nome para o DAG, o servidor testemunha que você deseja usar e o diretório que você deseja criar e compartilhar no servidor testemunha.

  • É possível especificar um nome para o DAG e o servidor testemunha que deseja usar, além de deixar o campo Diretório testemunha em branco. Nesse cenário, o assistente cria o diretório padrão no servidor testemunha especificado.

  • É possível especificar um nome para o DAG e deixar o campo Servidor testemunha em branco, além de especificar o diretório que você deseja criar e compartilhar no servidor testemunha. Nesse cenário, o assistente procura um servidor de Acesso para Cliente que não tenha o servidor de Caixa de Correio instalado e cria automaticamente o DAG especificado nesse servidor, compartilha o diretório e usa o servidor de Acesso para Cliente como o servidor testemunha.

Quando um DAG for formado, ele usará inicialmente o modelo de quórum Maioria dos Nós. Quando o segundo servidor de Caixa de Correio for adicionado ao DAG, o quorum será alterado automaticamente para um modelo de quorum Maioria dos Nós e Compartilhamentos de Arquivos. Quando essa alteração ocorrer, o cluster do DAG começará a usar o servidor testemunha para manter quorum. Se o diretório testemunha não existir, ele será automaticamente criado e compartilhado pelo Exchange, que fornecerá o compartilhamento com permissões de controle total para a conta de computador do CNO do DAG.

Observação

Não é possível usar compartilhamento de arquivos que seja parte de um namespace do sistema de arquivos distribuído.

Se o firewall do Windows estiver habilitado no servidor testemunha antes de o DAG ser criado, ele poderá bloquear a criação do DAG. O Exchange usa a Instrumentação de Gerenciamento do Windows (WMI) para criar o diretório e o compartilhamento de arquivo no servidor testemunha. Se o firewall do Windows estiver habilitado no servidor testemunha e não houver nenhuma exceção de firewall configurada para a WMI, o cmdlet New-DatabaseAvailabilityGroup falhará com um erro. Se você especificar um servidor testemunha, mas não um diretório de testemunha, receberá a seguinte mensagem de erro:

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

Se você especificar um servidor testemunha e um diretório de testemunhas, receberá a seguinte mensagem de aviso:

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

Se o firewall do Windows estiver habilitado no servidor testemunha após a criação do DAG, mas antes de os servidores serem adicionados, ele poderá bloquear a adição ou remoção de membros do DAG. Se o Firewall do Windows estiver habilitado no servidor testemunha e não houver exceções de firewall configuradas para WMI, o cmdlet Add-DatabaseAvailabilityGroupServer exibirá a seguinte mensagem de aviso:

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Para resolve os erros e avisos anteriores, faça uma das seguintes etapas:

  • Crie manualmente o diretório testemunha e compartilhe o servidor testemunha e atribua ao CNO do DAG total controle para o diretório e o compartilhamento.

  • Habilite a exceção WMI no firewall do Windows.

  • Desabilite o firewall do Windows.

Associação ao DAG

Depois que um DAG tiver sido criado, você pode adicionar servidores ou remover servidores do DAG usando o assistente Gerenciar Grupo de Disponibilidade de Banco de Dados no EAC ou os cmdlets Add-DatabaseAvailabilityGroupServer ou Remove-DatabaseAvailabilityGroupServer no Shell de Gerenciamento do Exchange. Para obter etapas detalhadas sobre como gerenciar a associação do DAG, consulte Gerenciar a associação do grupo de disponibilidade do banco de dados.

Observação

Cada servidor de Caixa de Correio membro de um DAG também é um nó no cluster subjacente usado pelo DAG. Como resultado, a qualquer momento, um servidor de caixa de correio pode ser membro de apenas um DAG.

Se o servidor de Caixa de Correio adicionado a um DAG não tiver o componente de cluster de failover instalado, o método usado para adicionar o servidor (por exemplo, o cmdlet Add-DatabaseAvailabilityGroupServer ou o assistente para Gerenciar Grupo de Disponibilidade de Banco de Dados) instalará o recurso de clustering de failover.

Quando o primeiro servidor de caixa de correio é adicionado a um DAG, os seguintes eventos ocorrem:

  • O componente de clustering de failover do Windows será instalado, se ainda não estiver.

  • Um cluster de failover é criado usando-se o nome do DAG. Esse cluster de failover é usado exclusivamente pelo DAG e deve ser dedicado ao DAG. O uso do cluster para qualquer outra finalidade não tem suporte.

  • Um CNO é criado no contêiner de computadores padrão.

  • O nome e o endereço IP do DAG é registrado como um Host (A) no DNS.

  • O servidor é adicionado ao objeto do DAG no Active Directory.

  • O banco de dados clusterizado é atualizado com informações sobre os bancos de dados montados no servidor adicionado.

Em um ambiente grande ou com vários locais, especialmente aqueles em que o DAG é estendido a vários locais de Active Directory, é preciso aguardar a replicação de Active Directory do objeto do DAG que contém o primeiro membro do DAG a ser concluído. Se esse objeto Active Directory não for replicado em todo o ambiente, a adição do segundo servidor poderá fazer com que um novo cluster (e um novo CNO) sejam criados para o DAG. Essa criação ocorre porque o objeto DAG aparece vazio na perspectiva do segundo membro sendo adicionado, fazendo com que o cmdlet Add-DatabaseAvailabilityGroupServer crie um cluster e um CNO para o DAG, mesmo que esses objetos já existam. Para verificar se o objeto do DAG que tem o primeiro servidor do DAG foi replicado, use o cmdlet Get-DatabaseAvailabilityGroup no segundo servidor sendo adicionado para verificar se o primeiro servidor adicionado está listado como membro do DAG.

Quando o segundo e os servidores subsequentes são adicionados ao DAG, os seguintes eventos ocorrem:

  • O servidor é adicionado ao cluster de failover do Windows para o DAG.

  • O modelo de quorum é ajustado automaticamente:

    • Um modelo de quorum Maioria dos Nós é usado para DAGs com um número ímpar de membros.

    • Um modelo de quorum Maioria dos Nós e Compartilhamentos de Arquivos é usado para DAGs com um número par de membros.

  • O diretório testemunha e o compartilhamento são criados automaticamente pelo Exchange quando necessário.

  • O servidor é adicionado ao objeto do DAG no Active Directory.

  • O banco de dados clusterizado é atualizado com informações sobre bancos de dados montados.

Observação

A alteração feita no modelo de quorum deve acontecer automaticamente. No entanto, se o modelo de quorum não for alterado automaticamente para o modelo adequado, você poderá executar o cmdlet Set-DatabaseAvailabilityGroup com apenas o parâmetro Identity para corrigir nas configurações de quorum para o DAG.

Pré-preparo do objeto nome do cluster para um DAG

O CNO é uma conta de computador criada no Active Directory e associada ao recurso de nome do cluster. Esse recurso está vinculado ao CNO, que é um objeto habilitado para Kerberos que atua como a identidade do cluster e fornece o contexto de segurança do cluster. A formação do cluster subjacente do DAG e do CNO para esse cluster é feita quando o primeiro membro é adicionado ao DAG. Quando o primeiro servidor for adicionado ao DAG, o Powershell remoto entra em contato com o Serviço de Replicação do Microsoft Exchange no servidor de Caixa de Correio sendo adicionado. O serviço de Replicação do Microsoft Exchange instala o recurso cluster de failover (se ele ainda não estiver instalado) e inicia o processo de criação do cluster. O Serviço de Replicação do Microsoft Exchange é executado no contexto de segurança de LOCAL SYSTEM e está sob esse contexto em que a criação do cluster é feita.

Cuidado

Caso os membros do DAG estejam executando o Windows Server 2012, você deverá preparar o CNO antes de adicionar o primeiro servidor ao DAG. Se os membros do DAG estiverem executando Windows Server 2012 R2 e você criar um DAG sem um ponto de acesso administrativo de cluster, um CNO não será criado e você não precisará criar um CNO para o DAG.

Nos ambientes em que a criação de conta de computador é restrita ou as contas de computador são criadas em um contêiner que não seja o de computadores padrão, você pode preparar e fornecer o CNO. Crie e desabilite uma conta de computador para o CNO e faça uma das seguintes etapas:

  • Atribua controle total da conta do computador à conta do computador do primeiro servidor de Caixa de Correio sendo adicionado ao DAG.

  • Atribua controle total da conta do computador ao USG do Subsistema Confiável do Exchange.

Atribuir controle total da conta do computador à conta do computador do primeiro servidor de Caixa de Correio sendo adicionado ao DAG assegura que o contexto de segurança de LOCAL SYSTEM possa gerenciar a conta de computador preparada. A atribuição de controle total da conta de computador ao USG do Subsistema Confiável do Exchange pode ser usada porque o USG do Subsistema Confiável do Exchange tem as contas de máquina de todos os servidores Exchange do domínio.

Para obter as etapas detalhadas sobre como preparar e fornecer o CNO de um DAG, consulte Preparar o objeto de nome de cluster de um grupo de disponibilidade do banco de dados.

Remover servidores de um DAG

Os servidores de caixa de correio podem ser removidos de um DAG usando o assistente Gerenciar Grupo de Disponibilidade de Banco de Dados no EAC ou o cmdlet Remove-DatabaseAvailabilityGroupServer no Shell de Gerenciamento do Exchange. Para que um servidor de Caixa de Correio possa ser removido de um DAG, todos os bancos de dados de caixa de correio replicados devem ser primeiramente removidos do servidor. Se você tentar remover um servidor de Caixa de Correio com bancos de dados de caixa de correio de um DAG, haverá falha na tarefa.

Há cenários nos quais você deve remover um servidor de Caixa de Correio de um DAG antes de realizar determinadas operações. Esses cenários incluem:

  • Executando uma operação de recuperação de servidor: se um servidor da Caixa de Correio que é membro de um DAG for perdido ou falhar e não for possível e precisar de substituição, você poderá executar uma operação de recuperação de servidor usando a opção Configurar /m:RecoverServer . No entanto, antes de executar a operação de recuperação, primeiro você deve remover o servidor do DAG usando o cmdlet Remove-DatabaseAvailabilityGroupServer com o parâmetro ConfigurationOnly .

  • Removendo o grupo de disponibilidade do banco de dados: pode haver situações em que você precisa remover um DAG (por exemplo, ao desabilitar o modo de replicação de terceiros). Se precisar remover um DAG, você deverá remover primeiro todos os servidores do DAG. Se você tentar remover um DAG que contenha algum membro, haverá falha na tarefa.

Configurar propriedades do DAG

Depois que os servidores forem adicionados ao DAG, você poderá usar o EAC ou o Shell de Gerenciamento do Exchange para configurar as propriedades de um DAG, incluindo o servidor testemunha e o diretório testemunha usado pelo DAG e os endereços IP atribuídos ao DAG.

As propriedades configuráveis incluem:

  • Servidor testemunha: o nome do servidor que você deseja hospedar o compartilhamento de arquivos para a testemunha de compartilhamento de arquivos. Recomendamos que você especifique um servidor de Acesso para Cliente como o servidor testemunha. Essa nomenclatura permite que o sistema configure, proteja e use automaticamente o compartilhamento, conforme necessário, e permite que o administrador de mensagens esteja ciente da disponibilidade do servidor testemunha.

  • Diretório testemunha: o nome de um diretório que será usado para armazenar dados de testemunha de compartilhamento de arquivos. Esse diretório será criado automaticamente pelo sistema no servidor testemunha especificado.

  • Endereços IP do grupo de disponibilidade de banco de dados: um ou mais endereços IP devem ser atribuídos ao DAG, a menos que os membros do DAG estejam executando Windows Server 2012 R2 e você esteja criando um DAG sem um endereço IP. Caso contrário, os endereços IP do DAG podem ser configurados com endereços IP estáticos atribuídos manualmente ou podem ser atribuídos automaticamente ao DAG com um servidor DHCP na organização.

O Shell de Gerenciamento do Exchange permite configurar propriedades DAG que não estão disponíveis no EAC, como endereços IP DAG; configurações de criptografia de rede e compactação; descoberta de rede; a porta TCP usada para replicação; e configurações alternativas de servidor testemunha e diretório de testemunha; e para habilitar o modo de Coordenação de Ativação do Datacenter.

Para obter etapas detalhadas sobre como configurar as propriedades do DAG, consulte Configurar as propriedades do grupo de disponibilidade do banco de dados.

Criptografia de rede do DAG

Os DAGs dão suporte ao uso da criptografia aproveitando os recursos de criptografia do sistema operacional Windows Server. DAGs usam a autenticação Kerberos entre servidores do Exchange. As APIs EncryptMessage e DecryptMessage do provedor de suporte de segurança (SSP) Microsoft Kerberos lidam com a criptografia do tráfego de rede do DAG. O SSP do Microsoft Kerberos dá suporte a vários algoritmos de criptografia. (Para obter a lista completa, confira a seção 3.1.5.2, "Tipos de Criptografia" de Extensões de Protocolo Kerberos.) O aperto de mão de autenticação Kerberos seleciona o protocolo de criptografia mais forte com suporte na lista: normalmente O AES (Advanced Encryption Standard) de 256 bits, potencialmente com um HMAC (Código de Autenticação de Mensagem baseado em Hash) sha para manter a integridade dos dados. Para obter mais informações, consulte HMAC.

A criptografia de rede é uma propriedade do DAG e não da rede DAG. Você pode configurar a criptografia de rede DAG usando o cmdlet Set-DatabaseAvailabilityGroup no Shell de Gerenciamento do Exchange. As possíveis configurações de criptografia para comunicações de rede DAG são mostradas na tabela a seguir:

Setting Descrição
Desabilitado A criptografia de rede não é usada.
Habilitado A criptografia de rede é usada em todas as redes do DAG para replicação e propagação.
InterSubnetOnly A criptografia de rede é usada em redes do DAG durante a replicação em sub-redes diferentes. Essa configuração é a configuração padrão.
SeedOnly A criptografia de rede é usada em todas as redes do DAG apenas para propagação.

Compactação de rede do DAG

Os DAGs dão suporte à compactação interna. Quando a compactação for habilitada, a comunicação de rede do DAG usará XPRESS, que é a implementação da Microsoft do algoritmo LZ77. Essa compactação é o mesmo tipo de compactação usada em muitos protocolos da Microsoft, em particular, compactação MAPI RPC entre o Microsoft Outlook e o Exchange.

Assim como acontece com a criptografia de rede, a compactação de rede também é uma propriedade do DAG e não da rede DAG. Você configura a compactação de rede DAG usando o cmdlet Set-DatabaseAvailabilityGroup no Shell de Gerenciamento do Exchange. As possíveis configurações de compactação para comunicações de rede DAG são mostradas na tabela a seguir:

Setting Descrição
Desabilitado A compactação de rede não é usada.
Habilitado A compactação de rede é usada em todas as redes do DAG para replicação e propagação.
InterSubnetOnly A compactação de rede é usada em redes do DAG durante a replicação em sub-redes diferentes. Essa configuração é a configuração padrão.
SeedOnly A compactação de rede é usada em todas as redes do DAG apenas para propagação.

Redes do DAG

Uma rede do DAG é uma coleção de uma ou mais sub-redes usadas para tráfego de replicação ou tráfego MAPI. Cada DAG contém um máximo de uma rede MAPI e zero ou mais redes de replicação. Em uma configuração de adaptador de rede único, a rede é usada para MAPI e tráfego de replicação. Embora haja suporte a um único adaptador de rede e um caminho, recomendamos que cada DAG tenha pelo menos duas redes do DAG. Em uma configuração com duas redes, uma rede costuma ser dedicada ao tráfego de replicação e a outra rede é usada essencialmente para o tráfego MAPI. Você pode também adicionar adaptadores de rede a cada membro do DAG e configurar redes de DAG adicionais como redes de replicação.

Observação

Ao usar várias redes de replicação, não há qualquer maneira de especificar uma ordem de precedência para o uso das redes. O Exchange seleciona aleatoriamente uma rede de replicação, no grupo de redes de replicação, para usá-la para envio de logs.

No Exchange 2010, a configuração manual de redes DAG era necessária em muitos casos. Por padrão, em versões posteriores do Exchange, as redes DAG são configuradas automaticamente pelo sistema. Antes de criar ou modificar redes DAG, você deve primeiro habilitar o controle manual de redes DAG executando este comando:

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

Depois de habilitar a configuração manual de rede DAG, você pode usar o cmdlet New-DatabaseAvailabilityGroupNetwork no Shell de Gerenciamento do Exchange para criar uma rede DAG. Para instruções detalhadas sobre como criar uma rede DAG, consulte Criar uma rede de grupo de disponibilidade do banco de dados.

Você pode usar o cmdlet Set-DatabaseAvailabilityGroupNetwork no Shell de Gerenciamento do Exchange para configurar propriedades de rede DAG. Para obter etapas detalhadas sobre como configurar as propriedades de rede do DAG, consulte Configurar propriedades de rede do grupo de disponibilidade de banco de dados. Cada rede do DAG exigiu parâmetros opcionais a serem configurados:

  • Nome da rede: um nome exclusivo para a rede DAG de até 128 caracteres.

  • Descrição da rede: uma descrição opcional para a rede DAG de até 256 caracteres.

  • Sub-redes de rede: uma ou mais sub-redes inseridas usando um formato de sub-redes IPAddress/Bitmask (por exemplo, 192.168.1.0/24 para sub-redes IPv4 (Protocolo de Internet versão 4); 2001:DB8:0:C000:::/64 para sub-redes do Protocolo de Internet 6 (IPv6).

  • Habilitar a replicação: no EAC, selecione a caixa de seleção para dedicar a rede DAG ao tráfego de replicação e bloquear o tráfego MAPI. Desmarque a caixa de seleção para impedir que a replicação use a rede DAG e habilite o tráfego MAPI. No Shell de Gerenciamento do Exchange, use o parâmetro ReplicationEnabled no cmdlet Set-DatabaseAvailabilityGroupNetwork para habilitar e desabilitar a replicação.

Observação

Desabilitar a replicação na rede MAPI não garante que o sistema não usará essa rede na replicação. Quando todas as redes de replicação configuradas estiverem offline, tiverem falhado ou estiverem indisponíveis de qualquer outra forma e somente a rede MAPI continuar ativa (o que é configurado como desabilitado para replicação), o sistema usará a rede MAPI para replicação.

As redes DAG iniciais (por exemplo, MapiDagNetwork e ReplicationDagNetwork01) criadas pelo sistema têm como base as sub-redes enumeradas pelo serviço de Cluster. Cada membro do DAG deve ter o mesmo número de adaptadores de rede, e cada adaptador de rede deve ter um endereço IPv4 (e opcionalmente, um endereço IPv6 também) em uma sub-rede exclusiva. Vários membros do DAG podem ter endereços IPv4 na mesma sub-rede, mas cada adaptador de rede e par de endereço IP em um membro do DAG específico deve estar em uma sub-rede exclusiva. Além disso, somente o adaptador usado para a rede MAPI deve ser configurado com um gateway padrão. As redes de replicação não devem ser configuradas com um gateway padrão.

Por exemplo, considere o DAG1, um DAG de dois membros em que cada membro tem dois adaptadores de rede (um dedicado para a rede MAPI e outro para uma rede de replicação). As configurações de configuração de endereço IP de exemplo são mostradas na seguinte tabela:

Exemplo de configurações do adaptador de rede

Adaptador de servidor-rede Endereço IP/máscara de sub-rede Gateway padrão
EX1-MAPI 192.168.1.15/24 192.168.1.1
EX1-Replication 10.0.0.15/24 Não aplicável
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replication 10.0.0.16 Não se aplica

Na configuração a seguir, há duas sub-redes configuradas no DAG: 192.168.1.0 e 10.0.0.0. Quando EX1 e EX2 são adicionados ao DAG, duas sub-redes serão enumeradas e duas redes de DAG serão criadas: MapiDagNetwork (192.168.1.0) e ReplicationDagNetwork01 (10.0.0.0). Essas redes serão configuradas, conforme mostrado na tabela a seguir:

Configurações de rede de DAG enumeradas para um DAG de sub-rede única

Nome Sub-redes Interfaces Acesso MAPI habilitado Replicação habilitada
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)
EX2 (192.168.1.16)		 Verdadeiro Verdadeiro
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)
EX2 (10.0.0.16)		 Falso Verdadeiro

Para concluir a configuração de ReplicationDagNetwork01 como a rede de replicação dedicada, desabilite a replicação para MapiDagNetwork executando o seguinte comando:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false

Depois que a replicação é desabilitada para MapiDagNetwork, o serviço de replicação do Microsoft Exchange usa ReplicationDagNetwork01 para replicação contínua. Se ReplicationDagNetwork01 falhar, o serviço de replicação do Microsoft Exchange volta a usar MapiDagNetwork para replicação contínua. O retorno ao MapiDagNetwork é feito intencionalmente pelo sistema para manter a alta disponibilidade.

Redes DAG e várias implantações de sub-rede

No exemplo anterior, embora existam duas sub-redes diferentes em uso pelo DAG (192.168.1.0 e 10.0.0.0), o DAG é considerado uma sub-rede única porque cada membro usa a mesma sub-rede para formar a redes MAPI. Quando os membros do DAG usam sub-redes diferentes para a rede MAPI, o DAG é mencionado como um DAG com várias sub-redes. Em um DAG com várias sub-redes, as sub-redes adequadas são associadas automaticamente a cada rede DAG.

Por exemplo, considere o DAG2, um DAG de dois membros em que cada membro tem dois adaptadores de rede (um dedicado para a rede MAPI e outro para uma rede de replicação), e cada membro do DAG está localizado em um site do Active Directory separado, com sua rede MAPI em uma sub-rede diferente. As configurações de configuração de endereço IP de exemplo são mostradas na seguinte tabela:

Exemplo de configurações de adaptador de rede para um DAG com várias sub-redes

Adaptador de servidor-rede Endereço IP/máscara de sub-rede Gateway padrão
EX1-MAPI 192.168.0.15/24 192.168.0.1
EX1-Replication 10.0.0.15/24 Não aplicável
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Replication 10.0.1.15 Não se aplica

Na configuração a seguir, há quatro sub-redes configuradas no DAG: 192.168.0.0, 192.168.1.0, 10.0.0.0 e 10.0.1.0. Quando EX1 e EX2 são adicionados ao DAG, quatro sub-redes serão enumeradas, mas apenas duas redes DAG serão criadas: MapiDagNetwork (192.168.0.0, 192.168.1.0) e ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Essas redes serão configuradas conforme mostrado na tabela a seguir:

Configurações de rede de DAG enumeradas para um DAG de várias sub-redes

Nome Sub-redes Interfaces Acesso MAPI habilitado Replicação habilitada
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24		 EX1 (192.168.0.15)
EX2 (192.168.1.15)		 Verdadeiro Verdadeiro
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24		 EX1 (10.0.0.15)
EX2 (10.0.1.15)		 Falso Verdadeiro

Redes DAG e redes iSCSI

Por padrão, os DAGs realizam a descoberta de todas as redes detectadas e configuradas para uso pelo cluster subjacente. Essa descoberta inclui a de todas as redes iSCSI (iSCSI) da Internet em uso como resultado do uso do armazenamento iSCSI para um ou mais membros DAG. Como prática recomendada, o armazenamento iSCSI deve usar redes dedicadas e adaptadores de rede. Essas redes não devem ser gerenciadas pelo DAG ou pelo cluster ou ser usadas como redes DAG (MAPI ou replicação). Em vez disso, essas redes devem ser desabilitadas manualmente do uso pelo DAG para que possam ser dedicadas ao tráfego de armazenamento iSCSI. Para impedir que redes iSCSI sejam detectadas e usadas como redes DAG, configure o DAG para ignorar quaisquer redes iSCSI detectadas no momento usando o cmdlet Set-DatabaseAvailabilityGroupNetwork, como neste exemplo:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Este comando também irá desativar a rede para uso pelo cluster. Embora as redes iSCSI continuem aparecendo como redes do DAG, elas não serão usadas para MAPI ou tráfego de replicação após a execução do comando acima.

Configurar membros do DAG

Os servidores de caixa de correio que são membros de um DAG têm algumas propriedades específicas de alta disponibilidade que devem ser configuradas como descrito nas seguintes seções:

Discagem de montagem automática de banco de dados

O parâmetro AutoDatabaseMountDial especifica o comportamento de montagem de banco de dados automático após o failover de um banco de dados. Você pode usar o cmdlet Set-MailboxServer para configurar o parâmetro AutoDatabaseMountDial com qualquer um dos seguintes valores:

  • BestAvailability: se você especificar esse valor, o banco de dados será montado automaticamente imediatamente após um failover se o comprimento da fila de cópia for menor ou igual a 12. O tamanho da fila de cópia é o número de logs reconhecidos pela cópia passiva que precisa ser replicada. Se o tamanho da fila de cópia for maior que 12, o banco de dados não será montado automaticamente. Quando o comprimento da fila de cópia é menor ou igual a 12, o Exchange tenta replicar os logs restantes para a cópia passiva e monta o banco de dados.

  • GoodAvailability: se você especificar esse valor, o banco de dados será montado automaticamente imediatamente após um failover se o comprimento da fila de cópia for menor ou igual a seis. O tamanho da fila de cópia é o número de logs reconhecidos pela cópia passiva que precisa ser replicada. Se o tamanho da fila de cópia for maior que seis, o banco de dados não será montado automaticamente. Quando o tamanho da fila de cópia é inferior ou igual a seis, o Exchange tenta replicar os logs restantes para a cópia passiva e monta o banco de dados.

  • Lossless: se você especificar esse valor, o banco de dados não será montado automaticamente até que todos os logs gerados na cópia ativa tenham sido copiados para a cópia passiva. Essa configuração faz também com que o Gerenciador Ativo selecione a melhor cópia de algoritmo para classificar candidatos potenciais para ativação com base no valor de preferência de ativação da cópia de banco de dados e não na extensão da fila de cópia.

O valor padrão é GoodAvailability. Se você especificar ou BestAvailabilityGoodAvailability, e todos os logs da cópia ativa não puderem ser copiados para a cópia passiva que está sendo ativada, você poderá perder alguns dados da caixa de correio. No entanto, o recurso de Rede Segura (que é habilitado por padrão) ajuda a proteger contra a perda da maior parte dos dados, reenviando as mensagens que estão na fila de Rede Segura.

Exemplo: configurar discagem de montagem automática de banco de dados

O exemplo a seguir configura um servidor de caixa de correio com uma configuração AutoDatabaseMountDial de GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Política de ativação automática de cópia do banco de dados

O parâmetro DatabaseCopyAutoActivationPolicy especifica o tipo de ativação automática disponível para cópias de banco de dados da caixa de correio nos servidores Caixa de Correio selecionados. Você pode usar o cmdlet Set-MailboxServer para configurar o parâmetro DatabaseCopyAutoActivationPolicy com qualquer um dos seguintes valores:

  • Blocked: se você especificar esse valor, os bancos de dados não poderão ser ativados automaticamente nos servidores de caixa de correio selecionados.

  • IntrasiteOnly: se você especificar esse valor, a cópia do banco de dados poderá ser ativada em servidores no mesmo site do Active Directory. Essa ativação impede o failover ou a ativação entre sites. Essa propriedade se destina a cópias de banco de dados de caixa de correio (por exemplo, uma cópia passiva transformada em uma cópia ativa). Os bancos de dados não podem ser ativados nesse servidor de Caixa de Correio para cópias de banco de dados ativos em outro site do Active Directory.

  • Unrestricted: se você especificar esse valor, não haverá restrições especiais na ativação de cópias de banco de dados de caixa de correio nos servidores de caixa de correio selecionados.

Exemplo: configurar política de ativação automática de cópia do banco de dados

O exemplo a seguir configura um servidor de caixa de correio com uma configuração DatabaseCopyAutoActivationPolicy de Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Máximo de bancos de dados ativos

O parâmetro MaximumActiveDatabases (também usado com o cmdlet Set-MailboxServer) especifica o número de bancos de dados que pode ser montado em um servidor de Caixa de Correio. Você pode configurar servidores de Caixa de Correio para atender aos seus requisitos de implantação assegurando que um servidor de Caixa de Correio individual não fique sobrecarregado.

O parâmetro MaximumActiveDatabases é configurado com um valor numérico de número inteiro. Quando o número máximo for atingido, as cópias de banco de dados no servidor não poderão ser ativadas se houver failover ou alternância. Se as cópias já estiverem ativas em um servidor, ele não permitirá a montagem de bancos de dados.

Exemplo: configurar máximo de bancos de dados ativos

O exemplo a seguir configura um servidor de caixa de correio para dar suporte a um máximo de 20 bancos de dados ativos:

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Executar a manutenção em membros do DAG

Antes de executar qualquer tipo de manutenção de software ou hardware em um membro DAG, primeiro você deve colocar o membro DAG no modo de manutenção. Os scripts a seguir são fornecidos com Exchange Server para ajudar nos procedimentos de manutenção do DAG:

  • StartDagServerMaintenance.ps1: auxilia na movimentação de todos os bancos de dados ativos do servidor. Ele também move todas as funcionalidades críticas de suporte do DAG, como a função PAM (Primary Active Manager) e as impede de voltar para o servidor antes que a manutenção seja concluída.

  • StopDagServerMaintenance.ps1: ajuda a tirar o membro DAG do modo de manutenção e torná-lo um destino ativo para todos os bancos de dados e todas as funcionalidades críticas de suporte do DAG.

Os scripts acima aceitam o parâmetro ServerName (que pode ser o nome do host ou o FQDN (nome de domínio totalmente qualificado) do membro DAG) e os parâmetros WhatIf . Ambos os scripts podem ser executados localmente ou remotamente. O servidor no qual os scripts são executados deve ter as ferramentas de Gerenciamento de Cluster de Failover do Windows instaladas (RSAT-Clustering).

Observação

O script RedistributeActiveDatabases.ps1 também está disponível, o que ajuda na montagem de bancos de dados de caixa de correio em membros da DAG específicos, conforme indicado pelo número preferência de ativação em cada banco de dados. No entanto, no Exchange 2016 CU2 ou posterior, a nova propriedade DAG chamada PreferenceMoveFrequency equilibra automaticamente cópias de banco de dados em um DAG. Portanto, você só precisará usar RedistributeActiveDatabases.ps1 script se tiver desabilitado essa funcionalidade ou se quiser equilibrar cópias de banco de dados manualmente.

O scriptStartDagServerMaintenance.ps1 executa as seguintes tarefas:

  • Define o valor do parâmetro DatabaseCopyAutoActivationPolicy no membro DAG como Blocked, o que impede que quaisquer cópias de banco de dados sejam ativadas no servidor.

  • Pausa o nó no cluster, o que impede que o nó seja e se torne o PAM.

  • Move todos os bancos de dados ativos atualmente hospedados no membro DAG para outros membros da DAG.

  • Se o membro DAG atualmente possui o grupo de cluster padrão, o script move o grupo de cluster padrão (e, portanto, a função PAM) para outro membro DAG.

Se alguma das tarefas anteriores falhar, todas as operações, exceto movimentos bem-sucedidos do banco de dados, serão desfeitas pelo script.

Para iniciar procedimentos de manutenção em um membro DAG, incluindo liberar as filas de transporte e suspender a conectividade do cliente, execute as seguintes tarefas:

  1. Para esvaziar as filas de transporte, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. Para iniciar a drenagem das filas de transporte, execute o seguinte comando:

    Restart-Service MSExchangeTransport

  3. Para iniciar o processo de drenagem de todas as chamadas de Mensagens Unificadas (somente no Exchange 2016), execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. Para acessar os scripts de manutenção da DAG, execute o seguinte comando:

    CD $ExScripts

  5. Para executar o script StartDagServerMaintenance.ps1 , execute o seguinte comando:

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode

    Para o valor do parâmetro MoveComment , você pode fazer qualquer notação desejada. O exemplo acima usa "Manutenção".

    Observação

    Esse script pode levar algum tempo para ser executado e, durante esse tempo, talvez você não veja nenhuma atividade na tela.

  6. Para redirecionar mensagens pendentes de entrega nas filas locais para o servidor exchange especificado pelo parâmetro Target, execute o seguinte comando:

    Redirect-Message -Server <ServerName> -Target <Server FQDN>

  7. Para colocar o servidor no modo de manutenção, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

Para verificar se um servidor está pronto para manutenção, realizar as seguintes tarefas:

  1. Para verificar se o servidor foi colocado no modo de manutenção, confirme se somente Monitoring e RecoveryActionsEnabled esteja em um estado ativo quando você executar o seguinte comando:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

  2. Para verificar se o servidor não está hospedando cópias de banco de dados ativos, execute o seguinte comando:

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy

  3. Para verificar se o nó de cluster está pausado, execute o seguinte comando:

    Get-ClusterNode <ServerName> | Format-List

  4. Para verificar se todas as filas de transporte foram esvaziadas, execute o seguinte comando:

    Get-Queue

Depois que a manutenção for concluída e o membro DAG estiver pronto para retornar ao serviço, o script StopDagServerMaintenance.ps1 ajuda a tirar o membro DAG do modo de manutenção e colocá-lo novamente em produção. O scriptStopDagServerMaintenance.ps1 executa as seguintes tarefas:

  • Retoma o nó no cluster, que permite a funcionalidade completa do cluster para o membro DAG.

  • Define o valor do parâmetro DatabaseCopyAutoActivationPolicy no membro DAG como Unrestricted.

  • Executa o cmdlet Resume-MailboxDatabaseCopy para cada cópia de banco de dados hospedada no membro DAG.

Quando você estiver pronto para restaurar o membro DAG para a produção completa status, incluindo retomar as filas de transporte e a conectividade do cliente, execute as seguintes tarefas:

  1. Para configurar o servidor para estar no modo fora de manutenção e pronto para aceitar conexões de cliente, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  2. Para permitir que o servidor aceite chamadas de Mensagens Unificadas (somente no Exchange 2016), execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  3. Para acessar os scripts de manutenção da DAG, execute o seguinte comando:

    CD $ExScripts

  4. Para executar o scriptStopDagServerMaintenance.ps1 , execute o seguinte comando:

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>

  5. Para permitir que as filas de transporte retomem as mensagens de aceitação e processamento, execute o seguinte comando:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  6. Para retomar a atividade de transporte, execute o seguinte comando:

    Restart-Service MSExchangeTransport

Para verificar se um servidor está pronto para o uso na produção, execute as seguintes tarefas:

  1. Para verificar se o servidor não está no modo de manutenção, execute o seguinte comando:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize

Se você estiver instalando uma atualização do Exchange e o processo de atualização falhar, ele poderá deixar alguns componentes do servidor em um estado inativo, que serão exibidos na saída do cmdlet acima Get-ServerComponentState . Para resolve esse problema, execute os seguintes comandos:

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Desativar os membros do DAG

A solução de alta disponibilidade do Exchange é integrada ao processo de desligamento do Windows. Se um administrador ou aplicativo iniciar um desligamento de um servidor do Windows em um DAG com um banco de dados montado replicado para um ou mais membros do DAG, o sistema tentará ativar outra cópia do banco de dados montado, antes de permitir a conclusão do processo de desligamento.

No entanto, esse novo comportamento não garante que todos os bancos de dados no servidor que estão sendo desligados terão uma lossless ativação. Dessa forma, é uma prática recomendável realizar uma alternância de servidor antes de desligar um servidor membro de um DAG.

Instalar atualizações sobre membros do DAG

Instalar atualizações do Exchange em um servidor que é membro de um DAG é um processo relativamente simples. Quando você instalar uma atualização em um servidor que é membro de um DAG, vários serviços são interrompidos durante a instalação, incluindo todos os Exchange serviços eo serviço de cluster. O processo geral para a aplicação de alterações de um membro do DAG é como se segue:

  1. Use as etapas descritas acima para colocar o membro do DAG em modo de manutenção.

  2. Instale a atualização.

  3. Use os passos descritos acima para dar o membro do DAG do modo de manutenção e colocá-lo novamente em produção.

  4. Opcionalmente, use o scriptRedistributeActiveDatabases.ps1 para reequilibrar as cópias ativas do banco de dados em todo o DAG.

Para obter mais informações sobre as atualizações mais recentes do Exchange, consulte Exchange Server números de build e datas de lançamento.

Observação

Você sempre deve executar todos os membros da DAG na mesma versão do servidor exchange (incluindo atualizações cumulativas e de segurança). Execute uma "atualização rolando" de todos os membros da DAG e não execute um DAG com membros em uma versão diferente do Exchange por um longo período de tempo.