Comunicações

Replicação contínua em espera do Service Pack 1 para Exchange Server 2007

Scott Schnoll

Visão geral:

• Configurando a replicação contínua em espera
• A importância da redundância
• Como a SCR reduz o tempo de inatividade

O Service Pack 1 oferece vários recursos e aprimoramentos novos para o Exchange 20 07. Um desses novos recursos, a SCR (Replicação Contínua em Espera), foi projetado para propiciar às organizações redundância no data center e resiliência local. Como o nome indica, a SCR foi projetada

para cenários que usam ou habilitam o uso de servidores de recuperação em espera.

Caso esteja familiarizado com a versão RTM (Release to Manufacturing) do Exchange 2007, você já deve saber que ela também oferece redundância no data center e resiliência local em todos os recursos de envio de logs e suporte aos clusters de failover do Windows® . Na versão RTM, o envio de logs (conhecido oficialmente como replicação contínua) está disponível em duas formas: LCR (replicação contínua local), como mostra a Figura 1e CCR (replicação contínua em cluster), como mostra a Figura 2.

Figure 1** Local continuous replication **

Figure 2** CCR is log shipping to a second server in a Windows failover cluster **

A replicação contínua oferece disponibilidade de dados e redundância, permitindo que os administradores habilitem e mantenham online uma segunda cópia de todos os bancos de dados de caixas de correio. Essa cópia do banco de dados representa uma primeira linha de defesa contra falha, perda ou dano de um banco de dados de produção. Em vez de precisar perder tempo localizando uma fita de backup para poder restaurar os dados, uma cópia do banco de dados pode ser ativada e transformada em um banco de dados de produção em questão de minutos.

A SCR estende os cenários em que é possível obter dados e disponibilidade do serviço para a organização. Os novos cenários lhe permitem separar as topologias de alta disponibilidade das topologias de resiliência local, além de também permitirem que você implante configurações adequadas às necessidades específicas da organização em cada área.

A versão RTM do Exchange 2007 proporciona redundância no data center e resiliência local, mas como a LCR e a CCR oferecem apenas uma cópia extra de cada banco de dados, você deve optar pela resiliência ou pela redundância. Por exemplo, considere os recursos de disponibilidade de dados e serviço oferecidos pela CCR. Implantar os nós ativo e passivo em um único data center possibilita o serviço no data center e a disponibilidade de dados, mas não a resiliência local (porque ambos os nós estão no mesmo local físico). Já implantar o nó ativo em um data center e o nó passivo em um segundo data center proporciona a resiliência, mas não a disponibilidade no data center (porque o nó passivo, que oferece esses recursos, está localizado em um segundo data center).

Com a SCR no Service Pack 1, a disponibilidade para a criação de cópias adicionais dos bancos de dados significa que a alta disponibilidade e a resiliência local não são mutuamente excludentes; é possível conseguir ambas. Por exemplo, como mostra a Figura 3, você pode combinar a SCR com a CCR para replicar grupos de armazenamento localmente em um data center principal (usando a CCR para a alta disponibilidade) e remotamente em um segundo data center ou em espera (usando a SCR para a resiliência local). O segundo data center contém um cluster em espera que pode ser ativado e rapidamente provisionado com um servidor de caixa de correio em cluster de substituição em um cenário de recuperação local.

Figure 3** CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter **(Clique na imagem para aumentar a exibição)

