O365 Cloud Identity – Atributos do Exchange não são sincronizados para o Office 365.


Por: Cesar Hara, Caio Ribeiro Cesar

 

Frequentemente ajudamos clientes que enfrentam problemas para sincronizar objetos do AD on-premise para o O365.

Um dos cenários é quando qualquer atributo de usuário é sincronizado, menos os atributos relacionados ao Exchange.

Essa situação na maioria dos casos acontece por causa de uma regra padrão que existe no Azure AD Connect chamada “In from AD – User Exchange”:

Para verificar a regra, abra a console do Synchronization Rules Editor, navegue até a regra e clique em Edit, clique em “No” na próxima janela mas não faça nenhuma alteração:

1

2

Como podemos observar, a regra não irá sincronizar nenhum atributo de Exchange caso o atributo “mailNickname” esteja vazio.

Um cenário onde isso pode acontecer é quando você precisa sincronizar algum atributo do Exchange porém não existe ou nunca existiu um Exchange local, e a conta em questão nunca teve uma mailbox.

A solução para este cenário, é preencher o atributo mailNickname do objeto através do ADSIEdit.msc* ou Active Directory Users and Computers. Navegue até a localicação do objeto e verifique se o atributo contém algum valor (se utilizar o dsa.msc, garanta que a opção de “Advanced Features” está marcada em “View”):

3

Este valor é preenchido por padrão com o sAMAccountName, portanto seria interessante manter este padrão: https://technet.microsoft.com/en-us/library/cc539081.aspx

Após inserir o valor no atributo, basta realizar uma sincronização do Azure AD Connect para que o objeto seja sincronizado com sucesso para o Office 365.

*É importante ressaltar que a utilização da ferramenta “adsiedit” para a gerência de objetos do Exchange/Exchange Online não é algo suportado pela Microsoft. Temos um índice de clientes que efetuam o decomission do Exchange On-Premises após a migração para a nuvem e, logo após, solicitam a suportabilidade para a gerência de objetos com o adsiedit. No cenário discutido neste artigo, a utilização da ferramenta (ou do próprio Active Directory) é algo suportado para a resolução deste problema – este cenário muitas vezes ocorre em ambientes sem Exchange Server On-Premises, porém com o Exchange schema extension efetuado no AD e os objetos sincronizados para a nuvem (geralmente feito pelo administrador para se obter o atributo msExchHideFromAddressLists). Já no cenário de decomission de Exchange, devido ao fato de também termos que remover o serviço de sincronismo, o Source of Authority será alterado para o O365 e a gerência de objetos deve ocorrer na cloud (portal) – desta maneira, não existindo a suportabilidade de adsiedit para gerência de objetos.

Comments (0)

Skip to main content