Entendendo Mailbox Moves em Ambientes Cross-Premises (Office 365)

By: Caio Ribeiro César / Technical Reviewer: Eduardo Tavares de Almeida

Este artigo faz uma referência à documentação da Microsoft que pode ser acessada atraváves dos links abaixo:

Understanding Move Requests

Start the MRSProxy Service on a Remote Client Access Server

Neste post irei descrever o processo de mailbox move em um ambiente de coexistência com o O365.

O ambiente on-cloud Office 365 da Microsoft roda em Exchange 2010, portanto quando efetuamos um move mailbox entre mailbox databases, o processo é executado pelo Microsoft Exchange Mailbox Replication Service (que será tratado como MRS).

O MRS é um serviço que é executado nos Exchange 2010 CAS servers e é o serviço que irá receber o move request do administrador e mover a mailbox de uma database para outra. O MRS suporta os mailbox moves sendo eles online ou offline, em um ambiente cross-premisse este move é considerado online.

Este é um exemplo de como um move request (simples) é executado:

image

  1. O administrador cria o move request utilizando o New-MoveRequest;

  2. O New-MoveRequest efetua as validações necessárias na mailbox que será movida;

  3. O New-MoveRequest cria uma mensagem de request que é inserida no DB do target server;

  4. Os seguintes atributos são adicionados na conta do usuário, para armazenar informações que serão utilizadas pelo move e que serão atualizadas durante o processo:

    • msExchMailboxMoveBatchName
    • msExchMailboxMoveFlags
    • msExchMailboxMoveRemoteHostName
    • msExchMailboxMoveSourceMDBLink
    • msExchMailboxMoveStatus
    • msExchMailboxMoveTargetMDBLink
  5. 1- O New-MoveRequest aciona o MRS informando que uma nova requisição de move está pronta para o processamento;

  6. 2- O MRS atualiza o atributo msExchMailboxMoveStatus do objeto no AD;

  7. 3- O MRS inicia o sincronismo de data;

  8. 4- Assim que o sincronismo é completo, o MRS irá efetuar o “lock” da account;

  9. 5- Após o lock, o MRS iniciará o delta, aonde será feito o sincronismo de mensagens novas ou de itens alterados;

  10. 6- O MRS irá então atualizar os atributos no AD para o mailbox enabled user (nova account criada):

  11. HomeMDB

  12. HomeMTA

  13. HomeServer

  14. MSExchangeVersion

  15. Proxy Address

  16. 7- O MRS remove a source mailbox do source DB e altera o move status do msExchMailboxMoveStatus e msExchMailboxMoveFlags para “Completed”;

  17. 8- Assim que este status for atualizado, a mailbox pode ser acessada;

  18. 9- No Exchange 2010, cada instância do MRS mantém um track dos move requests. Esta fila pode ser acessada utilizando o comando “Get-MoveRequestStatistics”, como é o exemplo abaixo:

Get-MoveRequestStatistics "Exchange Server" –MoveRequestQueue “User-Mailboxes”

MRSProxy

No Exchange 2007, quando administradores tinham que efetuar mailbox moves entre diferentes florestas (cross-forest environment), era necessário habilitar o acesso MAPI entre os servidores, configurar trusts e habilitar o full administrator access para os administradores em ambas as Exchange Organizations. O processo para esta versão está detalhado neste link.

O MRSProxy trabalha em conjunto com o MRS para facilitar a comunicação requerida entre o source e target server em cada floresta de Exchange Server 2010. Cada CAS server posssui uma instância do MRS e uma instância do MRSProxy como uma parte da implementação do Exchange Web Services (EWS). A grande diferença é que o MRSProxy não vem habilitado por default no CAS server.

Portanto, para efetuar um move em um ambientes cross premise ou até em um cross forest, é necessário habilitar este serviço. Para habilitar este serviço, basta configurar o arquivo de configuração (web.config) para o CAS on-premise. Lembre-se de habilitar para ambos os CAS nodes se você possui um array configurado.

Habilitando o MRSProxy

1. No servidor on-premise, abra o arquivo de configuração com o seu notepad:

<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config

2. Altere a configuração de IsEnabled de False para True:

<!-- Mailbox Replication Proxy Server configuration -->
<MRSProxyConfiguration
IsEnabled="False"
MaxMRSConnections="100"
DataImportTimeout="00:01:00" />

3. Salve e feche o arquivo;

4. Reinicie o serviço do MRS e o IIS para que as alterações tenham efeito.

Mail Enabled User (MEU)

No processo aonde as contas dos usuários são criadas no ambiente on-cloud utilizando o DirSync, temos que nos certificar de que os Mail Enabled Users criados na target forest (online) estão com os atributos mínimos requeridos para que o MRS efetue suas tarefas.

O DirSync se encarrega de criar os seguintes requisitos dos Mail Enabled Users :