A Figura 3 ilustra uma implantação corporativa com dois data centers, cada um com seu próprio site do Active Directory® : Redmond e Quincy. O site Redmond está localizado no data center principal (produção) e o site Quincy, em um data center secundário (backup). A CCR está implantada em Redmond para que haja redundância no data center. Com os elementos de infra-estrutura exigidos pelo Exchange 2007, os destinos da SCR são configurados em um cluster em espera no Quincy para que haja resiliência local. Esses elementos de infra-estrutura adicionais, os quais incluem os servidores de Acesso para Cliente e Transporte de Hub, servidores Active Directory e DNS, além do acesso à Internet, podem ser recursos dedicados ou não. Recursos dedicados são aqueles designados para dar suporte apenas aos usuários do data center nos quais eles residem. Já os não dedicados são aqueles recursos que dão suporte aos usuários no data center local, bem como aos usuários em outros locais. Você deve decidir se os recursos serão dedicados ou não, dependendo daquilo que for melhor para a organização. Para obter mais informações sobre recursos dedicados e não dedicados, consulte o tópico do arquivo de Ajuda do Exchange Server 2007 "Site Resilience Configurations" em technet.microsoft.com/bb201662.aspx. Também observe o uso de um novo quorum MNS (Majority Node Set). No Exchange Server 2007, a CCR usa o quorum de MNS com FSW (testemunha de compartilhamento de arquivos), e não o nó eleitor tradicional, como é possível ver na Figura 3.

Na Figura 4, um ambiente com CCR mais SCR projetado com a resiliência em mente oferece várias camadas de redundância para as caixas de correio e os serviços hospedados no servidor EXCLUS1, o que protege essas caixas de correio de falhas catastróficas de pequenas a grandes proporções.

Figure 4** Standalone mailbox servers using SCR to replicate storage groups to each other **(Clique na imagem para aumentar a exibição)

As pequenas e médias organizações também podem usufruir a SCR. Por exemplo, como mostra a Figura 4, uma organização pode implantar dois servidores de caixa de correio autônomos (EXMBX1 E EXMBX2) e usar a SCR para replicar um ou todos os grupos de armazenamento de um servidor de caixa de correio para outro.

Nesse exemplo, EXMBX1 e EXMBX2 são servidores de produção com cinco grupos de armazenamento ativos. Cada grupo de armazenamento é uma origem de SCR correspondente ao destino de SCR no outro servidor. Em caso de falha de armazenamento ou de algum outro evento em que um grupo de armazenamento ativo configurado como uma origem de SCR esteja indisponível, o destino de SCR pode ser rapidamente ativado usando algumas tarefas administrativas no Shell de Gerenciamento do Exchange. Com o Microsoft® Office Outlook® 2007 e os recursos de portabilidade do banco de dados e de Descoberta Automática do Exchange 2007, o tempo de inatividade em caso de perda do grupo de armazenamento ativo (ou, no caso, várias perdas do grupo de armazenamento ativo) pode ser de alguns minutos apenas.

Origens e destinos de SCR

Assim como acontece com a LCR e a CCR, a SCR também usa o conceito de cópias ativas e passivas de um grupo de armazenamento, mas se refere a elas como origens e destinos de SCR, respectivamente. No entanto, as origens e os destinos de SCR são cópias do grupo de armazenamento. (Os grupos de armazenamento de recuperação não podem ser habilitados para a SCR.)

O ponto de partida para a SCR (a origem de SCR) é qualquer grupo de armazenamento em um servidor de caixa de correio autônomo ou em um servidor de caixa de correio em cluster dentro de um cluster de cópia única ou ambiente CCR. É importante observar que, muito embora a origem de SCR possa estar em um servidor de caixa de correio em cluster, a SCR propriamente dita não é uma solução em cluster e não exige o serviço de Cluster do Windows. O ponto final da SCR (o destino de SCR) pode ser um servidor de caixa de correio autônomo ou um nó em um cluster de failover no qual a função de Caixa de Correio está instalada, mas sem nenhum servidor de caixa de correio em cluster configurado no cluster.

Relações de origem e de destino

