Objeto no se sincronizan como usuario con correo habilitado desde locales AD en Office 365 dedicado/ITAR

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 3186692
Síntomas
En Microsoft Office 365 dedicado/ITAR, en locales o correo dedicado antiguos aparece como un usuario en AD de Azure. Esta situación puede afectar a la entrega de correo dentro de vNext o mailfrom Internet a través de la protección en línea de Exchange.
Causa
Este problema se produce si la propiedad mailNicknameno tiene un valor establecido en los servicios de dominio de directorio local activo (AD DS).
Solución
En Azure Connect de AD, un valor debe establecerse para la propiedadmailNicknameun usuario de Exchange. La pantalla siguiente captura filtro de ámbito de showsthe predeterminado.
Una captura de pantalla de esta página de filtro de ámbito

Si se ha establecido ningún valor, el objeto está sincronizado a Azure Active Directory como un usuario y el objeto no tendrá las propiedades de correo establecidas en Exchange.

Whomove de los clientes a vNext desde heredados dedicado puede tener algunos objetos que no tienen un valormailNicknameestablecida. Las reglas de sincronización se utilizan por Microsoft Managed Services Service Provisioning proveedor (MMSSPP) no requieren una propiedadmailNicknameexiste en el objeto en los locales en AD DS. MMSSPP utiliza el valor de la propiedadSamAccountName para usuarios y grupos. Objetos de contacto se establecen en un valor igual a su atributo givenName.sn .

Antiguos clientes dedicados deben establecer un valor en sus instalaciones en AD DS para todos los objetos, o cambiar el predeterminado ámbito filtro en Azure Connect de AD.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 3186692 - Última revisión: 08/19/2016 16:11:00 - Revisión: 1.0

Microsoft Business Productivity Online Dedicated, Microsoft Business Productivity Online Suite Federal

  • vkbportal226 kbgraphic kbgraphxlink kbmt KB3186692 KbMtes
Comentarios