Miscosoft Exchange
Active Directory & DNS
- Architecture Deciplex
Configuration Serveur:
Nom du serveur: SRV
IP serveur : 10.0.0.1/16
Gateway: 10.0.0.254
DNS:10.0.0.1
- Installation Domaine Deciplex.lan
Ceci est un pré-requis Active Directory avant l’ installation Exchange2010:
Le niveau fonctionnel de la forêt doit être supérieur ou égal à Windows 2003.
Configuration et Installation Exchange 2010
- Pre-requis avant installation Exchange
Le contrôleur de schéma doit impérativement exécuter Windows Server 2003 SP1 ou une version ultérieure.
Le niveau fonctionnel de la forêt doit être supérieur ou égal à Windows 2003.
L'annuaire doit aussi être préparé pour Exchange 2010.
- Installation du serveur IIS et du services de certificats Active directory
Avant d'installer le premier serveur Exchange 2010 de l'organisation, il faut désinstaller tous les serveurs exécutant Exchange 5.5 car cette version n'est plus supportée et ne peut pas cohabiter avec Exchange 2010 au sein de la même organisation.
- Activer le service service de partage de ports Net.tcp.
L’une des nouveautés apportée avec Exchange 2007 était la gestion du routage qui est dorénavant basée sur les sites Active Directory.
Pour que le routage des messages fonctionne correctement, il faut définir correctement les objets sites Active Directory ainsi que les liens intersites.
Le routage des messages étant assuré par le serveur "hub transport", il faut donc installer un serveur hub dans chaque site Active Directory possédant un serveur Exchange avec le rôle messagerie.
Comme pour les précédentes versions, il faut qu'un serveur de catalogue global soit présent dans chacun des sites Active Directory où un serveur Exchange 2010 est déployé.
Dans l’idéal l’architecture Active Directory doit respecter les points suivants :
Nom de domaine AD à deux niveaux ou plus et donc pas de « single domain name ».
Les contrôleurs de domaine doivent exécuter une version 64 bit de Windows Server.
Les contrôleurs de domaine doivent disposer d’une quantité de mémoire suffisamment élevée pour mettre en cache la base « ntds.dit ».
- Allez dans le dossier et lancez le setup.exe.
- Cliquez sur "Choisir l'option de langue d'Exchange" puis "Installer uniquement les langues à partir du DVD". Il y a les langues les plus répandues sur le DVD.
- L’installateur met un peu de temps à se lancer, puis une nouvelle fenêtre s'ouvre avec une petite introduction. Cliquez sur suivant.
- Faites Suivant, sauf si vous voulez envoyer les messages d'erreur à Microsoft.
- Cette étape permet de définir si l’on veut installer des rôles bien spécifiques ou si l’on veut une installation standard. Nous allons utiliser l'installation par defaut.
- Ici nous voyons les différents rôles que nous utiliserons
Rôle Transport Hub : routage des messages
Ce rôle gère le routage et la remise des messages dans l'organisation Exchange. Il gère également la transmission de messages hors de l'organisation. Il peut également filtrer les messages ou appliquer des règles de routage configurées par l'administrateur. Ce rôle peut également journaliser les messages pour se conformer aux réglementations en vigueur.
Rôle CAS : Client Access Server ou rôle d'accès client
ce rôle va servir aux clients pour accéder à leur compte Exchange. Cela comprend les accès Outlook, Outlook Web App, Outlook AnyWhere et ActiveSync. C'est ici que les clients vont se connecter.
Rôle Mailbox : boîtes aux lettres
Ce rôle héberge les boîtes aux lettres de chaque utilisateur, matériel ou salle de l'organisation Exchange. Il héberge également les carnets d'adresses et permet la planification de réunions et des ressources associées.
Rôle Edge : passerelle email
Ce rôle est indépendant d'Active Directory et est généralement placé en DMZ. Il s'agit d'une passerelle email qui peut accepter les emails provenant d'Internet ou de serveurs d'organisations externes clairement identifiés. Ce serveur va pouvoir procéder à un scan antispam et antivirus grâce à Forefront Protection for Exchange. Les emails entrants ayant passé l'hygiène de messagerie seront routés vers les serveurs Transport Hub de l'organisation. Ce rôle ne peut pas être colocalisé avec d'autres rôles d'Exchange.
Rôle UM : Unified Messaging ou messagerie unifiée
Depuis Exchange 2007 SP1, un cinquième rôle a été ajouté : la messagerie unifiée. Ce rôle permet la réception des messages vocaux et fax dans la boîte aux lettres de l'utilisateur. Il permet également la consultation d'Exchange depuis un téléphone : vous pouvez ainsi écouter vos messages vocaux, emails et réunions. Vous pouvez également créer des messages ou contacter directement des personnes grâce à la consultation de votre carnet d'adresses. Le serveur vocal est capable de reconnaitre la voix (sans nécessiter de configuration préalable) ou alors de fonctionner en DTMF (touches numériques de votre téléphone).
- Choisissez le nom de votre organisation. Ce n'est pas un nom de domaine qui est demandé mais d'organisation. Ne mettez pas votre domaine de messagerie. Ce nom n'a pas vraiment de rapport avec les autres éléments de la messagerie, c'est un nom qui doit englober l'ensemble des objets (personne, ressource,...) intégrés à la messagerie. Dans mon cas, le nom de mon entreprise.
- Ici, nous allons déterminer les clients de messagerie qui seront utilisés. Si vous êtes sûr de ne pas avoir de client Outlook 2003, cochez non. Il sera toujours possible après l'installation de rajouter cette fonction.
- Ici nous indiquons si le serveur sera frontal (prot forwarding) sur internet ou si nous utiliserons d'autres serveurs en amont (Edge, reverse proxy, ...). Je décide de mettre mon serveur en frontal, je spécifie le nom DNS utilisé sur internet pour joindre mon serveur de messagerie.
- Une fois encore, on nous demande de participer à un programme d'envoi de messages à Microsoft. Choisissez "je ne souhaite pas participer au programme pour l'instant" et faites Suivant.
- Un test de préparation va être lancé. L'installeur va vérifier si le serveur a bien tout les éléments nécessaires pour l'installation d'Exchange Server 2010.
- Description du test:
La première étape consiste toujours à mettre à jour le schéma Active Directory. Pour se faire, il faut exécuter la commande :
- setup.com /PrepareSchema
Une fois la commande terminée, il est possible de vérifier sa bonne exécution en observant directement le contenu du schéma. Pour cela le plus simple reste d'utiliser la console Schéma Active Directory.
Composant logiciel enfichable Schéma Active Directory : Vous pouvez utiliser cet outil pour visualiser la configuration des attributs et classes. Vous pouvez par exemple modifier les attributs d’objets qui seront répliqué sur le catalogue global par exemple. Pour pouvoir utiliser ce composant, vous devez enregistrer la librairie DLL suivante : regsvr32.exe schmmgmt.msc
La seconde étape consiste à exécuter la commande
- setup.com /PrepareAd /OrganizationName:<nom-organisation>
Dans un premier temps, la commande /PrepareAd crée l'organisation Exchange dans la partition de configuration de l'annuaire. L'organisation Exchange représente la configuration complète du système de messagerie de la forêt Active Directory. Il est possible de visualiser cette configuration en procédant comme suit :
Lancer la console ADSIEdit (par exemple via le raccourci adsiedit.msc)
Sélectionner la partition de configuration
Développer CN=Configuration,DC=domaine,DC=suffixe, puis CN=Services
Si la commande /PrepareAd s'est exécutée correctement, un conteneur nommé Microsoft Exchange doit être présent. Ce conteneur contient lui-même un autre conteneur portant le nom de l'organisation indiqué au niveau de la commande /PrepareAd.
L'utilisation du commutateur /OrganizationName est obligatoire si et seulement si aucune version précédente d'Exchange n'est présente. En effet dans le cadre d'une migration depuis Exchange 2000/2003 vers Exchange 2010, l'organisation est déjà présente.
Dans un second temps, la commande /PrepareAd, va créer un certain nombre d'objets dans la partition de domaine (c'est l'équivalent de la commande /PrepareDomain).
Voici la liste de ces objets :
- Exchange Organization Administrators (les membres de ce groupe ont un accès en lecture/écriture à la configuration Exchange)
- Exchange Recipient Administrators (les membres de ce groupe peuvent modifier les attributs Exchange sur les comptes utilisateurs)
- Exchange Servers (ce groupe contient tous les serveurs Exchange de l'organisation)
- Exchange View-Only Administrators (les membres de ce groupe peuvent uniquement lire la configuration Exchange)
- ExchangeLegacyInterop (ce groupe est uniquement utilisé lorsque l'organisation contient des serveurs Exchange 2000/2003)
- Microsoft Exchange Security Groups centralisant les 5 groupes
- Cliquez sur installer. Il se peut qu'il reste quelques messages d'avertissement. Cela n'est pas très grave.
- Installation terminée, décochez "Finalisez l'installation ..." et redémarrez le serveur.
- Autre solution pour l’installation d’Exchange 2010
Vous pouvez installer Exchange 2010 sur les éditions Standard, Enterprise et Datacenter de Windows Server 2008 R2 en version complète (Exchange ne peut pas s’installer sur la version Core ou sur une édition Web Server).
Sur les serveurs hébergeant les rôles HUB et Mailbox, installez le Office Filter Pack qui permet l’indexation des documents Office dans le moteur de recherche d’Exchange.
Pour installer les prérequis spécifiques aux rôles Exchange lancez une console Windows PowerShell, tapez Import-Module ServerManager et lancez le script correspondant aux rôles que va accueillir votre serveur :
CAS, Hub, et Mailbox
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy
Set-Service NetTcpPortSharing -StartupType Automatic
CAS
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy
Set-Service NetTcpPortSharing -StartupType Automatic
HUB ou Mailbox
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server
UM
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience
Edge
Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS
Ensuite redémarrez le serveur et lancez l’installation de Exchange par l’interface graphique ou par les commutateurs en ligne de commande décrites plus loin.
Ensuite redémarrez le serveur et lancez l’installation de Exchange par l’interface graphique ou par les commutateurs en ligne de commande décrites plus loin.
- Installer le serveur Exchange avec les trois rôles principaux (Hub, Cas et Mailbox) en ligne de commande:
setup.com /mode:install /roles:HT,CA,MB /EnableErrorReporting /TargetDir: "C:\Exchange2010" /DomainController
- Désinstallation d’exchange :
setup.com /mode:uninstall /roles:HT,CA,MB
/AnswerFile <chemin> (ou /af) Indique le chemin vers un fichier de réponse
/DomainController (ou /dc) Permet d'indiquer le contrôleur de domaine qui sera utilisé pour lire ou écrire des informations dans l'annuaire.
/EnableLegacyOutlook (rôle Mailbox Uniquement) Indique que les clients antérieurs à Outlook 2007 seront supportés - ce commutateur doit uniquement être précisé lors de l'installation du premier serveur Exchange 2010 "Messaging" dans l'organisation.
/Mode:<nom-du-mode> (ou /m)Permet de spécifier si l'opération correspond à une installation (valeur "install") ou à une désinstallation (valeur "uninstall").
/Roles:<liste-de-rôles> ou /role:<liste-de-rôles> ou /r:<liste-de-rôles>
Permet de spécifier les rôles qui doivent être installés sur le serveur. Voici la liste des valeurs supportées:
- HubTransport ou HT ou H
- ClientAccess ou CA ou C
- Mailbox ou MB ou M
- UnifiedMessaging ou UM ou U
- EdgeTransport ou ET ou E
- ManagementTools ou MT ou T
/TargetDir (ou /t)
Permet d'indiquer le répertoire où sera installé Exchange 2010 (par défaut il s'agit de %programfiles%\Microsoft Exchange Server)
Une fois le serveur Exchange installé Activé les services POP et IMAP.
Configuration du certificat
Par défaut, Exchange se crée un certificat auto-signé qu'il assigne aux différents services. Le problème de ce genre de certificat est qu'on ne peut pas lui faire confiance.
Dans la fenêtre de configuration du serveur nous allons installer un nouveau certificat Exchange.
- Nous indiquons ici le nom de notre nouveau certificat.
- Nous configurons le nouveau certificat. Ainsi le Serveur d’accès client (Outlook Web App) doit être configuré sur l’intranet et sur l’internet et permettre l’accès client via les protocoles POP/IMAP.
- Notre fichier .req est maintenant généré et apparait sur le bureau.
Il faut maintenant lancer l’interface de certificat pour effectuer une nouvelle demande https://localhost/certsrv/
- Soumettre une demande de certificat en utilisant un fichier CMC puis copier/coller le contenu de notre « .req » dans la demande enregistrée en définissant un modèle de certificat de type Serveur Web.
- Le nouveau certificat est ainsi généré et apparait sur notre bureau. Il faut maintenant affecter des services au certificat via l’interface d’Exchange.
Il ne reste plus qu'à assigner le certificat aux services Exchange. Vous pouvez le faire en mode graphique ou Powershell.
- Dans la configuration serveur, faites un clic droit sur le certificat que vous venez de créer puis Affecter des services au certificat.
- Sélectionner le ou les serveurs auxquels vous souhaitez attribuer les certificats.
Vous devrez ensuite sélectionner les services que vous souhaitez sécuriser avec ce certificat.
Dans notre cas, on souhaite utiliser IMAP POP , sécuriser SMTP, notamment si vous avez des partenaires ou clients (au sens commercial et non réseau) qui vous envoient des documents confidentiels. Je sélectionne IIS qui gère Autodiscover, OWA et Outlook Anywhere dans une certaine limite. Le rôle de messagerie unifiée n'étant pas installé, il est inutile d'y assigner le certificat.
Notre certificat deciplex est ainsi valide pour notre serveur Exchange en tenant compte de nos services personnalisés, IMAP, POP, IIS et SMTP.
Ne pas oubliez d’activer les services pop et imap.
OWA
- Outlook Web App :
Outlook Web App permet un accès Web à votre boîte Exchange. Depuis Exchange 2007, OWA se rapproche le plus possible du client lourd Outlook. Il est possible de configurer cet accès Web de manière poussée. Il faudra aller dans la configuration du serveur d'accès client.
Ouvrez les propriétés du site OWA "owa (Default Web Site).
Vous pourrez modifier l'authentification d'OWA, activer ou non différentes fonctionnalités, gérer les accès aux fichiers et notamment le WebReady Document Viewing qui permet la visualisation des documents Office, Pdf, etc. en format html. En revanche, il n'est plus possible d'accéder à un serveur de fichiers depuis OWA. Il semblerait que la présence de la gestion de l'accès aux serveurs de fichiers soit un bug de la version finale d'Exchange.
Afin de simplifier la vie de vos utilisateurs, vous pouvez changer le type d'authentification d'OWA. Par défaut, vous devrez vous connecter avec votre identifiant SAM (DOMAINE\utilisateur) sur un formulaire. Il est possible de se connecter avec son identifiant SAM, UPN ou utilisateur (en forçant un domaine précis). Vous pouvez également utiliser une authentification standard (intégrée Windows, Digest ou Basic). La méthode d'authentification que nous définissons est Authentification intégrée à Windows
Pour changer la méthode d'authentification, allez dans les propriétés d'OWA, onglet Authentification puis choisissez votre méthode d'authentification.
Pour obtenir la commande PowerShell équivalente, cliquez sur la petite icône Powershell en bas de la fenêtre après avoir changé votre méthode d'authentification.
Gestion Exchange
Nous mettons en place un script powershell permettant l’importation depuis un fichier csv des utilisateurs ainsi que la création d’Unité d’Organisation, la création de Mailboxdatabas avec l’activation des boites mails utilisateurs et leur création dans leur groupe de distribution.
Mount-Database -Identity Deciplex\$departement : cette instruction permettant de monter les différentes bases de données n’est pas fonctionnelle sur notre infrastructure test. Le nombre de bases de données étant visiblement trop important.
Stratégie de gestion des Sauvegardes & haute disponibilité
Gardons à l’esprit que la mise en place d’un plan de sauvegarde permet de répondre à deux types de besoins :
- Restauration suite à un sinistre naturel : Le serveur ou un disque dur tombe en panne, il faut tout restaurer pour remettre en production le système.
- Restauration suite à une erreur humaine : Un utilisateur supprime par erreur un email ou une boîte aux lettres et il faut restaurer spécifiquement cet élément sans toucher au reste du contenu en production.
En résumé, la sauvegarde ne sert qu’à se prémunir d’un crash « complet » des serveurs nécessitant le rechargement de la totalité des informations.
La sauvegarde de la messagerie est longue (créneau horaire, multi-sites) et les sauvegardes complètes souvent préférées deviennent impossibles à réaliser dans le temps imparti car elle coûte cher.
Les logiciels de sauvegarde, le matériel spécifique et le support de stockage reviennent généralement 2 fois plus chers que la messagerie elle-même et sont très rarement utilisée : les contraintes de restauration, l’espace disque nécessaire, la complexité des procédures, les risques d’erreurs de manipulation, le temps passé.
Pour ces différentes raisons, et parce qu’il est facile de se prémunir de risques majeurs au niveau des disques et des serveurs grâce à Exchange 2010 et le DAG (Groupe de disponibilité de bases de données).
Les fonctionnalités de haute disponibilité dans l’environnement Exchange2007 reposaient essentiellement sur une fonctionnalité le « log shipping ». Fonction qui, tirait les journaux de transaction d’un groupe de stockage d’un serveur actif vers un serveur passif, qui, à son tour inspectait et rejouait ces derniers sur une base copiée au préalable. Si le principe reste le même, (mis à part que les journaux sont désormais poussés), au sein d’un «Groupe de disponibilité de bases de données», certains éléments de configuration changent.
Le premier changement provient de l’architecture elle-même qui ne se base plus sur un environnement clusterisé, ou presque. Les membres d’un DAG qui sont en réalité des serveurs d’infrastructures Exchange sans être lié à l’évolution des services Windows FCS.
Côté réplication, environnement CCR en raison de l’obligation de conserver au sein d’un groupe de stockage une et une seule base de données. Le DAG se compose au maximum de 16 serveurs de boîtes aux lettres qui vont répliquer entre eux leurs bases de données. Ainsi, la base de données
MBX1 sur le serveur EXDAG1 se duplique vers le serveur EXDAG2.
Ainsi Les risques majeurs sont couverts par le DAG qui sauvegarde jusqu’à 16 copies sur 16 serveurs différents d’une même banque. Les risques mineurs sont couverts par une augmentation de la période de conservation des éléments supprimés (par exemple, 3 mois au niveau du système), une augmentation de la durée de conservation des messages entrants/sortants au niveau du rôle HUB et un système d’archivage.
L’intérêt est multiple, les bases de données seront dupliquées sur plusieurs serveurs faisant partie du DAG permettant d’envisager la mise en place d’un serveur sur un site de PRA. D’autre part, ces configurations rompent avec le schéma traditionnel « Actif passif » car toutes les bases n’ont pas l’obligation d’être actives sur un et un seul serveur. La répartition des charges entre les serveurs, même si elle reste manuelle, sera une réalité.
Côté réseau, la dépendance aux latences réseaux (round trip delay) entre les serveurs a cependant été revue à la hausse et passe d’une limite de 0,5 secondes pour un CCR Exchange 2007 à 250 millisecondes pour un DAG Exchange 2010.
DAG est ces fonctionnalités :
- Haute disponibilité avec le DAG : Si un disque ou un serveur tombe en panne, les réplicas de cette base prennent le relai et le service n’est pas arrêté.
- Copie décalée d’une base de données (DAG) : Si un contenu n’est plus disponible dans la base de données en production, il est possible de revenir à un état antérieur de la base sur un serveur dédié pour récupérer le contenu.
Depuis Outlook 2007, en cas de crash d’un serveur et reconfiguration d’une boîte vide, les données sont alors resynchronisées depuis la copie locale de la boîte, ce qui en fait l’équivalent d’une copie supplémentaire.
Exchange 2010 facilite le stockage et la recherche grâce à ces autres fonctionnalités :
- Boîtes aux lettre d’archive : Les utilisateurs ne sont plus obligés de recourir aux fichiers d’archives locaux (fichiers .pst), ils peuvent maintenant sauvegarder leurs archives dans l’infrastructure Exchange.
- Rétention des emails : Même si les emails sont supprimés de la corbeille de la boîte aux lettres de l’utilisateur, il pourra les récupérer de manière autonome.
- Rétention légale (Legal Hold) : Si pour des raisons légales, le contenu d’une boîte aux lettres ne doit jamais être supprimé, un administrateur spécifiquement désigné pourra toujours le récupérer.
- Rétention des boîtes aux lettres : Si un utilisateur possédant une boîte aux lettres est supprimé, sa boîte aux lettres peut être réassociée à un autre utilisateur.
- Sauvegarde / Restauration : Si toutes ces solutions n’ont pas permis de récupérer ou de restaurer les données, il est toujours possible de s’appuyer sur les mécanismes classiques de sauvegarde et de restauration.
Architecture du DAG
2 serveurs Exchange (DAG) avec les rôles mutualisés et un HLB :
Un HLB (équilibreur de charge matériel) peut être utilisé pour effectuer le rôle de partage de charge entre les deux serveurs y compris pour le service RPC Client Access Service (RPC EndPoint port 135 et les ports entre 1024-65535). En règle générale, puisque nous mettons en œuvre une haute disponibilité, cela signifie que nous installerons probablement 2 équilibreurs de charge matériel afin de combler la défaillance du premier en cas de besoin.
Le HLB est la solution la plus adapte en termes de connectivité utilisateur. En effet, Microsoft recommande l’utilisation de celui-ci dans le cas où vous mettez en place plus de 7 noeuds HUB/CAS dans une ferme de serveur. Cette solution reste la plus chère par contre, de plus la mise en place suivant les constructeurs peut être fastidieuse.
L’ajout de nouveaux serveurs dans ce DAG se fera exactement de la même façon. Une base peut être répliquée sur un serveur du DAG ou sur l’ensemble des serveurs du DAG. Si votre DAG ne comprend que deux noeuds, vous ne pourrez avoir que deux copies par base.
Dans ce cas, il est conseillé de configurer les disques des serveurs en RAID afin de sécuriser les disques. En effet, si vous ne sécurisez pas les disques, en cas de problème sur l’un des disques d’un serveur, il n’y aura plus qu’une seule réplique avant de perdre les informations.
- Etapes pour monter un DAG :
- Installation d’un serveur Exchange 2010 autonome. Vous pouvez n’y installer que le rôle MBX ou l’ensemble des rôles CAS, HUB et MBX.
- Vous allez ensuite installer un autre serveur autonome. En utilisant la console Exchange ou Powershell, vous devrez créer un DAG, c'est-à-dire, le nom du regroupement des serveurs. C’est lors de cette étape qu’il est demandé le nom du FSW ainsi que le serveur qui l’hébergera.
- L’étape suivante consiste à ajouter les deux serveurs précédemment installés dans le DAG.
- La dernière étape consiste à créer les bases de données sur l’un des deux serveurs et de définir si vous souhaitez, pour chaque base, si elle doit être répliquée sur l’autre serveur. La seule condition à cette réplication est que le disque cible doit avoir le même chemin que le disque source.
- Mise en place d’une copie du DAG en décalée :
Suite à l’implémentation d’un DAG, il est possible d’avoir une copie d’une base décalée dans le temps.
Cette copie décalera l’intégration des journaux de transaction issue de la réplication et permettra de revenir à une version antérieure de la base.
La configuration de la copie décalée se fait à l’aide de l’invite de commande Exchange Management Shell et de la commande :
- Set-MailboxDatabaseCopy.
Les paramètres à configurer sont -ReplayLagTime et -TruncationLagTime. Ils peuvent accepter 14 jours comme valeur maximum.
- Stratégie de sauvegarde :
Il est important d’utiliser pour le processus de sauvegarde un logiciel qui supporte les API de sauvegarde d’Exchange. Ainsi, les sauvegardes seront faites à chaud (utilisation du Shadow Copy) et les journaux de transactions seront supprimés en regard à la stratégie de sauvegarde choisie.
Les critères déterminant le choix est basé principalement, sur le temps de sauvegarde et de restauration et la complexité des procédures.
Choisissez une sauvegarde au niveau des briques car Les sauvegardes au niveau des briques copient chaque message de chaque boîte aux lettres. Cette sauvegarde est beaucoup plus longue mais permet une restauration sélective (juste un email ou une boîte) plus rapide.
Les paramètres de l’organisation Exchange sont stockés dans la partition configuration d’Active Directory. Ainsi le premier élément à sécuriser est Active Directory avec notamment la sauvegarde de l’état du système.
- Données à sauvegarder :
- Les paramètres de l’organisation Exchange sont stockés dans la partition configuration d’Active Directory. Ainsi le premier élément à sécuriser est Active Directory avec notamment la sauvegarde de l’état du système.
- Puis chaque rôle va nécessiter des paramètres de sauvegarde spécifique :
Mailbox : les bases de données, …
CAS : les certificats et les paramètres IIS, …
Il convient donc d’adapter la sauvegarde de ses serveurs à l’architecture.
Privilégiés l’export des boîtes aux lettres directement en PST. Cette fonctionnalité permet la mise à disposition facile d’archives aux utilisateurs mais peu aussi permettre la mise en place d’une procédure de sauvegarde simplifiée pour les petites structures.
En conclusion, chaque architecture est différente et nécessite de faire le bon choix en ce qui concerne la Haute disponibilité sur des serveurs mutualisés. Une solution que nous n’avons pas présenté car elle nécessite l’infrastructure adéquate pour ce faire.
Il s’agit d’un HUB/CAS virtuel (VmWare ou Hyper-V) en plus des 2 serveurs Mailbox en DAG. Ce serveur virtuel aurait la notion de HA entre les ESX ou entre les hyperviseur donnant lieu à une machine virtuelle pouvant se balader au sein des environnements. La haute disponibilité serait assurée par la partie VmWare ou Hyper-V (Attention, cette infrastructure ne préviens pas d’une panne de service pour cette raison que nous ne la présentons pas comme de la haute disponibilité Exchange)
Aucun commentaire:
Enregistrer un commentaire