Cada grupo de armazenamento de origem da SCR pode ter um número ilimitado de destinos da SCR. Por exemplo, uma origem poderia ter um destino residindo no mesmo data center dela e um segundo destino em um data center separado. No entanto, a Microsoft recomenda que não sejam usados mais do que quatro destinos por origem. Caso opte por usar mais do que quatro destinos, você deve avaliar o provável impacto sobre o servidor de origem da SCR em termos de memória, CPU e recursos de disco, e planejar de acordo. Cada computador de destino da SCR pode ter vários servidores de origem. Tanto o computador de origem quanto o de destino devem estar executando o Service Pack 1 para Exchange 2007. O sistema operacional deve ser compatível com o Service Pack 1 para Exchange 2007 (por exemplo, o Windows Server® 2008 ou o Windows Server 2003 SP2). No entanto, independentemente do sistema operacional usado por você, a SCR não tem suporte para todos os sistemas operacionais e exige que o sistema na origem corresponda ao sistema de todos os destinos da SCR referentes a essa origem. Por isso, caso a origem da SCR esteja executando o Windows Server 2003, todos os destinos da SCR relacionados a essa origem também devem ter o Windows Server 2003 em execução.

A SCR está disponível na Standard Edition do Exchange 2007. Caso seja usado um servidor de caixa de correio em cluster em um ambiente de SCC ou CCR como origem da SCR, é necessária a Enterprise Edition do Exchange 2007. Cada destino da SCR dá suporte a um máximo de 50 instâncias (50 grupos de armazenamento replicados) com o uso da Enterprise Edition e um máximo de 5 com a Standard Edition.

Os destinos da SCR também têm requisitos a serem atendidos. Primeiro, os computadores de origem e de destino devem estar no mesmo domínio do Active Directory, ainda que possam estar nos mesmos sites do Active Directory ou em diferentes. Além disso, o banco de dados e os caminhos do arquivo de log na origem e em todos os seus destinos devem ser correspondentes para cada grupo replicado com a SCR. Por fim, quando um nó ou um servidor está configurado como sendo um destino de SCR, não é possível habilitar a LCR para nenhum grupo de armazenamento no computador de destino da SCR e adicionar nenhum servidor de caixa de correio em cluster ao cluster de failover em espera.

Comparando a SCR com a CCR e a LCR

A SCR (como mostra a Figura 5) usa a mesma tecnologia de envio de logs e de repetição usada pela LCR e pela CCR para oferecer novas opções e configurações de implantação. Assim como acontece com a LCR e a CCR, os grupos de armazenamento com a SCR habilitada não podem conter mais de um banco de dados. Além disso, a SCR não pode ser usada em um banco de dados de pasta pública, caso haja mais de um banco de dados de pasta pública na organização do Exchange.

Figure 5** SCR is log shipping to another server or a passive node in a failover cluster **

Uma das principais diferenças em relação à SCR é que ela dá suporte a vários destinos por grupo de armazenamento, enquanto a LCR e a CCR dão suporte a apenas um destino (a cópia passiva). Outra grande diferença é que, diferentemente da CCR e da LCR, não é possível fazer o backup de uma cópia da SCR. Quando usa a SCR, os cabeçalhos do banco de dados referentes aos destinos da SCR são atualizados e os arquivos de log, truncados quando são feitos backups compatíveis no grupo de armazenamento de origem da SCR (ou, no caso da CCR e da LCR, quando os backups são feitos em cópias ativas ou passivas do grupo de armazenamento de origem da SCR).

Assim como a LCR e a CCR, o envio de logs com a SCR é contínuo e usa um modelo de pull. Assim que um novo arquivo de log é fechado e nomeado usando o número do arquivo de log em seqüência da próxima geração, o Serviço de Replicação do Microsoft Exchange em execução no computador de destino da SCR obtém os arquivos de log da transação fechada do computador de origem da SCR, os inspeciona e valida e, em seguida, os move para a pasta de arquivos de log do grupo de armazenamento em contraponto.

Tempo de latência repetido

Depois que os arquivos de log são copiados para o computador de destino da SCR, esta faz algo que a LCR e a CCR não fazem. Em vez de repetir imediatamente os arquivos de log na cópia do banco de dados, a SCR impõe uma latência de repetição interna de 50 arquivos de log e 24 horas. A SCR também lhe permite especificar um tempo de espera adicional além desses atrasos internos. Atrasar a atividade de repetição é útil em vários cenários. Por exemplo, em caso de dano lógico em um banco de dados ativo, um atraso pode impedi-lo no banco de dados de destino da SCR.

