none
Comment supprimer ancien domaine migrer sur office 365 RRS feed

  • Question

  • Bonsoir,

    J'ai une problématique sur un serveur exchange 2010 SP3.

    Ce serveur héberge plusieurs noms de domaine , un de ces noms de domaine a été migré sur office 365.

    J'ai supprimé le nom de domaine dans le transport hub ( j'ai vérifié avec le shell et également vérifié dans l'AD).

    J'ai supprimé le compte AD d'un utilisateur ainsi que la BAL pour faire un test.

    Le nom de domaine est toujours reconnu comme hébergé sur ce serveur Exchange.

    Les messages sont toujours distribués en interne sur l'exchange local et non vers office 365.

    Message de non remise dans le cas de cet utilisateur (#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found )

    J'ai fais une recherche sur pas mal de forums sans résultat, avez vous une idée de l'attribut à modifier afin d'indiquer au système de router les messages de ce nom de domaine vers l'extérieur.

    Bonne soirée.

    jeudi 15 mai 2014 19:06

Toutes les réponses

  • Bonjour,

    Le domaine de messagerie doit être retiré des domaines acceptés. Je suppose que cela a été fait. 

    Vérifiez ensuite que la zone DNS ne soit pas définie sur les serveurs DNS internes, ni dans le fichier HOSTS d'Exchange. Redémarrez les services DNS pour vider le cache.

    Ensuite, seuls les utilisateurs dont l'adresse email de ce domaine est encore définie recevront encore les messages directement. Pour l'utilisateur migré, la résolution DNS devrait pointer vers Internet, si la zone DNS publique est bien configurée.

    A+

     


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(79 MCPs). https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660
    http://base.faqexchange.info

    jeudi 15 mai 2014 19:24
    Modérateur
  • Bonsoir,

    La problématique reste la même, j'ai nettoyé les entrées DNS ultérieurement et supprimé l'entrée dans " domaines acceptés"

    deux types de messages d'erreurs : #5.7.1
    smtp; 550 5.7.1 Unable to relay> #SMTP#

    #550
    5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

    Et cela renvoyé par le serveur Exchange interne.

    Les mails de tests ont été envoyé à partir d'un client interne.

    jeudi 15 mai 2014 20:24
  • Bonjour,

    pour que les messages partent, ils doivent être envoyés a partir de clients Outlook(configurés en mode Exchange) ou a partir d'adresses provenant d'un domaine autorisé  pour des clients authentifiés.

    Il ne semble pas que ce soit le cas.

    A+ 


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(80 MCPs). MCSA Office 365 <a href="https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660">https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660</a><br/> <a href="http://base.faqexchange.info">http://base.faqexchange.info</a>

    vendredi 16 mai 2014 06:42
    Modérateur
  • Je pense que vous pouvez avoir deux problématiques liés à ce type de migration :

    En interne d'Exchange, il n'y a pas de notion de domaine accepté, une adresse interne peut être utilisée par tout utilisateur interne, indépendamment du nom de domaine accepté. Vous devez enlever *toutes* les adresses smtp des utilisateurs internes qui portent ce domaine.

    D'autre part, il y a plusieurs mécanismes de cache dans Outlook qui font qu'un email envoyé à un domaine précédemment hébergé peuvent etre remis en interne sur l'adresse LegacyExchangeDN. Il faut nettoyer le cache de saisie semi-automatique, et éviter d'utiliser toutes les réponses à des messages reçus en interne précédemment.


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    vendredi 16 mai 2014 08:41
    Modérateur
  • Bonjour,

    Merci pour votre aide.

    Côté client Outlook celui que j'utilise est dédié à ce test donc pas de problème de cache.

    En ce qui concerne DNS tout a été nettoyé, les adresses SMTP et BAL ont été supprimé.

    En interne les mails destinés à ces utilisateurs externe sont toujours routé vers l'exchange interne et toujours le même message d'erreur

    Votre
    message n'a pas été remis, car le fournisseur de messagerie du destinataire l'a
    rejeté. 

    #5.7.1 smtp; 550 5.7.1 Unable to relay> #SMTP# sur un alias d'une BAL

    #550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ## sur une ancienne BAL existante et fonctionnelle sur 365

    Un cas d'école ? :)

    Je continue les investigations pour els idées, je suis preneur.

    Merci bien.


    • Modifié Eric_support vendredi 16 mai 2014 11:36 complément d'information
    vendredi 16 mai 2014 11:33
  • Il est important de déterminer si le message d'erreur est généré par le serveur local ou le serveur distant pour les 2 messages indiqués.

    Ceci ne semble pas clair!

    Y-a t-il eu redémarrage? Régénération d'une nouvelle liste globale? d'un carnet d'adresse Hors ligne?


    Thierry DEMAN. Exchange MVP. MCSE:Messaging 2013,MCSE:Server Infrastructure 2012(80 MCPs). MCSA Office 365 https://mvp.microsoft.com/en-us/mvp/Thierry%20Deman-7660 http://base.faqexchange.info

    vendredi 16 mai 2014 16:04
    Modérateur
  • Bonsoir,

    Après vérification, c'est le carnet d'adresse hors connexion qui ne se met pas à jour.

    J'ai exécuté  

    Get-Globaladdresslist | Update-Globaladdresslist

    Get-Offlineaddressbook | Update-Offlineaddressbook

    Sans aucun résultat.

    J'ai par contre une erreur dans les journaux d'événements concernant IIS.

    Un canal de l'écouteur pour le protocole 'http' du processus de travail '10040' servant le pool d'applications 'DefaultAppPool' a signalé l'échec d'un canal de l'écouteur. Le champ des données contient le numéro de l'erreur.

    Je suppose que le dysfonctionnement vient de D'IIS soit dans le stockage ou la mise à jour des fichiers LZX soit dans la diffusion de ce carnet.

    Le serveur a été redémarré.

    dimanche 18 mai 2014 18:00
  • Bonjour,

    Le problème est réglé.

    Il s'agissait du carnet d'adresse hors connexion qui ne s'était pas mis à jour.

    Malgré le faite de le forcer en shell , la mise à jour a été faite dans la nuit.

    Le service de surveillance est bien fonctionnel.

    Merci bien pour vos conseils.

    Cdt.

    lundi 19 mai 2014 08:42