Peguei recentemente uma situação muito interessante: usuários que logam com um UPN na rede interna e possuem outro UPN para endereço de e-mail com a necessidade de transicionar de domínio no Office 365. Neste cenário, temos usuários que já foram migrados do Lotus Notes Domino Server para o Office 365 e já têm sua estrutura de mensagens funcionando através de um foward no Lotus Notes redirecionando todo o fluxo de mensagens para o domínio de provisionamento “dominio.onmicrosoft.com” então temos que tomar cuidado com as particularidades envolvidas neste tipo de migração.

 
Para que entendam este cenário de forma mais abrangente, vou informar aqui alguns pontos importantes desta migração.
Nota: A solução de migração adotada, neste caso, foi MigrationWiz de Lotus Notes Domino Server para Exchange Online – Office 365.

A migração é do tipo Staged, pois a organização definiu migrar por lotes departamentais e sentir segurança no ambiente Microsoft Exchange com as caixas migradas e aos poucos migrar o restante. Vale lembrar que a migração Staged é recomendada nestas situações aonde o cliente se sente mais confortável e seguro adotando este modelo que visa permitir um acompanhamento gradual e sólido da transição de plataforma. Neste modelo os usuários absorvem com mais tempo o conceito da nova interface e novas ferramentas que o Outlook-Outlook Web App entregam e dividem uma experiência “prévia” com aqueles colegas de trabalho que serão migrados depois, mas já terão uma ideia de como trabalhar com a nova plataforma ao ver seus colegas de trabalho migrados descobrindo e aprendendo os recursos.
Pois bem… como a migração é do tipo faseada e tanto as caixas que foram migradas para o Exchange quanto as caixas que continuam no Lotus Server têm que funcionar; de forma alguma no processo de implantação, podemos registrar o MX do Office 365. Do contrário, todo o fluxo de mensagens dos usuários que têm caixa no Lotus Server (ou seja, que ainda não foram migrados para Exchange) pára de funcionar e os usuários param de receber/enviar e-mails.
Observação: Todos os outros registros (TXT, SPF, CNAME e SRV) podem ser apontados no DNS externo conforme orienta a console administrativa de domínios do Office 365 normalmente.
Veja como passa a funcionar o fluxo de mensagens após a migração das primeiras caixas:

No servidor Lotus Notes Domino Server deve haver um foward para o endereço “user1@dominio.onmicrosoft.com” no office 365. Desta forma a organização passa a fornecer os dois serviços de e-mail até o final da migração com 100% das caixas no Exchange Online.
Claro que mostrando desta forma parece simples montar este tipo de ambiente, mas todas as etapas de configuração do Lutos Notes Domino Server,Lotus Extractor, MigrationWiz e Exchange Online – Office 365 devem ser levadas em consideração. Atentem-se para o fato de que para isto acontecer o servidor de DirSync já deve estar implementado e sincronizando os objetos com sucesso. Os campos dos atributos de objetos no AD devem estar corretamente populados bem como os atributos de objeto no ADS Edit como o ProxyAddress, por exemplo. Nesta minha migração levei em consideração ainda a implantação de SSO – Single Sign On em uma farm com 2 servidores de ADFS em Load  Balancing.
Bom, Ok! Usuários migrados e com caixas totalmente funcionais no Exchange Online. Neste ponto da migração surgiu uma nova necessidade (que me fez desenvolver este artigo técnico): usuários que logam com um UPN na rede interna e possuem outro UPN para endereço de e-mail com a necessidade de transicionar de domínio no Office 365.
Observem a estrutura da floresta de domínios deste meu caso para que entendam melhor:

Levando em consideração que o User 1, quando foi sincronizado e migrado, logava como

• “dominiopai\User1”
• ou “dominiofilho1\User1”
• ou “dominiofilho2\User1”
• ou “dominiofilho3\User1”
• ou “user1@dominio.com.br” (através da relação de confiança que têm que ser criada em Domains and Trusts com os domínios válidos para a internet) na rede local e possuía seu endereço de e-mail como “usuario1@dominio.com.br”, devemos considerar este escopo quando formos transicionar o User 1, no Office 365, para usar o “dominio2.com.br”.

Para fazer o User 1, que responde hoje pelo SMTP Principal “user1@dominio.com.br”, passar a responder como SMTP Principal “user1@dominio2.com.br”  é necessário que:

• O dominio2.com.br esteja validado na console administrativa de domínios do Office 365
• O dominio2.com.br esteja adicionado como um domínio confiável de internet em Active Directory Domains and Trusts para que possamos, mais tarde, trocar de UPN na guia Account das propriedades do objeto usuário.

