none
Ajout d'un 2e serveur Exchange en vu de supprimer le 1er RRS feed

  • Question

  • Bonjour, 

    Voilà ma problématique : 

    Actuellement nous avons un serveur Exchange 2013 (machine virtuelle) hébergé sur un autre site (chez iWeb).

    Appel d'offre oblige, nous devons maintenant aller avec OVH (je suis dans le public au Canada). Nous devons donc migrer notre serveur Exchange de iWeb chez OVH.

    Ma première solution serait de monter un 2e serveur Exchange chez OVH puisque notre nouveau serveur est déjà disponible. Une fois installé une réplication entre les 2 serveurs se feraient. Une fois complètement répliqué je pourrai éteindre et enlever le 1er serveur Exchange.

    Pensez-vous que c'est une bonne solution ? Aussi, je suppose qu'il faut installer tous les rôles sur le 2nd serveur Exchange.

    Ma 2e solution aurait été de copier la VM Exchange puis de migrer sur notre nouveau serveur physique chez OVH. Mais j'ai peur qu'il y ait des problème puisque nous aurons une adresse MAC différente avec notre nouvelle VM puisque OVH attribue automatiquement l'adresse MAC avec l'IP publique.

    Merci de m'éclairer.

    Philippe 

    mercredi 26 octobre 2016 14:03

Réponses

  • Bonjour,

    Oui la premiere proposition peut etre la bonne solution, du moment où vous configurer le 2e serveur dans la meme organisation que le 1er serveur.

    Vous devez configurer l'ensemble des URLs et autres services à l'identique sur ce serveur et les faire pointer sur la "ferme" dans un premier temps. Vous pourrez ainsi migrer l'ensemble des boites aux lettres (ne pas oublier les boites administration 'audit', 'federation'....etc...)

    Une fois que vous êtes prêt à la bascule, vous switcher l'ensemble des services sur le nouveau serveur et la "migration" sera transparente pour vos utilisateurs.

    La bonne pratique est d'arrêter le premier serveur avant de le deco.

    Merci


    Hakim Taoussi - Consultant Exchange - http://exchangediscover.blogspot.fr

    mercredi 26 octobre 2016 14:23
  • Merci Hakim pour votre réponse.

    Que voulez-vous dire sur 'pointer les URLs sur la 'ferme' ? 

    La migration des boîtes se fera automatiquement via la réplication entre les 2 serveurs, non ?  Je pensais laisser les deux serveurs en service durant quelques jours le temps que la réplication se fait.

    Quelle est la solution pour migrer toutes les boîtes aux lettres ? La base de données (.edb) est un seul fichier.

    Merci d'avance.

    Bonjour,

    Notez bien : que le DAG (Data avaibility group) , est un mécanisme de réplication de la base entre les serveurs Exchange qui hébergent le rôle boite de lettre afin d'assurer la haute disponibilité du serveur en cas de panne de l'un des serveurs.

    la communication entre les clients Outlook est géré via IIS, pour cela il faut toujours bien configurer les répertoire virtuelle du serveur Exchange afin d'éviter l’interruption de service ( connexion outlook , webmail..)

    Comme proposé par Hakim, vous pouvez commencer installer un nouveau serveur Exchange avec les mêmes rôle (mailbox, CAS)  , puis créer une nouvelle base sur le nouveau serveur et configurer les répertoires virtuels avec l'identique  que l'ancien et ensuite commencer migrer les boite de lettre. c'est totalement transparent si vous avez bien configurer les URL des répertoires virtuels.

    Configuration du serveur d’accès au client Exchange 2013

    mercredi 26 octobre 2016 15:01
    Modérateur
  • Bonsoir,

    il est possible et souvent préférable de créer plusieurs banques, et donc plusieurs fichiers EDB !!!

    En revanche, la migration d'une boîte est une tâche courante entre 2 serveurs Exchange et/ou banques d'information différente. Elle se fait schématiquement "boîte par boîte", plusieurs déplacement simultanés étant possible.

    => Cette opération réplique de manière masquée la totalité de la boîte, puis supprime la source si tout s'est bien passé, et met à jour les informations correspondantes dans AD. Le profil de l'utilisateur est mis à jour automatiquement..

    Les utilisateurs peuvent communiquer entre eux pendant la migration, et Exchange sait toujours grâce à AD où se trouve la boîte de l'utilisateur.

    Le DAG implique une configuration plus complexe et surtout le souhait de conserver cette configuration à terme. Sinon, on se rajoute des problèmes inutiles.

    A bientôt,


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

    mercredi 26 octobre 2016 16:39
    Modérateur

