none
Exchange migration interforêt - utilisateurs déjà présents sur forêt cible

    Question

  • Bonjour,

    Je crée ce topic, qui en suit un autre, afin de pouvoir se concentrer sur le problème qu'il me reste à prévoir.

    Résumé du contexte :

    1. Historiquement, une société A avec la forêt A.com hébergeait ses utilisateurs et la messagerie sur Exchange 2013.
    2. Par la suite société A a racheté une société B avec une forêt B.com qui hébergeait ses utilisateurs. Pas de messagerie.
    3. Des BAL ont été créées pour les utilisateurs de la forêt B sur l'Exchange A. En bref la forêt A héberge la messagerie pour tout le monde. 
    4. On a donc les comptes en double : Un sur la forêt B, pour l'accès de l'utilisateur à son domaine. Ce même utilisateur possède un autre compte sur la forêt A juste pour sa messagerie.
    5. Le besoin se fait sentir de séparer les environnements de messagerie. Un Exchange va être installé sur forêt B et un migration Exchange 2013 vers 2016 se prépare.

    Solution Technique envisagée :

    Je me suis renseigné et lu de nombreuses documentation sur la migration Exchange interforêt. Cela a l'air extrêmement simple. En très rapide : 

    • Le proxyMRS est utilisé comme point de terminaison
    • le script déjà fourni sur exchange prepare-moverequest.ps1 permet de créer un "mail user" sur l'exchange cible
    • A la fin du move-request, la mailbox source se transforme en "mail user". Comme ça pas de soucis de routage.

    La problématique :

    Toutes les documentation que je vois parte du principe que l'AD cible est vide :)

    l'utilisateur de messagerie cible se transforme en mailbox à la fin de la migration avec son nouveau compte AD. Eventuellement un coup d'ADMT est passé pour mettre à jour les attributs et mots de passes.

    Mais qu'en est il si les comptes AD sont déjà présents sur la forêt cible ? C'est bête mais il semble que ce scénario ne soit pas prévu par microsoft ?

    Peut on lier les utilisateurs AD présents lors de la migration plutôt que d'utiliser un "mail user" ?

    Ou peut on utiliser une solution intermédiaire ?

    Du genre :

    1. je migre mes BALs, les nouveaux utilisateurs AD sont créés.
    2. Déconnexion de la BAL de l'utilisateur AD (disable-mailbox)
    3. connexion de la BAL sur le bon utilisateur AD (connect-mailbox)

    Et encore je risque d'avoir des soucis car les samaccount name sont souvent les même que les utilisateurs locaux...

    Dans l'idéal  je souhaiterais éviter les migrations par PST car delta trop important à gérer entre le début et la fin de la migration et problèmes de routage entre les BAL migrées et non migrées...


    Merci à vous si vous arrivez à me sortir de cet impasse...

    Quelqun a une idée ?

    merci d'avance.

    mardi 16 avril 2019 13:08

