Microsoft Exchange Server est la plate-forme de messagerie, de calendrier, de contact, de planification et de collaboration de Microsoft. Il est déployé sur le système d’exploitation Windows Server (OS) pour un usage professionnel. Microsoft a conçu Exchange Server pour permettre aux utilisateurs d’accéder à la plate-forme de messagerie à partir d’appareils mobiles, de postes de travail et de systèmes Web. Les capacités de téléphonie dans Exchange Server prennent en charge les messages vocaux.
Les utilisateurs d’Exchange collaborent via le partage de calendriers et de documents. Les fonctionnalités de stockage et de sécurité de la plate-forme permettent aux organisations d’archiver le contenu, d’effectuer des recherches et d’exécuter des tâches de conformité. Exchange Server a évolué au fil du temps, et il est maintenant un composant fondamental d’Office 365 en tant qu’offre de logiciel en tant que service (SaaS) dans le cloud Microsoft, Microsoft agissant en tant que fournisseur de services.
Comment fonctionne Exchange Server ?
Exchange Server est un produit de collaboration de classe entreprise qui se concentre principalement sur l’envoi, la réception et le stockage de messages électroniques. En plus de gérer le trafic de messagerie, Exchange Server fournit plusieurs autres fonctionnalités de collaboration, telles que le calendrier et une intégration étroite avec d’autres applications Microsoft Office.
Exchange Server est connu pour ses fonctionnalités de haute disponibilité (HA) qui garantissent un service continu dans différents scénarios de panne. Cela inclut les chemins de conception qui peuvent assurer le service lors de pannes de serveur unique ou de pannes de centre de données.
Fonctionnalités d’Exchange Server 2019
La version 2019 offre un basculement nettement plus rapide et plus fiable entre les serveurs. Il a été conçu pour améliorer les performances globales et tirer parti du matériel de stockage le plus récent, notamment des disques plus gros et des disques SSD.
Les fonctionnalités supplémentaires d’Exchange server 2019 incluent les éléments suivants:
- prend en charge jusqu’à 256 Go de mémoire et 48 cœurs de processeur ;
- permet les installations sur le cœur de Windows Server ;
- permet de bloquer nativement l’accès externe au centre d’administration Exchange (EAC) et au shell de gestion Exchange ;
- utilise l’allocation de cache de mémoire dynamique pour optimiser l’utilisation de la mémoire pour les bases de données actives;
- empêche les participants de transférer des invitations à des réunions ;
- fournit aux utilisateurs finaux des options supplémentaires Hors bureau ;
- permet aux administrateurs d’annuler les réunions organisées par un utilisateur qui a quitté l’entreprise ;
- permet aux administrateurs d’attribuer des autorisations de délégué ; et
- permet aux adresses e-mail contenant des caractères non anglais d’être acheminées et livrées en mode natif.
Logo Exchange Server 2019 En plus de ces fonctionnalités supplémentaires dans Exchange 2019, le rôle de messagerie unifiée (UM) et toutes les fonctionnalités associées ont été supprimés d’Exchange 2019. A Sept. 16, 2019, blog sur le site de l’équipe Exchange a indiqué que Microsoft pousserait le support étendu d’Exchange Server 2010 à partir de janvier. 14, 2020, à oct. 13, 2020, pour donner aux clients d’Exchange Server 2010 plus de temps pour terminer leurs migrations.
Les administrateurs qui exécutent des charges de travail Exchange Server 2010 sur Windows Server 2008 devront effectuer des ajustements en raison du Janv. 14, 2020, fin de vie de ce système d’exploitation de serveur.
Exigences d’Exchange Server 2019
Les exigences suivantes doivent être remplies pour installer Exchange 2019:
- Exchange 2019 peut être installé dans des forêts Active Directory (AD) avec des serveurs Exchange 2016 et/ou 2013 existants. Aucune version antérieure d’Exchange ne peut être installée dans la même forêt qu’Exchange 2019.
- Tous les contrôleurs de domaine (DCS) de la forêt AD doivent exécuter Windows Server 2019 Standard ou Datacenter, Windows Server 2016 Standard ou Datacenter, ou Windows Server 2012 R2 Standard ou Datacenter.
- Le niveau de fonction de forêt d’ANNONCES doit être Windows Server 2012 R2 ou supérieur.
- Le serveur hébergeant Exchange 2019 doit utiliser un processeur 64 bits.
- Le serveur hébergeant Exchange 2019 devrait avoir entre 128 et 256 gigaoctets (Go) de mémoire vive (RAM).
- Le système de fichiers de nouvelle technologie (NTFS) est requis sur toutes les partitions de disque contenant la partition système, les binaires d’échange, les journaux de diagnostic et la base de données de transport. Le système de fichiers résilient (ReFS) peut être utilisé sur des partitions contenant des bases de données de boîtes aux lettres et des journaux de transactions.
Exchange Server haute disponibilité
Exchange Server possède plusieurs fonctionnalités importantes pour maintenir la résilience et la HA. Les composants du serveur de boîtes aux lettres d’Exchange reposent sur des groupes de disponibilité de base de données (DAG). Les composants du serveur d’accès client reposent sur l’équilibrage de charge.
Groupes de disponibilité des bases de données
Le DAG est le sous-système d’échange fondamental pour garantir l’HA. Le DAG a été introduit pour la première fois dans Exchange 2010 et est rapidement devenu l’un des sous-systèmes les plus importants d’Exchange.
Le DAG est un groupe de jusqu’à 16 serveurs Exchange qui copie automatiquement les bases de données entre les membres pour assurer la redondance en cas de panne au niveau de la base de données ou du serveur. Tout serveur membre d’un DAG peut héberger une copie d’une base de données à partir de n’importe quel autre serveur membre du DAG. Une fois qu’une copie d’une base de données est ajoutée à un autre serveur, cette copie est automatiquement mise à jour et prête à être activée à tout moment.
Le DAG est basé sur le clustering Windows et non sur une technologie spécifique à l’équipe Exchange elle-même. Cela peut signifier que, parfois, les fonctionnalités et les bogues de Windows Server peuvent avoir un impact significatif sur le fonctionnement d’Exchange.
Active Manager
Active Manager (AM) est le composant Exchange responsable de la gestion des événements de basculement dans un environnement Exchange. AM s’exécute dans le service de réplication Microsoft Exchange sur tous les serveurs Exchange 2016. Lorsqu’un serveur Exchange est joint à un DAG, deux rôles AM sont exécutés sur ce serveur : le Gestionnaire actif principal (PAM) et le Gestionnaire actif de secours (SAM).
Le serveur membre DAG qui possède la ressource de quorum de cluster tiendra le rôle PAM. Si le nœud DAG contenant la ressource quorum échoue, le rôle PAM se déplace vers le serveur qui prend la propriété de la ressource quorum.
Le SAM est responsable de fournir des informations aux autres composants Exchange qui exécutent des clients AM sur la copie de base de données actuellement active. Le SAM détecte l’échec d’une base de données et demande au PAM d’initier l’événement de basculement. Le SAM n’est pas responsable de la sélection de la copie de la base de données activée après une défaillance. Ce processus est appelé meilleure copie et sélection du serveur (BCSS).
Sélection de la meilleure copie
Lorsqu’une défaillance de la base de données est détectée, AM prend des mesures pour récupérer de l’échec en sélectionnant la meilleure copie de la base de données à activer. Le processus BCSS se déroule comme suit:
- Une panne est détectée par AM ou par Disponibilité gérée. Ce processus peut également être lancé par un administrateur qui initie un basculement sans cible.
- Le PAM démarre l’algorithme interne BCSS.
- Le sous-processus attempt copy last logs (ACLL) tente de copier tous les fichiers journaux manquants du serveur qui a hébergé la dernière copie active de la base de données.
- Une fois le processus ACLL terminé, une valeur AutoDatabaseMountDial est vérifiée pour les serveurs hébergeant des copies de la base de données et est comparée à la longueur de la file d’attente de copie de la base de données en cours d’activation. Si le nombre de fichiers journaux manquants est inférieur ou égal à la valeur d’AutoDatabaseMountDial, AM passe à l’étape cinq. Si ce n’est pas le cas, AM recommencera ce processus à la deuxième étape.
- Le PAM émet une demande de montage au magasin d’informations. Si la base de données ne se monte pas, AM revient à la deuxième étape.
Il existe une logique supplémentaire dans ce processus si l’événement de basculement est déclenché par un événement de surveillance. La logique supplémentaire garantira que le serveur qui reprend la base de données active est en meilleure santé que le serveur d’où il provient.
Modes de quorum DAG
Un DAG est une implémentation spécifique d’un cluster de serveurs Windows. Les composants Exchange de DAG reposent sur la technologie de cluster Windows Server sous-jacente pour fonctionner. Le concept de quorum est essentiel pour comprendre comment mettre en œuvre et gérer les DAG.
Le quorum est l’idée qu’en cas d’échec de certains membres du GCD, il existe des règles régissant les ressources que les membres restants peuvent fournir. Ces ensembles de règles de quorum existent pour fournir un fonctionnement cohérent d’un DAG et agir comme un bris d’égalité dans les situations où les nœuds DAG perdent la communication les uns avec les autres.
Lorsqu’un DAG a un nombre pair de nœuds, il utilise le mode quorum majoritaire de partage de fichiers Node &. Dans ce mode, un serveur témoin externe agit comme bris d’égalité. Lors de l’exécution dans ce mode, chaque membre du nœud DAG obtient un vote unique, mais le serveur témoin donne un vote supplémentaire à l’un des nœuds DAG. Les données de quorum de cluster sont stockées sur le disque système local de chaque membre, mais le serveur témoin dispose d’un fichier séparé qui pointe vers un membre DAG en tant que copie la plus à jour des données de quorum de cluster DAG.
Lorsqu’un DAG a un nombre impair de membres, il utilise le mode quorum majoritaire du nœud. Dans ce mode, chaque membre DAG obtient un vote et le disque système local de chaque membre est utilisé pour stocker les données de quorum du cluster.
Il est possible d’attribuer manuellement des membres DAG spécifiques avec des votes de quorum pondérés. Cela n’est pas recommandé dans la plupart des cas et ne doit être fait qu’après consultation directe du support Microsoft.
Mode de coordination d’activation du centre de données
Le mode de coordination d’activation du centre de données (DAC) est une fonctionnalité de DAGs conçue pour éviter les situations dans lesquelles une panne entraîne la mise en ligne de deux copies d’une base de données sur deux serveurs différents. Le mode DAC nécessite une intervention manuelle lorsque le serveur hébergeant la base de données ne peut pas atteindre la majorité des serveurs membres du DAG.
Les meilleures pratiques de Microsoft exigent que le mode DAC soit activé sur tout DAG comportant deux membres ou plus et utilisant une réplication continue. Les seuls cas où le mode DAC pour un DAG n’est pas recommandé seraient si l’administrateur utilisait un outil de réplication tiers.
Lorsque le DAC est actif, il y a une communication supplémentaire entre les nœuds DAG au démarrage qui utilisent le protocole DAC (DACP). DACP est défini sur 0 au démarrage. Si le bit DACP reste à 0, AM ne tentera pas de démarrer de bases de données sur ce nœud. Le bit DACP peut également être défini sur 1 si un autre membre DAG a son bit DACP défini sur 1 ou lorsqu’un nœud DAG peut contacter tous les serveurs de sa liste d’adhésion DAG.
Le mode DAC est utile lorsqu’un centre de données principal tombe complètement en panne et qu’un centre de données de sauvegarde est activé. Lorsque l’alimentation revient et que les serveurs apparaissent avant que la connexion au réseau étendu (WAN) ne soit de nouveau en ligne, le mode DAC empêche différentes copies des mêmes bases de données de se retrouver actives dans les deux centres de données.
Pour un DAG à deux nœuds, le mode DAC utilise une comparaison du temps de démarrage du serveur témoin alternatif et de l’heure à laquelle le bit DACP a été défini sur 1 pour déterminer s’il peut monter des bases de données. Si le bit DACP a été défini sur 1 plus tôt que l’heure de démarrage du serveur témoin alternatif, le système suppose que les deux serveurs ont été redémarrés en même temps – peut-être en raison d’une panne de courant au centre de données principal – et que le membre DAG n’est pas autorisé à monter des bases de données. Si le bit DACP a été défini sur 1 après le démarrage du serveur témoin alternatif, le système suppose qu’il est sûr de monter des bases de données.
Databaseavailabilitéles applets de commande de groupe et conditions de cerveau divisé
Le cerveau divisé est une situation où deux copies différentes d’une même base de données deviennent actives en même temps dans des centres de données différents. Lorsque cela se produit, les deux copies différentes de la base de données divergent, entraînant une perte potentielle de données utilisateur lorsque les deux copies différentes tentent de se réconcilier.
En plus de prévenir les troubles du cerveau partagé, le mode DAC permet de démarrer, d’arrêter et de restaurer les applets de commande DatabaseAvailabilityGroup. Ces applets de commande sont utilisées pour effectuer des basculements manuels de centres de données. Lorsque le mode DAC n’est pas actif, le processus d’un centre de données manuel est complexe et implique à la fois des outils d’échange et un gestionnaire de cluster.
Imaginez une situation où un environnement d’échange se compose de quatre serveurs, chacun ayant une copie de la même base de données. Deux de ces serveurs se trouvent dans le centre de données A et deux dans le centre de données B. Une panne de réseau se produit dans la liaison entre les deux centres de données. Sans le mode DAC activé, il serait possible pour les serveurs de chaque centre de données de penser qu’ils devaient activer une copie de la base de données.Le mode DAC
empêche ce scénario de cerveau partagé en exigeant la majorité des nœuds avant qu’une base de données puisse être activée. La majorité des nœuds signifie que la plupart des nœuds du cluster – ou DAG dans ce cas – doivent être en ligne et accessibles pour qu’un nœud DAG puisse activer une copie de base de données. S’il y a un nombre pair de nœuds dans le DAG, le témoin de partage de fichiers fonctionnera également en tant que membre votant pour déterminer la majorité des nœuds.
Dans le cas décrit ci-dessus avec un cluster à quatre nœuds et deux nœuds dans chaque centre de données, seuls les serveurs Exchange du centre de données avec le témoin de partage de fichiers seraient en mesure d’activer des bases de données. Les nœuds DAG de l’autre centre de données seraient empêchés d’activer des bases de données jusqu’à ce qu’ils puissent contacter tous les serveurs répertoriés comme membres du DAG.
Témoin de troisième site
Une fonctionnalité ajoutée à Exchange à l’ère 2013 était la prise en charge d’un témoin de troisième site, qui a le pouvoir de mettre toutes les ressources en ligne sans intervention de l’administrateur. Lorsque chaque site dispose d’un chemin de réseau indépendant vers le témoin du troisième site, les nœuds d’un site peuvent maintenir le quorum à l’aide du serveur témoin. L’inconvénient de l’utilisation d’un témoin tiers est que les administrateurs Exchange doivent prendre le temps nécessaire pour creuser et bien comprendre le comportement de leur réseau.
Équilibrage de charge
L’équilibrage de charge est un moyen pour les administrateurs de gérer le trafic réseau qui finit par être dirigé vers chaque serveur Exchange au sein d’un réseau. Habituellement, il est souhaitable de gérer la distribution des connexions client entrantes entre les serveurs Exchange 2016 pour deux raisons:
- Pour répartir la charge de travail. Si quelqu’un va prendre la peine de configurer et de maintenir plusieurs serveurs Exchange, c’est une bonne idée de faire travailler tous ces serveurs Exchange régulièrement.
- Pour réduire l’impact d’une défaillance. Quand quelque chose ne va pas, il est agréable d’avoir un système redondant pour prendre en charge la charge de travail du système défaillant.
L’équilibrage de charge complète les DAG. Le travail d’un DAG est: (1) de s’assurer qu’il y a plusieurs copies de chaque boîte aux lettres prêtes à être activées et (2) d’accepter les demandes des clients au cas où la copie active deviendrait indisponible. L’équilibrage de charge fonctionne de la même manière; son travail consiste à s’assurer qu’il existe d’autres endroits pour envoyer du trafic client si un endroit devient indisponible.
L’équilibrage de charge peut s’étendre sur deux serveurs Exchange ou plus dans un seul site, ou sur plusieurs sites. Un déploiement Exchange d’architecture préférée (PA) comprendrait quatre serveurs Exchange répartis sur deux sites AD distincts. Les versions actuelles d’Exchange prennent en charge l’équilibrage de charge de la couche 4, de la couche 7 et du système de noms de domaine (DNS).
Architecture préférée d’Exchange
Exchange PA est le déploiement Exchange idéal, tel qu’envisagé par l’équipe Exchange de Microsoft. Le PA est développé en tenant compte du coût total de possession (TCO), de l’HA, de la résilience, de la redondance et du recouvrement. L’AP n’est pas destiné à être utilisé comme modèle de maturité; il a été conçu pour servir d’inspiration.
Clients Exchange Server
Les utilisateurs Exchange accèdent aux messages et interagissent avec eux via un client de messagerie. Microsoft Outlook est le client le plus courant. Exchange Server 2016 prend également en charge les éléments suivants:
- Outlook 2016
- Outlook 2013
- Outlook 2010 Service Pack 2 (SP2)
- Outlook pour Mac pour Office 365
- Outlook pour Mac 2011
Outlook est également disponible en tant qu’application Web, appelée Outlook sur le Web – anciennement Outlook Web App et couramment abrégé en OWA – pour que les utilisateurs puissent accéder aux messages de nombreux navigateurs Web différents et interagir avec eux. Outlook sur le Web permet aux utilisateurs de lier et de partager des documents stockés dans OneDrive Entreprise sur un serveur SharePoint local. Cela crée un moyen plus simple et plus direct pour les utilisateurs finaux d’enregistrer et de joindre des fichiers aux e-mails.
Avantages et inconvénients d’Exchange Server
Bien qu’il soit facile de parler des avantages de l’utilisation de Microsoft Exchange, il peut être difficile d’identifier les inconvénients, en plus des coûts de licence. À l’heure actuelle, il y a peu, voire aucun, de vrais concurrents à échanger.
Exchange on-premises – toutes les versions comptées ensemble – a probablement la plus grande base d’utilisateurs actifs, mais Microsoft ne publie pas de chiffres sur le nombre d’utilisateurs actifs dans Exchange on-Premises ou Exchange Online. Outlook.com fonctionne maintenant sur Exchange, donc Exchange sur site, Exchange en ligne et Outlook.com vous avez probablement plus d’utilisateurs totaux (professionnels et personnels) que Gmail (professionnels et personnels). Toute autre plate-forme de messagerie concurrente après les offres de Microsoft et de Google a des bases d’utilisateurs relativement petites.
Après les plates-formes de messagerie professionnelle de Microsoft et de Google, la solution la plus importante en termes de base d’utilisateurs installée est probablement Lotus Notes. Les comparaisons entre Notes et Exchange sont difficiles car Notes n’est pas avant tout une solution de messagerie. Lotus Notes est une solution de base de données qui inclut une fonctionnalité de messagerie. En outre, à compter du 30 juin 2019, IBM a vendu la propriété de Lotus Notes à HCL et ne mettra plus à jour ce produit.
Zimbra est la plus grande solution de messagerie basée sur Linux. Des solutions Zimbra basées sur SCSI (SAS) sur site et en série sont disponibles. Il existe des versions open source de Zimbra disponibles, qui incluent différentes options de licence.
Toutes les différentes solutions de messagerie avec des fonctionnalités et des objectifs différents rendent difficile une comparaison directe entre pro et con. Voici quelques comparaisons de haut niveau pour et contre. Ces listes ne sont pas destinées à être définitives.
Exchange on-premise vs Exchange Online
Le choix le plus courant pour les entreprises à la recherche d’une solution de messagerie sera entre Exchange on-premise et Exchange Online.
| Échange sur site | |
| Avantages | Inconvénients |
|
Les administrateurs peuvent contrôler le calendrier de mise à niveau et la disponibilité des fonctionnalités |
Les réparations matérielles sont de la responsabilité de l’administrateur |
|
Frais de licence uniques |
Doit être entretenu localement, sur place |
| Personne en dehors de l’organisation n’a accès aux serveurs ou aux données | Les coûts matériels et logiciels doivent être amortis |
| Échange En Ligne | |
| Avantages | Inconvénients |
| Pas besoin de maintenance matérielle ou logicielle | Solution rigide |
| Frais mensuels de licence | Perte potentielle de contrôle de vos données |
| 99.9% contrat de niveau de service (SLA) de disponibilité | Potentiellement plus cher |
| Nécessite potentiellement la mise à jour des logiciels sur site associés | |
Échange en ligne vs. Gmail
| Exchange Online | |
| Pros | Con |
| Integration with other Office 365 applications | More expensive than Gmail |
| Hybrid integration with Exchange on-premises | |
| Gmail | |
| Pro | Cons |
| Less expensive than Exchange Online | Less complete suite of software |
| No hybrid options | |
| Aucune intégration publicitaire | |
Microsoft Exchange Online
Microsoft propose Exchange en tant qu’offre SaaS appelée Exchange Online. Il est disponible en tant que service autonome ou dans le cadre de la suite Office 365. Les utilisateurs finaux se connectent à Exchange Online via le client Outlook ou Outlook sur le Web. Les administrateurs disposant d’autorisations administratives Office 365 configurent et gèrent le service. Microsoft propose Exchange en tant que service hébergé pour réduire le travail administratif impliqué dans les déploiements sur site Exchange.
Tarification du serveur Exchange
La tarification du serveur Exchange peut varier considérablement en fonction de la façon dont elle est achetée et de la version achetée.
Exchange sur site est vendu sur une base par serveur. De plus, une licence d’accès client (CAL) est requise pour chaque utilisateur accédant à Exchange. Exchange Server doit être installé sur un serveur exécutant le système d’exploitation Windows Server, qui doit également être sous licence avec un modèle par serveur plus CAL. Le serveur doit être installé dans une forêt AD avec au moins un DC.
Exchange Server lui-même est disponible en deux niveaux de licence: Standard et entreprise. Les CALs d’échange sont également disponibles en standard et en Entreprise. Chaque utilisateur doit disposer d’un CAL standard Windows Server et peut disposer d’un CAL d’entreprise pour des fonctionnalités supplémentaires. Les CALs Standard et d’entreprise peuvent être utilisés avec l’une ou l’autre édition de serveur.
Exchange Online est vendu par utilisateur et par mois, soit en tant qu’offre autonome, soit dans le cadre d’un forfait Office 365. Il existe deux plans autonomes. Forfait Exchange Online 14 4 par utilisateur, par mois offers offre une messagerie professionnelle sécurisée et disponible, avec une boîte aux lettres de 50 Go par utilisateur. Le forfait Exchange Online 2 à 8 — $ par utilisateur et par mois s’appuie sur le forfait 1 et comprend un stockage illimité, une messagerie vocale hébergée et une fonctionnalité de prévention de la perte de données (DLP).
Historique d’Exchange Server
Exchange Server a été publié pour la première fois dans un aperçu privé en 1993. En 1996, la première version accessible au public d’Exchange Server a été publiée sous le nom d’Exchange 4.0. Le numéro de version 4.0 de la première version d’Exchange devait signifier qu’il s’agissait de la mise à niveau de Microsoft Mail 3.5, mais il s’agissait de deux programmes radicalement différents. Exchange 4.0 a utilisé le X.protocole 500 pour les services d’annuaire et la livraison du courrier.
En 1997, Exchange 5.0 a été publié. C’était la première version d’Exchange à présenter le protocole SMTP (Simple Mail Transfer Protocol) comme protocole de livraison du serveur de messagerie. SMTP a fait d’Exchange 5.0 la première version capable de communiquer avec d’autres plates-formes de messagerie sur Internet. Exchange 5.0 a également introduit OWA dans Exchange 5.0 dans un service pack post-sortie.
Exchange 5.5 a été publié moins d’un an après Exchange 5.0 et a été la première version d’Exchange à être disponible dans les éditions Standard et Enterprise. Échange 5.5 incluait également l’introduction de la récupération pour les éléments supprimés et la prise en charge du protocole d’accès aux messages Internet 4 (IMAP4) et des clients LDAP (Lightweight Directory Access Protocol) v3.
Exchange Server 2000 a été publié deux ans plus tard pour coïncider avec la sortie de AD. Exchange 2000 comprenait une fonctionnalité de messagerie instantanée qui a ensuite été transférée à Office Communications Server. Exchange Server 2000 n’a pas été largement adopté.
Exchange Server 2003 a été un énorme pas en avant pour Exchange, à la fois en termes de fonctionnalité et d’adoption. Exchange Server 2003 a commencé la tendance à différencier différents serveurs Exchange pour répondre à différentes fonctions. Bien que le même logiciel ait été installé sur tous les serveurs Exchange, 2003 a soutenu l’idée de désigner certains serveurs en tant que serveurs frontaux pour héberger les connexions client. Exchange 2003 a également facilité les migrations à partir des versions précédentes d’Exchange en permettant la coexistence de serveurs 2003 dans des organisations qui exécutaient encore des versions précédentes.
Exchange Server 2007 était une autre version majeure qui comprenait de nombreuses nouvelles fonctionnalités. Lors de la sortie, Exchange 2007 ne prenait pas en charge les dossiers publics, mais cette prise en charge a été renvoyée avec le Service Pack 1 (SP1) après les plaintes des clients. Exchange 2007 a été le premier produit majeur de Microsoft à adopter pleinement PowerShell. Pour la première fois, toutes les fonctionnalités d’Exchange étaient disponibles en tant que commandes PowerShell, bien que certaines fonctionnalités n’aient pas de commandes d’interface utilisateur graphique (GUI).
Exchange 2007 a également introduit le concept de rôles de serveur Exchange entièrement séparés. 2007 comprenait cinq rôles de serveur Exchange différents sur lesquels un logiciel distinct était installé sur le serveur physique. Quatre de ces rôles pourraient être installés sur un seul serveur physique si vous le souhaitez, mais chaque rôle pourrait également être installé sur son propre serveur physique.
Exchange 2007 a également introduit l’UM pour fournir des services de téléphonie « une fois l’appel répondu » et a inclus plusieurs options de base de données HA. Ces options, qui comprenaient plusieurs façons de créer un cluster de bases de données, ont fini par être compliquées et déroutantes à déployer et à maintenir.
Exchange 2010 était une version mineure d’Exchange Server. Le changement majeur dans Exchange Server 2010 a été l’introduction du DAG et la dépréciation des options de clustering compliquées d’Exchange 2007. Exchange 2010 a inclus et amélioré la séparation des rôles de serveur d’Exchange 2007, et il a amélioré les options d’équilibrage de charge disponibles pour une meilleure disponibilité de l’accès client. Office 365 a été publié pour la première fois pendant la période Exchange 2010, et Exchange 2010 comprenait la première fonctionnalité hybride Exchange entre Exchange sur site et Exchange Online.
Exchange 2013 a été publié le octobre. 11, 2012, aux côtés de nouvelles versions de SharePoint et Skype Entreprise. Cette version signifiait l’intention de Microsoft de créer une intégration plus étroite entre les trois produits Office Server et leurs versions Office 365 online. Les boîtes aux lettres du site ont été introduites dans Exchange 2013 et comprenaient des fonctionnalités permettant d’accéder aux boîtes aux lettres Exchange et au contenu SharePoint ensemble.
Exchange 2013 a inclus un changement significatif des dossiers publics appelés dossiers publics modernes. Alors que les fonctionnalités de base des dossiers publics sont restées les mêmes, l’architecture en coulisses a été modifiée pour inclure des dossiers publics dans les mêmes bases de données de boîtes aux lettres que les boîtes aux lettres des utilisateurs. Au cours du cycle de vie d’Exchange 2013, les clients de Microsoft ont commencé à se demander si Microsoft continuerait à développer de nouvelles versions d’Exchange sur site ou ne prendrait en charge qu’Exchange Online. La spéculation s’est produite principalement parce que de nouvelles fonctionnalités d’échange ont commencé à apparaître dans Exchange Online d’abord, puis elles en feraient des versions sur site du logiciel.
Exchange 2016 a supprimé la possibilité d’installer des rôles de serveur Exchange distincts sur des serveurs physiques distincts, à l’exception du rôle de transport périphérique.
Exchange Server 2019 incluait la possibilité d’installer Exchange Server sur Windows Server Core. C’était la première version d’Exchange qui pouvait être exécutée et gérée avec une interface graphique. Toutes les fonctionnalités UM ont été supprimées d’Exchange 2019 dans cette version, et de nouvelles fonctionnalités pour Exchange 2019 ont été ajoutées.
Versions d’Exchange Server
La liste suivante affiche la progression de la version d’Exchange Server avec la date de sortie et la version logicielle correspondantes:
- L’édition standard Exchange Server 4.0 a été publiée pour la première fois le 11 juin 1996 sous le nom de build 4.0.837.
- Exchange Server 5.0 a été publié pour la première fois le 23 mai 1997, sous la version 5.0.1457.
- Exchange Server 5.5 a été publié pour la première fois en février. 3, 1998, comme build 5.5.1960.
- Le serveur Exchange 2000 a été publié pour la première fois en novembre. 29, 2000, comme build 6.0.4417.
- Exchange Server 2003 a été publié pour la première fois en septembre. 28, 2003, comme build 6.5.6944.
- Exchange Server 2007 a été publié pour la première fois le 8 mars 2007 sous la version 8.0.685.25.
- Exchange Server 2010 a été publié pour la première fois en novembre. 9, 2009, comme build 14.00.0639.021.
- Exchange Server 2013 a été publié pour la première fois en décembre. 3, 2012, comme build 15.00.0516.032.
- Exchange Server 2016 a été publié pour la première fois en octobre. 1, 2015, en tant que version 15.01.0225.042.
- Exchange Server 2019 a été publié pour la première fois en octobre. 14, 2018, en tant que version 15.2.221.12.