Observem agora como o User 1 está funcionando antes da transição domínios:
 

Neste ponto, devemos usar o PowerShell para “quebrar” a federação do domínio “dominio.com.br” forçando o UPN a adotar o domínio de provisionamento “dominio2.onmicrosoft.com”. Para isso, iremos usar o cmdlet Set-MsolUserPrincipalName -UserPrincipalName user1@dominio.com.br -NewUserPrincipalName user1@dominio2.onmicrosoft.com

Notem que eu só posso quebrar uma federação de um usuário que loga na rede com um UPN (user1) e tem outro UPN como endereço de e-mail (usuario1) usando SEMPRE o UPN que ele usa para logar na REDE INTERNA primeiro.
Se for tentar logar no portal com este usuário já não terá mais sucesso pois a federação foi quebrada e o ADFS não funciona mais para este usuário até que seja rodado o cmdlet que atribua um domínio federado novamente ao usuário.
Vamos agora atribuir o domínio final (que é o domínio pelo qual o usuário passará a responder como SMTP Principal):
Rode o comando: Set-MsolUserPrincipalName -UserPrincipalName user1@dominio2.onmicrosoft.com -NewUserPrincipalName usuario1@dominio2.com.br
Notem, desta vez, que além de eu reinserir o usuário em um domínio federado novamente, agora eu consigo setar o UPN de endereço de e-mail correto (usuario1@dominio2.com.br).
Isso tudo é necessário porque o ID que o Office 365 reconhece ao usuário ser sincronizado pelo DirSync é o interno (como ele loga no portal e na rede interna) e o endereço de e-mail é o SMTP Principal. Isso tem que estar bem claro para quem estiver migrando, do contrário se deparará com diversas telas de erro do PowerShell.
Precisamos alterar todos os atributos do objeto no AD para quando houver sincronia de diretórios, as alterações sejam refletidas na nuvem:
Primeiro, na guia General das propriedades do User 1, altere o atributo do campo E-mail para o novo endereço de e-mail do usuário:
Antes

Depois

Depois, na guia Account, modifique o domínio do UPN de rede do usuário selecionando o novo domínios à qual ele responderá como endereço de e-mail principal no Exchange Online:
Antes

Depois

Importante: Percebam que o UPN de rede interna do usuário não foi e não deve ser alterado pois impactaria no ambiente caso este usuário possua alguma aplicação que utilize o UPN de rede interna.

Agora modificamos os atributos de ProxyAddress via ADS Edit:
Antes:

Depois

Importante: não esquecer de setar o SIP conforme o SMTP para organizações com implantações que contemplam assinaturas de Lync Online.

Rodamos uma sincronização forçada no servidor de DirSync (Delta Sync ) para que ele as alterações que fizemos no primeiro passo no AD e ADS Edit sejam atualizadas na nuvem com o cmdlet: Start-OnlineCoexistenceSync
Nota: Você pode acompanhar as etapas da sincronização de diretórios tanto pelo Event Viewer do seu Windows Server quanto pelo FIM – Forefront Identity Manager.
Após sincronização feita, já se nota o sucesso da operação com os UPN’s e SMTP corretos do User 1 no Exchange Online:




Quando o User 1 tenta logar no portal com o dominio 2, vejam que a federação de domínios (SSO – Silgle Sign On) da farm de servidores ADFS volt a funcionar:


Sucesso!
Aparentemente tudo resolvido, mas não acaba por aqui não… Devemos deixar o ambiente redondinho nos atentando aos seguintes pontos após a alteração:

• Para usuários que utilizam o Outlook Client (2007/2010/2013), é necessário configurarmos um novo perfil e limparmos o cache off-line do Catálogo Global de Endereços na máquina do usuário para que ele não visualize mais os endereços antigos de antes da transição em relação à outros usuários que passaram pelo mesmo procedimento e puxe o novo catálogo atualizado. O Outlook solicitará autenticação 3 vezes: no wizard de configuração do novo perfil de e-mail, ao finalizar a criação do novo perfil e ao reiniciar o Outlook (que é quando ele começa a baixar a mailbox).
• Para usuários que utilizam o Lync Client (2010/2013), é necessário forçar a sincronização com o servidor de Lync Online indo em Ferramentas>Opções>Pessoal>Minha conta>Avançado:

Em “Configuração manual”, setar sipdir.online.lync.com:443 tanto em “Nome do servidor interno ou endereço IP” quanto em “Nome do servidor externo ou endereço IP”

• Verificar se a solução de Firewall está barrando a conexão, tentar conexão e setar o novo endereço SIP e no próximo log-on do Lync voltar as configurações para automático.

Espero que seja de ajuda, forte abraço e até o próximo artigo!