O atraso da repetição controlado por administrador é definido com um parâmetro chamado ReplayLagTime, que informa o tempo que o serviço de replicação do Exchange deve aguardar antes de repetir os arquivos de log que foram copiados para o computador de destino da SCR. O formato é Dias.Horas:Minutos:Segundos, e o valor padrão é de 24 horas. A configuração máxima permitida para o valor é de sete dias. Já a configuração mínima é de zero segundo, e definir esse valor como zero elimina efetivamente qualquer atraso na atividade de repetição do log além do atraso padrão de 50 arquivos de log.

Além de ReplayLagTime, o Exchange tem um atraso codificado interno de 50 arquivos de log, independentemente do valor de ReplayLagTime. Para determinar quando um arquivo de log deve ser repetido, o Exchange usa o maior de ReplayLagTime ou x arquivos de log, em que x=50. Trata-se de mais uma proteção para evitar a necessidade de propagar novamente um grupo de armazenamento em situações nas quais uma origem de SCR que usa a replicação contínua (por exemplo, um servidor de caixa de correio em cluster dentro de um ambiente de CCR) enfrenta um failover e um ou mais grupos de armazenamento precisam ser colocados online usando o cmdlet Restore-StorageGroupCopy. (Propagar é o processo de usar as APIs de backup de streaming do ESE (Mecanismo de Armazenamento Extensível) para criar uma cópia online do banco de dados de origem da SCR no computador de destino da SCR.) Com o atraso da atividade de repetição nos destinos da SCR, quando ocorre um failover com perdas em uma origem de SCR, as chances de que seja preciso propagar novamente as cópias da SCR serão minimizadas porque a natureza da perda de dados na origem da SCR junta as duas cópias de uma só vez.

Tempo de latência do truncamento

Na versão RTM do Exchange 2007, as regras são impostas em um ambiente de replicação contínua para que um arquivo de log não seja excluído, a menos que haja o backup dele e ele tenha sido repetido na cópia do banco de dados. Quando a SCR é usada, essa regra é modificada. A SCR (que introduz o conceito de várias cópias de bancos de dados) permite o truncamento dos arquivos de log no computador de origem da SCR assim que eles são inspecionados por todos os computadores de destino da SCR. O truncamento do log no servidor de origem da SCR não aguarda a repetição de todos os logs em todos os destinos da SCR porque as cópias de destino da SCR podem ser configuradas com tempos maiores de latência para a repetição do log.

Também é possível adicionar um atraso a mais ao truncamento do log usando um novo parâmetro chamado TruncationLagTime, que especifica por quanto tempo o serviço de replicação do Exchange deve aguardar (no formato Dias.Horas:Minutos:Segundos) antes do truncamento dos arquivos de log que foram copiados para o computador de destino da SCR e repetidos na cópia do banco de dados. O período começa assim que os arquivos de log são repetidos com êxito na cópia do banco de dados. A configuração máxima permitida para o valor é de sete dias, e a mínima é de zero segundo, embora zero segundo elimine efetivamente qualquer atraso na atividade de truncamento do log.

Em um ambiente da SCR, um thread em segundo plano é executado a cada três minutos para determinar se algum arquivo de log precisa ser truncado. Se a seqüência de geração do arquivo de log estiver abaixo do ponto de verificação do arquivo em relação ao grupo de armazenamento e o arquivo de log for posterior a ReplayLagTime + TruncationLagTime, um arquivo de log no destino da SCR será truncado.

Em um ambiente de LCR ou CCR estendido com a SCR, um arquivo de log no destino da SCR será truncado se estes quatro critérios forem atendidos: foi feito o backup do arquivo de log, a seqüência de geração do arquivo de log está abaixo do ponto de verificação do arquivo em relação ao grupo de armazenamento, a cópia passiva do grupo está em um estado que permite o truncamento do arquivo e todos os destinos da SCR inspecionaram o arquivo de log.

Habilitando e gerenciando a SCR