Toutes les réponses

  • Bonjour, il y a dans l'article ci-dessous la réponses à vos questions:

    http://itnyou.fr/migration-inter-foret-exchange-2013-vers-exchange-2013/


    Cordialement.


    • Proposé comme réponse Romain.D mardi 16 avril 2019 17:04
    • Modifié Franck Fouché mardi 16 avril 2019 17:55
    mardi 16 avril 2019 13:35
  • Bonjour,

    Pour le "éventuellement ADMT", il faut lire "Il faut utiliser ADMT!!!"...

    En fait, c'est dans ADMT qu'il faut gérer cet aspect des choses:

    - Soit autoriser la fusion si le compte existe déjà

    - Soit créer un nouveau compte en cas de doublon.

    C'est le "Move-mailbox" qui gérera la mise à jour des attributs propres à la messagerie.

    A bientôt


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(85 MCPs). MCSA Office 365 http://base.faqexchange.info

    mardi 16 avril 2019 16:25
    Modérateur
  • Merci Thierry pour la précision, erreur de ma part. :) 

    Cordialement.

    mardi 16 avril 2019 18:11
  • Merci messieurs pour vos réponses.


    Du coup si je comprends bien il suffit lier le compte AD cible non pas à une mailbox mais à un mailuser. Et le Prepare-MoveRequest.ps1 sera capable de lier la mailbox source avec le mailuser cible, sans en recréer un nouveau. Nickel :)

    Simplement avec la commande suivante sur exchange cible puis  switch -UseLocalObject dans le prepare-moverequest.ps1:

    "Enable-MailUser -Identity user1@mondomainecible.com -ExternalEmailAddress user1@mondomainesource.com"

    Question : Cette méthode est supportée par Microsoft ou c'est une bidouille ? Pour faire simple en cas de souci pendant la migration aurais je moyen d'appeler Microsoft ?

    @Thierry : Pour le coup je ne comprends pas bien l'utilisation d'ADMT dans ce cas. Pourquoi l'utiliser ?

    Surtout que de mémoire ADMT ne synchronise pas les attributs de messagerie.

    Est ce que ça ne va plutôt poser problème dans l'environnement cible ? (qui je le rappel est en production).

    J'ai notemment peur que ça remplace ceci :SID, droits d'accès, attributs déjà remplis, apartennance aux groupes, etc...

    Bref, pourquoi utiliser ADMT si au final Prepare-MoveRequest.ps1 peut lier la mailbox source avec le mailuser enabled de l'utilisateur cible comme vu ci dessus ?

    Enfin j'ai une dernière question, est il possible que pendant ou après la migration, les utilisateurs migrés puissent continuer à utiliser quelque temps le nom de domaine source pour l'envoie de leurs mails ? Pourront ils toujours contacter les utilisateurs qui ne sont pas prévu dans la migration sur l'Exchange source ? (problématique de routage).

    Merci par avance

    mercredi 17 avril 2019 10:54
  • Bonjour,

    ADMT permet justement d'ajouter le SID de l'ancienne forêt dans un champ appelé "SIDHistory".

    Cela permet de s'assurer que le compte migré continue à bien bénéficier de tous les accès qu'il avait dans l'ancien domaine, et aussi sur les ressources migrées (Messagerie, Serveurs de fichiers, ...).

    ADMT peut être modifié pour synchroniser la totalité des informations, notamment la messagerie, mais cela n'est pas souhaitable dans ce cas.

    Sinon, par défaut, les messages peuvent être transférés entre les 2 messageries. Mais, Il est parfois nécessaire d'utiliser des domaines de messagerie fictif/supplémentaires si l'on veut définir un même domaine de messagerie dans les 2 organisations Exchange.

    A+


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2012(85 MCPs). MCSA Office 365 http://base.faqexchange.info

    mercredi 17 avril 2019 21:16
    Modérateur
  • Merci Thierry,

    Pour rappel sur le besoin : les comptes sources n'ont accès uniquement à la messagerie sur la forêt source. Rien d'autres. Le but étant justement de rapatrier uniquement les boites mails et les lier avec les comptes cibles existants sur la forêt de destination et qui eux ont des accès sur leur environnement. Même le mot de passe ne doit pas être migré, les utilisateurs utiliseront enfin leur mot de passe de session habituel pour la messagerie. Je ne vois donc pas de nécessité à utiliser ADMT. Sauf si vous m'expliquiez que cela est nécessaire techniquement pour la migration des mailbox.

    Du coup reste la question de routage en gardant temporairement ( quelques mois le temps de gérer la communication avec les clients et partenaires) les adresses par défaut (adrsses de réponse)  avec le même nom de domaine Du coup :

    1 - Sur le nouveau système de messagerie pour envoyer/Recevoir des mails avec le domaine d'origine vers l'extérieur (clients par exemple) :

    => envoie : J'imagine qu'il suffi d'ajouter au pointeur SPF du domaine d'origine l'adresse IP utilisée pour l'envoie.

    =>  Réception : Si le client répond, le mail arrivera sur le système de messagerie sources, mais grâce au mailuser créé lors de la migration, le mail sera routé vers le système de messagerie cible.

    Mon analyse est elle bonne ?

    2 - Pour envoyer/Recevoir des mails entre les 2 organisations, comment est ce possible ?

    -pour l'envoie depuis l'exchange source j'imagine que le mail user permet de router vers l'exchange cible ?

    -Pour l'envoie depuis l'exchange cible, faut il créer manuellement un mail user pour chaque boite mail hébergée sur l'exchange source ?

    Je ne sais pas si je suis bien clair dans mes explications. N'hésitez pas à me corriger. En fait ce que je ne voudrais surtout pas, c'est que suite à la migration on ai des rejets du genre "la boite mail n'existe pas". Parce que

    -côté serveur source, étant autoritaire sur le domaine de messagerie, reçois un mail à destination d'un utilisateur qui a été migré, ne le trouve pas (normal il a été migré).

    -côté serveur cible, qui est aussi autoritaire sur le même domaine de messagerie (pour pouvoir envoyer des mails avec des adresses dans ce domaine). Si un utilisateur qui souhaite joindre un utilisateur du serveur source, idem "la boit mail n'existe pas".

    Bref j’espère ne pas vous avoir embrouillé, merci d'avance pour votre aide sur ce dernier point qui nous pose un vrai soucis.

    jeudi 18 avril 2019 08:07
  • Bonjour,

    Je me dis que je vous ai peut être embrouillé avec mes explications. Pour faire simple : après migration j'ai temporairement besoin que les utilisateurs migrés se trouvant sur le nouveau serveur puissent envoyer et recevoir avec et depuis des adresses dans le domaine source.

    Si j'ajoute le domaine source faisant autorité sur mon nouveau serveur, je pense que je pourrais envoyer (ajout champ dans le SPF pour éviter la blacklist), et recevoir grâce aux utilisateurs de messagerie correspondant sur la forêt source.

    Mais dans ce cas on aura un problème pour contacter les utilisateurs sur l'Exchange source. Avez vous une solution ?

    Je me demande, si je rentre le domaine en tant que "relai interne" sur Exchange, ça fonctionnerait ? Comme ceci :

    Qu'en pensez vous ?

    En résumé mon but : j'envoie un mail à un utilisateur user@domainesource.fr.

    • Si la BAL  se trouve  sur mon nouveau serveur alors OK le serveur peut remettre
    • Si la BAL se trouve sur l'ancien serveur, alors le serveur va chercher le MX pour envoyer le mail à destination de l'ancien serveur qui se débrouillera pour la remise.

    Pensez vous que ça peut fonctionner de cette manière ?

    mercredi 24 avril 2019 15:52