Where Are You Coming From Today?
Follow us on:
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:
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:
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.
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:
“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”
https://SOURCECAS/EWS/mrsproxy.svc https://TARGETCAS/EWS/mrsproxy.svc