Toutes les réponses

  • Bonjour,

    Oui la premiere proposition peut etre la bonne solution, du moment où vous configurer le 2e serveur dans la meme organisation que le 1er serveur.

    Vous devez configurer l'ensemble des URLs et autres services à l'identique sur ce serveur et les faire pointer sur la "ferme" dans un premier temps. Vous pourrez ainsi migrer l'ensemble des boites aux lettres (ne pas oublier les boites administration 'audit', 'federation'....etc...)

    Une fois que vous êtes prêt à la bascule, vous switcher l'ensemble des services sur le nouveau serveur et la "migration" sera transparente pour vos utilisateurs.

    La bonne pratique est d'arrêter le premier serveur avant de le deco.

    Merci


    Hakim Taoussi - Consultant Exchange - http://exchangediscover.blogspot.fr

    mercredi 26 octobre 2016 14:23
  • Merci Hakim pour votre réponse.

    Que voulez-vous dire sur 'pointer les URLs sur la 'ferme' ? 

    La migration des boîtes se fera automatiquement via la réplication entre les 2 serveurs, non ?  Je pensais laisser les deux serveurs en service durant quelques jours le temps que la réplication se fait.

    Quelle est la solution pour migrer toutes les boîtes aux lettres ? La base de données (.edb) est un seul fichier.

    Merci d'avance.

    mercredi 26 octobre 2016 14:28
  • Merci Hakim pour votre réponse.

    Que voulez-vous dire sur 'pointer les URLs sur la 'ferme' ? 

    La migration des boîtes se fera automatiquement via la réplication entre les 2 serveurs, non ?  Je pensais laisser les deux serveurs en service durant quelques jours le temps que la réplication se fait.

    Quelle est la solution pour migrer toutes les boîtes aux lettres ? La base de données (.edb) est un seul fichier.

    Merci d'avance.

    Bonjour,

    Notez bien : que le DAG (Data avaibility group) , est un mécanisme de réplication de la base entre les serveurs Exchange qui hébergent le rôle boite de lettre afin d'assurer la haute disponibilité du serveur en cas de panne de l'un des serveurs.

    la communication entre les clients Outlook est géré via IIS, pour cela il faut toujours bien configurer les répertoire virtuelle du serveur Exchange afin d'éviter l’interruption de service ( connexion outlook , webmail..)

    Comme proposé par Hakim, vous pouvez commencer installer un nouveau serveur Exchange avec les mêmes rôle (mailbox, CAS)  , puis créer une nouvelle base sur le nouveau serveur et configurer les répertoires virtuels avec l'identique  que l'ancien et ensuite commencer migrer les boite de lettre. c'est totalement transparent si vous avez bien configurer les URL des répertoires virtuels.

    Configuration du serveur d’accès au client Exchange 2013

    mercredi 26 octobre 2016 15:01
    Modérateur
  • Bonsoir,

    il est possible et souvent préférable de créer plusieurs banques, et donc plusieurs fichiers EDB !!!

    En revanche, la migration d'une boîte est une tâche courante entre 2 serveurs Exchange et/ou banques d'information différente. Elle se fait schématiquement "boîte par boîte", plusieurs déplacement simultanés étant possible.

    => Cette opération réplique de manière masquée la totalité de la boîte, puis supprime la source si tout s'est bien passé, et met à jour les informations correspondantes dans AD. Le profil de l'utilisateur est mis à jour automatiquement..

    Les utilisateurs peuvent communiquer entre eux pendant la migration, et Exchange sait toujours grâce à AD où se trouve la boîte de l'utilisateur.

    Le DAG implique une configuration plus complexe et surtout le souhait de conserver cette configuration à terme. Sinon, on se rajoute des problèmes inutiles.

    A bientôt,


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

    mercredi 26 octobre 2016 16:39
    Modérateur
  • Bonjour, merci pour votre réponse.

    Pensez-vous qu'il serait plus judicieux de copier la VM et de la migrer vers le nouveau site ? 

    Une fois migrer nous aurions juste besoin de changer l'adressage IP.

    Cordialement.

    mercredi 26 octobre 2016 17:06
  • Euh, pas forcément.

    L'inconvénient d'une copie, surtout à travers Internet, est de provoquer une interruption très longue.

    Après déplacement, la reconfiguration (IP, DNS public, ...) ne sera pas non plus totalement sans douleur.

    On préfère généralement préparer (tranquillement) la nouvelle machine dans l'organisation existante.

    - Migrer quelques boîtes (de tests) 

    - Basculer les configurations sur le nouveau serveur (Connecteurs d'envois, de réception, etc...). 

    - Déplacer ensuite toutes les boîtes.

    - Désinstaller "proprement" l'ancien serveur.

    Ceci permet de n'impacter les utilisateurs que (faiblement) pendant le déplacement de leurs boîtes (qui peut se faire la nuit), et pendant les tests de bascules (notamment pour la réception).

    => Aucun risque de perte de message, ni d'interruptions de la prod...

    A bientôt,


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

    mercredi 26 octobre 2016 19:40
    Modérateur
  • Bonjour, merci pour votre réponse.

    Pensez-vous qu'il serait plus judicieux de copier la VM et de la migrer vers le nouveau site ? 

    Une fois migrer nous aurions juste besoin de changer l'adressage IP.

    Cordialement.

    Vous pouvez le faire si la solution de virtualisation vous propose de exporter et importer la VM proprement (comme si vous déplacer un serveur physique dans un autre emplacement), mais cela vous allez obliger d'arrêter la machine virtuelle et interrompre le service de messagerie.
    mercredi 26 octobre 2016 20:01
    Modérateur
  • Hello Phil,

    D'autres compléments ont été donnés dans ce thread :)

    Quand je parlais d'url sur la "ferme" c'était faire pointer les serveurs 1 et 2 sur le même nom comme par exemple mail.domaine.fr.

    Durant la migration des boites un utilisateur sur le serveur 1 pourra se connecter à sa boite même en passant par le serveur 2 en toute transparence et inversement (proxyfication)

    Le DAG, comme le dit Thierry, à éviter pour ne pas se compliquer la "migration".

    Merci


    Hakim Taoussi - Consultant Exchange - http://exchangediscover.blogspot.fr

    jeudi 27 octobre 2016 05:07
  • Bonjour à tous et merci beaucoup pour vos réponses. 

    Donc nous allons opter pour le déplacement de la VM d'un site à un autre. Il y aura un temps d'interruption mais ce n'est pas grave puisque ce sera fait durant le week-end. 

    J'ai une question concernant la base de données EDB. Si on déplace la VM - on change l'adressage IP, le nom du serveur (tout en gardant le NAMESPACE (mail.xxx.ca)) - Est-ce que les 2 VM pourront tourner en même temps ? Ou est-ce qu'il y aura un conflt vu que c'est la même base de données EDB ?

    Philippe

    jeudi 27 octobre 2016 14:06
  • Bonjour à tous et merci beaucoup pour vos réponses. 

    Donc nous allons opter pour le déplacement de la VM d'un site à un autre. Il y aura un temps d'interruption mais ce n'est pas grave puisque ce sera fait durant le week-end. 

    J'ai une question concernant la base de données EDB. Si on déplace la VM - on change l'adressage IP, le nom du serveur (tout en gardant le NAMESPACE (mail.xxx.ca)) - Est-ce que les 2 VM pourront tourner en même temps ? Ou est-ce qu'il y aura un conflt vu que c'est la même base de données EDB ?

    Philippe

    Il faut pas laisser les deux machine tourner en meme temps sur le meme réseau cela n'a aucun sens, (conflit identifiant OS, compte AD de la machine AD, DNS...)
    jeudi 27 octobre 2016 14:33
    Modérateur