A SCR é habilitada com o cmdlet Enable-StorageGroupCopy no Shell de Gerenciamento do Exchange, que foi atualizado no SP1 com alguns parâmetros novos. Conforme a descrição anterior, ReplayLagTime e TruncationLagTime podem dar a você o controle sobre alguns comportamentos dos destinos da SCR. Outro parâmetro, SeedingPostponed, pode ser usado para ignorar a propagação inicial do destino da SCR. Adiar a propagação é útil em várias situações. Por exemplo, digamos que o banco de dados no grupo de armazenamento que está sendo habilitado para a SCR tenha 100 GB. Talvez você não queira que esses 100 GB de dados atravessem a rede durante os períodos de pico da produção. O parâmetro SeedingPostponed lhe dá a opção de habilitar a SCR imediatamente e de realizar uma tarefa de propagação mais tarde. Quando estiver pronto, você poderá propagar manualmente o destino da SCR usando o cmdlet Update-StorageGroupCopy.

Embora os parâmetros mencionados anteriormente sejam opcionais, um parâmetro de Enable-StorageGroupCopy é obrigatório para a SCR: StandbyMachine. Ele especifica o nome do computador que conterá o destino da SCR. O valor desse parâmetro é definido como parte do valor referente ao atributo msExchStandbyCopyMachines do grupo de armazenamento que está sendo habilitado para a SCR. O atributo msExchStandbyCopyMachines é uma cadeia de caracteres Unicode com vários valores adicionada ao esquema do Active Directory quando o Exchange 2007 SP1 é introduzido na organização do Exchange, que é um dos motivos pelos quais o SP1 exige uma atualização para o esquema do Active Directory.

O parâmetro StandbyMachine é básico na SCR, e vários cmdlets foram atualizados no SP1 para usar esse parâmetro na habilitação e no gerenciamento dos destinos da SCR. Os cmdlets atualizados estão descritos na Figura 6.

Figure 6 Cmdlets that use the Stand­by­Machine parameter

Ativando destinos da SCR

A SCR oferece uma ou mais cópias atualizadas dos dados, que podem ser usados caso os dados originais sejam perdidos ou inutilizados. O processo de criação de uma cópia de destino da SCR e de reprovisioná-la como um banco de dados de produção é chamado de ativação. A ativação ocorre como parte do processo de recuperação, que assumirá a forma de portabilidade do banco de dados ou de uma das duas opções de recuperação da configuração (/m:RecoverServer para recuperar um servidor autônomo ou /RecoverCMS para recuperar um servidor de caixa de correio em cluster).

Como você deve usar a SCR

Vejamos como uma empresa fictícia pode usar a SCR e a portabilidade do banco de dados na recuperação após uma falha em um banco de dados de caixa de correio. Após a identificação do dano no banco de dados de produção, o administrador ativa o banco de dados de destino da SCR usando a portabilidade do banco de dados.

A organização implantou o Exchange 2007 com SP1 e optou por usufruir a SCR para oferecer uma cópia de um grupo de armazenamento em um servidor de caixa de correio remoto. Os servidores de caixa de correio de origem e de destino estão no mesmo site do Active Directory e configurados para usar servidores DNS integrados ao Active Directory. O intervalo de replicação do Active Directory é configurado para 15 minutos.

Habilitando a SCR e preparando a recuperação

A SCR é configurada para que os arquivos de log da transação sejam replicados para um único grupo de armazenamento, SG1, que contém um único banco de dados, MBX1. Os caminhos para os arquivos do grupo de armazenamento e para o arquivo do banco de dados são C:\SG1 e C:\SG1\MBX1.EDB. Nesse caso, EXMBX1 é a origem da SCR e EXMBX2, o destino da SCR. Isso foi configurado como você vê aqui:

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

Após a habilitação da SCR, a integridade e o status da SCR para SG1 foram verificados com o cmdlet Get-StorageGroupCopyStatus:

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2

