none
Certificat pour Exchange 2013 RRS feed

  • Question

  • Bonjour,

    je travail sur un lab dans le but de mettre en place Exchange 2013

    j'ai installé

    2 serveurs CAS 

    2 serveurs MBX

    1 DC (DNS, DHCP)

    1 Serveur AD CS pour les certificat 

    j'utilise un nom de domaine "test.com" je n'ai rien changé dans le DNS ( les enregistrement se font automatiquement chaque fois que j’intègre un serveur au domaine)

    j'ai fait une demande de certificat depuis CAS1 '"certif.req" j'ai copié le code de la demande dans le Services de certificats Microsoft Active Directory via un navigateur web et j'ai généré un certificat.

    je retourne dans le EAC et j'importe le certificat (mais que des erreurs)

    ma question :

    Est ce que j'importe le certificat sur cas1 et cas 2 seulement ou bien sur les 4 serveurs Exchange ?

    Est ce que je je dois crée des enregistrement DNS avant ? 

     Merci d'avance pour votre aide.

    dimanche 3 février 2019 20:01

Réponses

  • Bonsoir,

    l'important, ce que vous avez mis dans la demande de certificat... en particulier, les noms DNS.

    Y a t-il un nom DNS partagé entre les 2 CAS ?

    par exemple: Webmail.Test.com,

    Il faut systématiquement ajouter "autodiscover.test.com" dans les noms DNS. Comme il s'agit d'une autorité interne, on peut aussi ajouter les noms des 2 serveurs CAS (pour le même prix)

    Dans votre cas, le certificat n'est utile que sur les 2 CAS.

    La mise à jour des enregistrements DNS n''est pas liée à la demande/installation des certificats.

    C'est seulement lors de l'utilisation et de la connexion que les noms DNS doivent correspondre.

    A+


    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

    • Marqué comme réponse Ali-Wr lundi 4 février 2019 22:01
    dimanche 3 février 2019 22:59
    Modérateur
  • Bonsoir,

    a priori, il n'y a aucune raison de désactiver les services DAG ou NLB.

    => Ils peuvent être actifs pendant toute l'opération de migration. L'accès aux boites et services est nécessaire pour réaliser une migration.

    NLB n'est plus utile ni conseillé pour Exchange 2013, encore moins pour Exchange 2016.

    Cette séparation n'existe plus sur Exchange 2016, tous les rôles (sauf EDGE) sont sur chaque serveur Exchange.

    Seul le HLB (Hardware Load Balancing ou l'équivalent en virtuel) est maintenant préconisé pour Exchange, et au pire, on peut utiliser le Round Robin DNS.

    La logique de migration consiste maintenant à installer Exchange 2016 dans la même organisation Exchange. Très vite se posera la question d'avoir un certificat pour le nouveau serveur avec le ou les noms susceptibles d'être utilisés. L'option la plus simple, si vous avez utilisé un nom commun (Webmail.test.com) consiste à exporter le certificat existant avec sa clé privée (TRES IMPORTANT).

    Sinon, vous pouvez créer un nouveau certificat avec tous les noms (anciens et nouveaux serveurs) susceptibles d'être utilisés.

    Dès que cela est effectué, il est possible et souvent préférable de basculer l'accès sur le nouveau Exchange 2016 (Exchange 2013 et 2016 sont très proches).

    La suite est relativement classique. Ajouter un serveur Exchange 2016 pour former un nouveau DAG en 2016. Déplacer les boites... Retirer les anciens CAS/Frontaux... Gérer la répartition des clients sur tous les membres du DAG 2016.

    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

    • Marqué comme réponse Ali-Wr lundi 4 février 2019 22:01
    lundi 4 février 2019 21:48
    Modérateur
  • Merci Infiniment Thierry, vos conseils sont très utiles, j'apprécie vraiment.
    lundi 4 février 2019 22:01

Toutes les réponses

  • Bonsoir,

    l'important, ce que vous avez mis dans la demande de certificat... en particulier, les noms DNS.

    Y a t-il un nom DNS partagé entre les 2 CAS ?

    par exemple: Webmail.Test.com,

    Il faut systématiquement ajouter "autodiscover.test.com" dans les noms DNS. Comme il s'agit d'une autorité interne, on peut aussi ajouter les noms des 2 serveurs CAS (pour le même prix)

    Dans votre cas, le certificat n'est utile que sur les 2 CAS.

    La mise à jour des enregistrements DNS n''est pas liée à la demande/installation des certificats.

    C'est seulement lors de l'utilisation et de la connexion que les noms DNS doivent correspondre.

    A+


    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

    • Marqué comme réponse Ali-Wr lundi 4 février 2019 22:01
    dimanche 3 février 2019 22:59
    Modérateur
  • Bonjour Thierry 

    Merci pour votre aide, c’était vraiment très utiles.

    je voudrais vous poser une autres question concernant le même lab, 

    j'ai configuré le DAG pour MBX1 et MBX2 (2 bases de données sur un serveur iSCSI)

    et NLB pour CAS1 et CAS2

    j'ai réussi à configurer le certificat (plus de messages d'erreur ni sur EAC ni pour les clients Outlook) 

    maintenant je compte migrer cette organisation Exchange 2013 vers Exchange 2016.

    ma question :

    Est ce que je dois desactiver les service DAG et NLB avant ?

    si vous avez des conseils pour moi j’apprécie trop :)

    Merci infiniment Thierry.

    lundi 4 février 2019 16:30
  • Bonsoir,

    a priori, il n'y a aucune raison de désactiver les services DAG ou NLB.

    => Ils peuvent être actifs pendant toute l'opération de migration. L'accès aux boites et services est nécessaire pour réaliser une migration.

    NLB n'est plus utile ni conseillé pour Exchange 2013, encore moins pour Exchange 2016.

    Cette séparation n'existe plus sur Exchange 2016, tous les rôles (sauf EDGE) sont sur chaque serveur Exchange.

    Seul le HLB (Hardware Load Balancing ou l'équivalent en virtuel) est maintenant préconisé pour Exchange, et au pire, on peut utiliser le Round Robin DNS.

    La logique de migration consiste maintenant à installer Exchange 2016 dans la même organisation Exchange. Très vite se posera la question d'avoir un certificat pour le nouveau serveur avec le ou les noms susceptibles d'être utilisés. L'option la plus simple, si vous avez utilisé un nom commun (Webmail.test.com) consiste à exporter le certificat existant avec sa clé privée (TRES IMPORTANT).

    Sinon, vous pouvez créer un nouveau certificat avec tous les noms (anciens et nouveaux serveurs) susceptibles d'être utilisés.

    Dès que cela est effectué, il est possible et souvent préférable de basculer l'accès sur le nouveau Exchange 2016 (Exchange 2013 et 2016 sont très proches).

    La suite est relativement classique. Ajouter un serveur Exchange 2016 pour former un nouveau DAG en 2016. Déplacer les boites... Retirer les anciens CAS/Frontaux... Gérer la répartition des clients sur tous les membres du DAG 2016.

    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

    • Marqué comme réponse Ali-Wr lundi 4 février 2019 22:01
    lundi 4 février 2019 21:48
    Modérateur
  • Merci Infiniment Thierry, vos conseils sont très utiles, j'apprécie vraiment.
    lundi 4 février 2019 22:01