Assessment – Parte 1
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
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.