Para economizar tempo durante o processo de ativação do destino da SCR, EXMBX2 é pré-configurado com um grupo de armazenamento SG1PORT e o banco de dados MBX1PORT, que será usado como parte das operações de portabilidade do banco de dados. SG1PORT e MBX1PORT estão separados do grupo de armazenamento do destino da SCR e dos arquivos do banco de dados. Por isso, os caminhos para SG1PORT e MBX1PORT são configurados com um caminho temporário que não entra em conflito com os caminhos de destino da SCR. SG1PORT e MBX1PORT só serão usados como objetos de portabilidade do banco de dados; o grupo de armazenamento real e os arquivos do banco de dados para SG1PORT não são necessários. Por isso, o administrador desmonta MBX1PORT e exclui todos os arquivos do grupo de armazenamento. O grupo de armazenamento e os objetos do banco de dados permanecem no Active Directory porque serão usados posteriormente na portabilidade do banco de dados durante o processo de recuperação.

Ativação e recuperação

Uma entrada do log de eventos do aplicativo indica que o banco de dados de origem da SCR está danificado fisicamente. Como a SCR foi habilitada para SG1, é tomada a decisão de realizar uma ativação manual do banco de dados de destino da SCR para SG1 e de usar a portabilidade do banco de dados para restaurar a disponibilidade dos dados. A ativação da cópia de destino da SCR começa desmontando MBX1 em SG1 usando o seguinte cmdlet:

Dismount-Database EXMBX1\SG1\MBX1

Em seguida, a montagem do banco de dados de destino da SCR é viabilizada, e as caixas de correio originalmente em MBX1 são movidas para MBX1PORT.

O processo de desabilitação da SCR e de viabilização da montagem do banco de dados de destino da SCR envolvem a execução do cmdlet Restore-StorageGroupCopy. Essa tarefa marca o banco de dados do grupo de armazenamento como sendo montável e oferece um relatório sobre a perda de dados, caso haja alguma, resultante da montagem do banco de dados no grupo de armazenamento. Ele também verifica se todos os arquivos de log gerados pela cópia ativa do grupo de armazenamento estão presentes no local do arquivo do grupo de armazenamento da cópia passiva. Se algum arquivo de log não for encontrado, a operação também tentará copiá-lo. O seguinte cmdlet é usado para viabilizar a montagem do banco de dados de destino da SCR:

Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

No exemplo, os arquivos de log do grupo de armazenamento de origem da SCR estão disponíveis para cópia. Caso esses arquivos não estejam disponíveis (por exemplo, porque o computador de origem da SCR está desligado), o parâmetro Force deve ser adicionado à tarefa Restore-StorageGroupCopy. Do contrário, Restore-StorageGroupCopy sempre tentará se conectar à origem da SCR para copiar todos os arquivos de log não encontrados e, se a origem da SCR estiver indisponível, haverá uma falha na tarefa Restore-StorageGroupCopy e o banco de dados não será viabilizado para a montagem. Adicionar o parâmetro Force informa à tarefa Restore-StorageGroupCopy que os arquivos de origem não estão disponíveis, quando ela ignora a tentativa de conexão e continua viabilizando a montagem do banco de dados de destino da SCR.

Após a conclusão do comando Restore-StorageGroupCopy, o administrador deve verificar se o banco de dados está em um estado de desligamento normal. Caso o banco de dados esteja em um estado de desligamento anormal (consulte technet.microsoft.com/aa996757.aspx), ele deve ser colocado em um desligamento normal. Se o prefixo do arquivo de log do grupo de armazenamento (por exemplo, E00 ou E01) for o mesmo da origem da SCR (EXMBX1\SG1) e do grupo de armazenamento no destino da SCR (SG1PORT) a ser usado na portabilidade do banco de dados (EXMBX2\SG1PORT), não será necessário executar Eseutil no modo de recuperação, e a operação de montagem do banco de dados final o colocará em um estado de desligamento normal após a repetição de todos os arquivos de log replicados. Caso o banco de dados não esteja em um estado de desligamento normal, o modo de recuperação (Eseutil /r) do Exchange Server Database Utilities (Eseutil) deve ser executado no banco de dados.

