Fase 1: Assessment

 

• URLs do Exchange Server

Outro porto importante para mapearmos é entender como são publicadas as URLs do Exchange. Para isso podemos usar os comandos abaixo:

 get-AutodiscoverVirtualDirectory
 get-ClientAccessServer
 get-webservicesvirtualdirectory
 get-oabvirtualdirectory
 get-owavirtualdirectory
 get-ecpvirtualdirectory
 get-ActiveSyncVirtualDirectory

No meu caso, a topologia era definida como single namespace, resumindo; seria todas as URLs configuradas como mail.contoso.com

Fazendo uma simples consulta ao DNS do google, pude obter o endereço externo do mail.contoso.com

Como até esse ponto eu já sabia que existia uma regra de balanceamento no BigIP apenas para a entrada SMTP, obviamente esse IP XXX.XXX.XXX.77 seria também um NAT no BigIP para fazer o balanceamento HTTP entre os dois CAS que existem na organização.

Um ponto importante a ser observado, a organização deve utilizar split-brain DNS – ter uma zona com o nome externo no DNS interno. Caso não tenha, já deixe isso como um ponto a ser feito na fase de implementação.

• Quantidade e tamanho dos e-mails diário da organização.

Certamente o cliente ira te questionar sobre a quantidade de e-mail trocados diariamente. Além disso, o cliente precisa mensurar se o link atual será suficiente após a migração ou não.  Para isso, temos algumas formas de obter esses números. Usei um script para obter os números que eu precisava.

Existe também esse script, porem confrontando os números entre os dois scripts, notei que havia uma grande diferença.

Para saber qual dos dois scripts chegava mais próximo da exatidão, acabei fazendo um trabalho manual de tracking e confrontando os números. Dessa forma, pude ver que o primeiro script – Email stats – era o que me atendia da melhor forma.

Um outro ponto para quem usa o MessageLabs é que na ferramenta é possível gerar relatórios da quantidade de e-mails enviados para fora da organização e recebidos de fora da organização – obviamente ele não consegue mensurar os e-mails internos.

• Quantidade de Mailbox

É claro que esse é um ponto óbvio pois geralmente quando somos chamados para realizar o projeto, a organização já comprou as licenças – em boa parte dos casos – do Exchange Online. Dessa forma, alguém já contabilizou a quantidade de mailbox para poder realizar a compra da quantidade de licenças necessárias. Contudo, como nada na vida do consultor é fácil, nesse projeto mesmo em que estou me baseando, a empresa havia comprado 2.000 licenças de Exchange online, sendo que existem 2.600 mailboxes On-Premises. E aí, o que fazemos? Como sempre, sobra para o consultor fazer o milagre, mesmo que em matemática não exista milagre rsrs.

Analisando a estrutura de OU da organização, notei existia uma OU chamada “Shared Mailbox”. Olhando as configurações dessas mailboxes que estavam nessa OU, notei que realmente eram mailboxes com permissões de Full Access e Send As, porem o tipo delas não era Shared e sim UserMailbox.

E em que isso influencia? Licenças. Uma Shared Mailbox não necessita de uma licença no Office 365.

Sendo assim, ofereci ao cliente a opção de conversão dessas Mailboxes para Shared. Informei que isso poderia ter impacto, se uma pessoa utiliza essa conta para se logar no domínio e abrir o Outlook ou OWA, essa pessoa perderia o acesso, pois ao realizar a conversão automaticamente a conta no AD da Shared Mailbox é desabilitada. Isso equivale o mesmo para aplicações que utilizam mailbox.

O cliente aceitou a conversão, e obviamente algumas aplicações sofreram impacto, pois se enquadravam na situação que eu mencionei. Dessa forma acabamos fazendo rollback de algumas Mailboxes.

• Nome do domínio

No geral, as empresas tendem a usar nomes de domínio “não roteáveis”. Isso significa que o nome do domínio não corresponde ao mesmo nome externo que a empresa utiliza. Por exemplo:

Nome Externo: contoso.com

Nome do domínio: Contoso.local

De fato, no passado isso era uma pratica comum e até mesmo referida como melhores práticas na criação do domínio. Essa configuração impacta diretamente na sincronização entre o AD e o Azure AD, sendo os nomes diferentes, não é possível sincronizarmos.

Como forma de contorno para essa situação, a Microsoft recomenda que se crie então um sufixo do nome externo no AD, e que o UPN dos usuários seja alterado para o sufixo. Existe um step-by-step da propria Microsoft para isso.

OBS: Sugiro atenção ao utilizar esse script mencionado no artigo acima, o script irá encontrar tudo que seja *@contoso.local e mudar para @contoso.com. Tive problemas com isso relacionado a usuários de aplicação que o UPN era por exemplo: httpcontoso.local@contoso.local. Nesse caso, o script mudou não só do arroba para frente, e sim o nome UPN do usuário, ficando: httpcontoso.com@contoso.com. Isso me ocorreu com uma média de 10 usuários de aplicação. Inclusive usuários que envolviam a autenticação da aplicação de proxy, fazendo haver a indisponibilidade de navegação para todos os usuários. A dica que eu dou aqui é a seguinte, faça um export de todos os nomes UPN dos usuários da organização. Posteriormente veja que nenhum se enquadra nesse exemplo que citei, isso lhe fara evitar horas de troubleshooting e indisponibilidade.

Outro detalhe importante a ser considerado é que o valor principal de identificação do usuário no Office 365 será o UPN e não o e-mail. Justamente por esse motivo, a Microsoft recomenda como boa pratica que o UPN dos usuários seja igual ao e-mail deles. Ou seja, se o e-mail do usuário for: denis.signorelli@contoso.com e o UPN for DSIGNORELLI@contoso.com, o valor principal de identificação no Office 365 será o DSIGNORELLI@contoso.com.

Para não haver problemas de confusão na cabeça dos usuários, a boa pratica é que o UPN corresponda ao mesmo valor do e-mail. Geralmente as perguntas corriqueiras sobre esse assunto são:

Qual o impacto em mudar o UPN do usuário?

A nível de acesso no Windows nenhum. Nunca vi nenhum usuário logando no Windows com o UPN, por padrão todos utilizam o SAM Account Name (CONTOSO\DSIGNORELLI). Haverá impacto se algum usuário da organização se loga com o UPN. Visto que nunca ocorre, digamos que não existe impacto a nível de logon. O que ocorre as vezes são aplicações que utilizam o UPN para se autenticar, aí sim alterar o UPN haverá impacto.

Posso deixar do jeito que está? A resposta é sim, é possível deixar o UPN diferente do e-mail. O maior problema nesse caso, será educar os usuários a utilizarem os serviços do Office 365 com o UPN ao invés do e-mail.  

Existe alguma outra opção para não alterar e utilizar o e-mail como campo de identificação? Sim, a Microsoft introduziu a opção de Alternate Logon ID. Basicamente isso faz com que o Office 365 reconheça o atributo email como identificação. O Alternate Logon ID possui algumas limitações, sugiro a leitura do link para entender quais. Particularmente sugiro que seja evitado o uso.

Sugiro também a leitura desse artigo, no qual cita detalhadamente os prós e contras em mudar ou não mudar UPN diferentes do e-mail.