Fase 1: Assessment

Como todo projeto de migração, é de suma importância que façamos um assessment para mapear o ambiente atual. Isso deve inclusive servir de base para elaborar o desenho do ambiente no futuro.

• Verificar versão atual do Exchange Server e nível funcional do domínio/floresta

É importante que se verifique a versão atual do Exchange Server e o nível funcional da floresta e domínio da organização. Nem todas as versões do Exchange Server podem ser utilizadas como Hybrid. Para ver os requisitos, sugiro a leitura de ambos os links abaixo:

https://technet.microsoft.com/en-us/library/hh534377(v=exchg.150).aspx

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequisites

A partir disso então, deve ser feito o desenho de como será o ambiente hibrido da organização, por exemplo se a versão atual do Exchange Server atende ou não o requisito para ser hibrido, ou deverá ser feita a instalação de uma versão mais nova.

Para as organizações que possuem versões 2003 ou 2007 do Exchange Server, poderá ser solicitada uma licença gratuita para manter de modo hibrido o Exchange. Claro que alguns pré-requisitos devem ser seguidos, veja aqui se a organização é elegível a licença.

Update 09/2018: A licença free hybrid (de graça) ainda existe, entretanto não se requer mais através do portal. O próprio Hybrid Wizard ofereçe a opção de licenciar o Exchange Server caso ele detecte que o cliente se enquadra nos requisitos para obtê-la. Segue o artigo da Microsoft para maiores detalhes.  

• Verificar utilização de permissões Full Access, Send As e Send On Behalf

Muitas vezes o cliente não tem ideia das limitações que podem haver em um ambiente hibrido. Por isso cabe a nós explicarmos o que atualmente está funcionando, e não funcionara de modo hibrido.

Quando falamos de permissões Cross-premises, isso significa permissões entre usuários que estão no O365 e usuários que estao on-prem.  Algumas coisas funcionam e outras não, irei listar abaixo o que deve ser claro para o cliente, para que não haja aquele, “Mas você não me disse isso”.

1 – Full Access: Funciona em modo cross-premises e é suportado pela Microsoft.

Nota: Por padrão, ao conceder full access permission, o usuário receptor da permissão mapeia automaticamente a mailbox do outro usuário, essa feature se chama Auto-Mapping. Essa feature entretanto não é suportada pela Microsoft em caso de coss-premises. Nos meus testes, quem já havia a permissão on-prem e foi migrado ao 365 permaneceu com o Auto-mapping. Porém, se você der a permissão no momento em que os usuários estão em cross-premises, o auto-mapping não funcionara.

2 – Send As: A Microsoft se restringe a dizer que não é suportado. Entretanto, existe um workarround no qual é possível fazer funcionar, seria aplicar a permissão no Exchange Online e também no Exchange On-Premises, dessa forma é possível realizar Send As

3 – Send On Behalf: É suportado a partir da versão 1.1.553.0 do Azure AD Connect.

No geral, ao migrar as mailboxes ao Exchange Online, as permissões acima citadas permanecem em funcionamento. Entretanto para evitar problemas, a Microsoft informa que o ideal é migrar usuários que possuem permissões dentro do mesmo batch de migração, de modo que eles cheguem todos juntos ao Exchange Online, e não separados.

Para isso, extrai um relatório com os comandos abaixo, e contei com a ajuda do Excel para obter as informações que eu precisava:

Get-Mailbox -Resultsize Unlimited | Get-ADPermission | where { ($_.ExtendedRights -like “*Send-As*”) -and ($_.IsInherited -eq $false) -and -not ($_.User -like “NT AUTHORITY\SELF”) } | Select Identity, User, Deny | Export-CSV Send_As.csv

Get-Mailbox -Resultsize Unlimited | Where-Object {$_.GrantSendOnBehalfTo} | select Name,@{Name='GrantSendOnBehalfTo';Expression={($_ | Select -ExpandProperty GrantSendOnBehalfTo | Select -ExpandProperty Name) -join ","}} | export-csv Send_On_Behalf.csv

• Entender como funciona o fluxo de e-mail na organização

É crucial que seja feito um desenho detalhado de como funciona atualmente o fluxo de e-mail na organização. No caso do meu exemplo, temos uma organização que utiliza o MessageLabs – Symantec Cloud.Security – como AntiSpam. A pergunta que não quer calar é; mas como desvendamos qual é o exato fluxo SMTP da organização se o próprio cliente não tem mapeado essas informações? Simples, com logs e alguns detalhes nós conseguimos obter esses detalhes.

O primeiro ponto é saber para onde aponta o atual MX record da organização. Para isso nós podemos contar com a ajuda do MXToolbox que pode nos trazer rapidamente essa informação. No meu caso, pude ver que a entrada do fluxo de e-mail da organização era o feita através do MessageLabs.

Sabendo que a entrada de e-mails é feita através do MessageLabs, me restava saber como era feita a saída de e-mails. No caso do MessageLabs e de algumas outras soluções de Anti-Spam e Anti-Virus, nós temos a opção de configurar a saída de e-mails por essas soluções. Assim prevenimos a organização não apenas de receber spams mais também de fazer spam. A fim de ver se a saída de e-mails está sendo feita através de uma solução de Anti-Spam, basta procurarmos se existe algum smart host configurado no Send Connector do Exchange

Como no exemplo acima, vemos que toda saída e e-mails para destinatários externos é roteada para o endereço do MessageLabs. Portanto até esse ponto, já possuímos duas informações importantes. A primeira por onde é feita a entrada dos e-mails da organização, e a segunda é por onde é feita a saída.

Precisamos também conhecer a infraestrutura atual do Exchange Server na organização. No caso do meu ambiente, temos as seguintes configurações:

2 Servidores com as roles de CAS e HUB Transport.

2 Servidores com a role de Mailbox Server.

Se existem 2 CAS/HUB, bem provavelmente teremos também alguma solução de Load Balance. Nesse caso, para termos certeza disso, o ideal então é ver dentro do MessageLabs qual o IP configurado para o envio de e-mail. Contudo, uma segunda opção seria checar o cabeçalho de uma mensagem enviada de fora para dentro da organização. Podemos encontrar qual é o IP cuja o qual o MessageLabs envia a mensagem após a varredura.

No caso desse cabeçalho, conseguimos ver que a mensagem chega do MessageLabs com o IP XX.XX.XX.205. Vendo o IP, notei que não era um IP externo e sim interno, então pude entender que se tratava de um NAT. O firewall fazia a conversão do IP público do Load Balance – no caso um F5 BigIP – que no MessageLabs era configurado como YY.YYY.YYY.YY e internamente era convertido para XX.XX.XX.205.