Assim que o banco de dados estiver em um estado de desligamento normal, será possível executar dois comandos que atualizam o Active Directory com novos locais referentes aos arquivos do grupo de armazenamento e ao arquivo do banco de dados. Estes comandos alteram os caminhos para SG1PORT e MBX1 dos caminhos originais para os caminhos referentes ao grupo de armazenamento temporário e ao banco de dados (SG1PORT e MBX1PORT):

Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly

O parâmetro –ConfigurationOnly deve ser incluído nos comandos anteriores para que apenas as definições de configuração referentes a esses objetos sejam atualizadas no Active Directory. Nenhum dado ou arquivo é movido, e eles nem precisam ser porque a SCR já replicou os dados para C:\SG1 em EXMBX2.

A próxima etapa é configurar o banco de dados (MBX1PORT) para permitir que ele próprio seja substituído durante uma operação de restauração. Isso pode ser feito marcando a caixa de seleção da configuração "Este banco de dados pode ser substituído por uma restauração" nas propriedades do objeto de banco de dados no Console de Gerenciamento do Exchange ou usando o seguinte comando no Shell de Gerenciamento do Exchange:

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

Assim que você tiver configurado o banco de dados para que ele próprio seja substituído, a próxima etapa é montar o banco de dados usando o seguinte comando:

Mount-Database EXMBX2\SG1PORT\MBX1PORT

Após a montagem do banco de dados, as caixas de correio hospedadas no banco de dados de origem da SCR (SG1\MBX1) devem ser movidas de forma a apontar para MBX1PORT em EXMBX2. Basta executar o cmdlet Get-Mailbox e associar a saída ao cmdlet Move-Mailbox. Durante esse processo, é importante que o Atendedor do Sistema Exchange e as caixas de correio do sistema não sejam incluídos na saída do cmdlet Get-Mailbox associado ao cmdlet Move-Mailbox. Esses objetos de caixa de correio não precisam ser movidos e nem devem. O seguinte comando é executado para mover todas as caixas de correio do usuário e excluir as caixas de correio do sistema:

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT

Neste ponto, agora o acesso para cliente a MBX1PORT é possível. No entanto, a possibilidade dos usuários realmente acessarem suas caixas de correio depois que elas foram movidas de EXMBX1\SG1\MBX1 para EXMBX2\SG1PORT\MBX1PORT depende da latência de replicação do Active Directory; ou seja, dependendo do número de servidores de diretório, talvez a propagação da atualização em todo o ambiente demore um pouco. Além disso, os métodos de acesso para cliente importam. Os clientes de mensagens que estejam executando o Outlook 2007 e os que não estejam usando o Outlook terão acesso à caixa de correio do usuário depois que os servidores de diretório usados pelo servidor Acesso para Cliente forem atualizados com os novos caminhos. Os clientes de mensagens que estejam executando o Outlook 2003 e todas as versões anteriores exigirão que o perfil de mensagens da área de trabalho do usuário seja atualizado com o novo nome do servidor.

Etapas finais

Depois que os clientes tiverem acesso a caixas de correio e a dados de caixa de correio, a etapa final é estabelecer a redundância reabilitando a SCR. Isso é feito com a remoção de todos os grupos de armazenamento e dos arquivos de banco de dados restantes de EXMBX1. Após a remoção dos arquivos, os caminhos para EXMBX1\SG1\MBX1 podem ser movidos para um local temporário, e EXMBX1 pode se tornar um destino da SCR de EXMBX2.

Scott Schnoll é redator técnico chefe da equipe do Exchange Server na Microsoft, elaborando conteúdo para o Exchange Server 2007. Antes de trabalhar na Microsoft, Scott escreveu Exchange Server 2003 Distilled (Exchange Server 2003 Elaborado; Addison-Wesley Professional, 2004) e foi o autor-chefe do Exchange 2000 Server: The Complete Reference (Exchange 2000 Server: A referência completa; McGraw-Hill/OsborneMedia, 2001).

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..