Problème de remise du courrier une fois la boîte aux lettres est migrée vers Office 365 dédié/ITAR (vNext)

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3189107
Symptômes
Une fois votre boîte aux lettres est déplacée vers Microsoft Office 365 dédié/réglementation ITAR (vNext), vous rencontriez les problèmes suivants :
  • Vous ne recevez pas de tout votre courrier électronique.
  • Lorsque quelqu'un tente de vous envoyer des courriers (l’utilisateur nouvellement migré), ils reçoivent un rapport de non-remise (NDR).
Cause
Dans le cadre du processus de déplacement à vNext, les objets sont figés dans l’ancien environnement dédié. Si un utilisateur n’est pas correctement congelé, MMSSPP continue à mettre à jour le targetAddress et proxyAddresses les attributs et ce peut provoquer un problème de remise du courrier.
Résolution
Migrations à partir de legacy dédié à vNext sont organisées et configurées avec les ressources de déploiement de Microsoft. Ce processus implique les étapes suivantes pour vous assurer que la migration est effectuée plus efficacement et avec aussi peu d’effet sur l’utilisateur final que possible :
  1. Initiale du processus d’écriture différée (actuellement manuel * et complété par Microsoft)

    Certaines informations de l’annuaire (par exemple, msExchMailboxGuid et publicDelegates) doivent être transférés à partir de l’annuaire dédié à Azure Active Directory. Pour ce faire, les informations requises sont extraite de l’annuaire dédié et écrites dans votre répertoire actif sur place. À partir de là, DAS Sync/connexion est utilisée pour transférer les informations jusqu'à le nuage. Cette écriture différée effectuées manuellement et la coordination avec les ressources de déploiement de Microsoft avant la migration.
  2. Objet dans vNext de licence et de fournir aux utilisateurs par lots à l’équipe EXO (client)

    Dès que le processus d’écriture différée est terminé, le client prendra des mesures au lot et licence les objets en exécutant le script fourni par l’équipe de service EXO dans la documentation de configuration. Étant donné que la msExchMailboxGuid élément est copié à partir de legacy dédiée sur site AD vNext, cela empêche une nouvelle boîte aux lettres en cours de mise en service et permet de s’assurer que le déplacement est effectué avec succès.

  3. Gel des boîtes aux lettres (manuelle, complétée par Microsoft)

    Avant de soumettre les déplacements, les boîtes aux lettres sont figées. Par conséquent, la targetAddress et proxyAddresses propriétés sont ne sont plus mis à jour par MMSSPP. Après le déplacement, la boîte aux lettres source sera configuré par le Service de réplication de boîtes aux lettres (Mme) pour vous assurer que continue de remise du courrier. Ces attributs doivent rester congelés définitivement après la migration afin d’éviter toute modification.
  4. Amorçage préalable (Mme)

    Un groupe de boîtes aux lettres va être inclus dans un lot de migration fourni par le client pour les ressources de déploiement de Microsoft. Remplir plusieurs semaines avant que la boîte aux lettres est migré afin que la nouvelle boîte aux lettres peut être déjà amorcée dans vNext.
  5. Migration finale (Mme)

    Le déplacement de boîte aux lettres est effectué sur la date et l’heure demandée par le client.
  6. Écriture différée finale (actuellement manuel *, effectuée par Microsoft)

    Dans les trois jours ouvrables, une écriture différée finale sera terminée. Les propriétés mises à jour sont targetAddress, msExchRecipientTypeDetails, msExchRemoteRecipientType, msExchRecipientDisplayTypeet proxyAddresses.
S’il existe un rapport de courrier électronique des problèmes de livraison après la migration, vous devez collecter les informations suivantes :
  • Des rapports non remise (NDR), si disponible

Passez en revue la configuration de l’objet dans l’ancien environnement dédié. L’objet doit être un RemoteUserMailbox avec un attribut ExternalEmailAddresset d’un suffixe de *. onmicrosoft.com :
get-recipient john@contoso.com | fl ExternalEmailAddress,RecipientTypeDetails
ExternalEmailAddress          : SMTP:john@contoso.onmicrosoft.comRecipientTypeDetails          : RemoteUserMailbox

Adresse ExternalEmailAddress doit être une adresse de messagerie de la boîte aux lettres vNext.

S’il existe des problèmes que l’objet source dans legacy dédié est mal configurée, veuillez faites appel à Microsoft pour des recherches supplémentaires.

* Un projet est en cours d’exécution pour automatiser le processus d’écriture différée. L’automatisation est mis en place, dès que les écritures différées seront effectue en continu et étapes supplémentaires seront inutiles.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3189107 - Dernière mise à jour : 09/05/2016 02:50:00 - Révision : 2.0

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

  • vkbportal226 kbmt KB3189107 KbMtfr
Commentaires