- O MEU é criado na floresta de destino (Microsoft Online Directory Service);

- O valor de msExchMailboxGUID, que indica a GUID da mailbox do usuário, é estampado no MEU criado online;

- O valor de msExchArchiveGuid é criado no MEU criado online caso exista um archive habilitado;

- O valor de LegacyExchangeDn é estampado no MEU criado online;

- O valor de Mailnickname é populado no MEU criado online;

- O valor de msExchArchiveName é configurado no MEU criado online caso exista um archive habilitado;

- O MEU deve estar ativo com uma licença válida.

Agora que sabemos a teoria de um move mailbox e das alterações feitas para a melhora do serviço no Exchange 2010, irei detalhar o processo de migração de mailbox entre premises (O365).

Pré requisitos:

a) Para efetuar um mailbox move entre um ambiente on-premise e um ambiente O365, temos que ter certeza de que já configuramos o DirSync (ele se encarregará de criar o UPN e outros atributos dos usuários);

b) Ao menos um Exchange Server 2010 SP1;

c) O MRSProxy deve estar habilitado;

d) É recomendado que o Federation Trust com o Microsoft Federation Gateway esteja configurado;

e) É recomendado que você tenha um Organization Relationship (irá facilitar o processo, com o relationship configurado não teremos que prover as credenciais de acesso em cada remote move).

Caso você tenha um Organization Relationship configurado, não esqueça de habilitar o mailbox move para não que a autenticação não seja solicitada em cada move request:

On-premise:

- Execute o cmdlet:

Set-OrganizationRelationship -Identity "Cloud" -MailboxMoveEnabled $True

O365:

- Execute o Windows PowerShell para se conectar no Exchange Online Services (maiores detalhes de como efetuar este procedimento neste link);

- Se autentique como seu usuário da cloud ($Cred = Get-Credential);

- Crie uma sessão remota:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $Cred -Authentication Basic –AllowRedirection

- Importe a sessão:

Import-PSSession $Session

- Habilite o serviço:

Set-OrganizationRelationship -Identity "On-prem" -MailboxMoveEnabled $True

f) Um certificado emitido por uma CA externa e importado para o CAS (EWS) do ambiente on-premise. Este certificado deve ser confiável para ambas as organizações.

Cross Premise Move Request – Workflow:

Em um ambiente cross-forest, o remote move request é acionado no target server. Em um cross-premise, na maioria das vezes, os moves serão originados do on-premise.

Em um resumo, o processo pode ser dividido em nove etapas:

  1. O New-RemoteMoveRequest é iniciado no ambiente on-premise (EMS/EMC). Isto irá forçar a autorização do administrador para efetuar a operação. O MRS do O365 será responsável por receber o move request pelo MRSProxy;
  2. O MRS do ambiente online valida o matching do MailEnabledUser com a mailbox que será migrada (pelo valor configurado em MsExchMailboxGUID);
  3. O MRS do ambiente online irá criar a mailbox para o usuário que será migrado;
  4. O MRSProxy do ambiente online irá contatar o ambiente on-premise para encontrar a source mailbox (novamente, utilizando o MsExchMailboxGUID);
  5. O MRS informa ao MRSProxy (source forest) de que a mailbox foi localizada. O MRSProxy da source forest então contata o MRSProxy da target forest informando que a mailbox foi encontrada;
  6. O MRS do ambiente online então abre uma conexão web services (EWS) com o on-premise CAS;
  7. O conteúdo localizado na mailbox do source user é sincronizado para o target forest . O MRSProxy se encarrega da comunicação entre os dois ambientes, esta comunicação é feita pelo EWS:
    • Migrar a estrutura de diretórios;
    • Migrar os dados;
    • Migrar as configurações de conta e atributos.
  8. Assim que as informações são movidas para a mailbox account do ambiente online, esta mailbox é convertida para uma remote mailbox;
  9. A target mailbox é convertida de Mail Enabled User para Mailbox Enabled User.

Hands on: migrando as mailboxes on-premise para on-cloud

O move pode ser efetuado pelo Exchange Management Shell ou Exchange Management Console.

Assumindo que os pré-requisitos já foram revistos, podemos iniciar a migração.

  1. Adicione a floresta do Exchange Online Services para o EMC do seu ambiente on-premise e configure os domínios corretamente:
    1. Selecione Microsoft Exchange no topo da hierarquia;
    2. Selecione a opção Add Exchange Forest;
    3. Adicione o Friendly Name (como esta nova floresta será nomeada no seu Management Console);
    4. Especifique o FQDN, selecione “Exchange Online” e clique em “Ok” ;
    5. Se autentique com a conta de administrador do Online Services;
    6. Abra a organização (Organization Configuration) que foi adicionada;
    7. Selecione o HUB Transport > Remote Domains;
    8. Em Actions, selecione a opção “New Remote Domain” ;
    9. Adicione as informações do novo remote domain:
      • Name = Nome do Remote Domain;
      • Domain Name = Domínio on-premise;
      • Selecione a opção “Use this domain for my on-premise deployment”.
    10. Selecione a opção “New”.
  2. Agora precisamos adicionar o domínio Online como um Remote Domain válido para o ambiente on-premise:
    1. Abra a organização (Organization Configuration) on-premise;
    2. Selecione o Hub Transport > Remote Domains;
    3. Em Actions, selecione a opção “New Remote Domain” ;
    4. Adicione as informações do novo remote domain:
      • Name = Nome do Remote Domain;
      • Domain Name = Domínio online;
      • Selecione a opção “Use this domain for my BPOS tenant” .
    5. V. Selecione a opção “New”.
  3. Se você ainda não habilitou o MRSProxy, siga os passos descritos anteriormente para ativar este serviço;
  4. Inicie o mailbox move (assumindo que você já tenha criado o seu Mailbox Enabled User no ambiente on-premise e que você tenha executado o DirSync com sucesso e o Mail Enabled User está pronto para o move):
    1. Vá para o Exchange Management Console > Recipient Container, clique com o botão direito do mouse no mailbox enabled user que será migrado e selecione a opção “New Remote Move Request”;
    2. Especifique o que irá ser movido (somente a mailbox/somente o archive mailbox/ambos);
    3. Configure corretamente as opções de Connection Configuration:
      • Target Forest = Nome adicionado no step 1, IX;
      • O FQDN do serviço do MRS deve ser aquele configurado no CAS on-premise que possui o MRSProxy habilitado. Este endereço deve ser acessível para acesso externo, já que o CAS do O365 irá efetuar a comunicação com este endereço.
      • Adicione as credenciais de administrador (on-premise);
    4. Selecione a opção “Next”;
    5. Na opção “Target Delivery Domain” , adicione o FQDN que foi inserido no segundo passo;
    6. Selecione a opção “New”;
    7. Nesta nova página, você terá o status do request. Assim que o setup finalizar, você pode selecionar a opção finish.

Podemos monitorar os requests de move pelo EMC > Recipient Container > Move Requests. Se você clicar no move request, uma nova janela aparecerá trazendo os detalhes do request e até o log do move request. Também podemos utilizar o Get-MoveRequestStatistics para acompanhar o move.

Notas/FAQ:

  1. O comando de “Move-Mailbox” introduzido no Exchange 2007 foi removido do Exchange 2010. Agora utilizamos o New-MoveRequest;

  2. A utilização de um certificado público não é necessária em um move mailbox em um ambiente cross forest. Neste ambiente, podemos utilizar certificados de uma CA interna (desde que ambos os certificados sejam válidos para ambas as organizações). Recebemos algumas ligações de clientes com problemas de certificado, neste caso o sequinte erro será gerado:

    “The call to 'https://server1.contoso.com/EWS/mrsproxy.svc' failed. Error details: Could not establish trust relationship for the SSL/TLS secure channel with authority ' server1.contoso.com’. --> The underlying connection was closed”

    1. Esta mensagem de erro nos informa que o certificado utilizado no EWS do servidor “server1.contoso.com” não é confiável para o servidor que acessa a URL (ou que executa o New-MoveRequest);
    2. O certificado deve ser importado e confiável em ambos os lados (tanto o CA certificate quanto o root certificate), portanto:
      • Exporte os certificados do source/target servers (utilizado pelo CAS – EWS);

      • Exporte o root certificates do source/target CA’s;

      • Importe os certificados do target server (root CA do target para o Trusted Root Certification Authorities e o certificado do EWS do target botão direito>Importar ) para o source server;

      • Importe os certificados do source server (root CA do target para o Trusted Root Certification Authorities e o certificado do EWS do target botão direito>Importar ) para o target server;

      • Certifique-se que você consegue abrir ambos os endereços sem problemas de certificado:

        https://SOURCECAS/EWS/mrsproxy.svc
        https://TARGETCAS/EWS/mrsproxy.svc

    3. Em um Offline move, o processo é similar ao que foi demonstrado no exemplo deste artigo, porém a mailbox não será acessível duranto o processo de move;
    4. O MRS possui uma configuração de high availability que pode ser acessada no MSExchangeMailboxReplication.exe.config:
      • DataGuaranteeCheckPeriod: Controla o tempo em que o MRS irá efetuar o “check” com o Active Manager. O tempo default é de 5 minutos, o máximo é de 2 horas e o mínimo é de 30 segundos.
      • EnableDataGuaranteeCheck – Habilita o MRS para validar no active manager o status das mailbox databases. O valor by default é “true”.
    5. Utilizamos o Test-MRSHealth para validar o status dos serviços MRS.