Frédéric Laubel's Blog

Exchange Server Tips & Tricks

Archives de la catégorie ‘Architecture’

Exchange 2010: Préparez vous dès aujourd’hui

Publié par Frédéric Laubel le avril 25, 2009


exchange20101

La version final de Exchange 2010 sortira dans plusieurs mois: cela vous laisse largement le temps de mettre à niveau votre environnement pour être en phase avec les pré-requis !

Au delà de la liste exhaustive de l’ensemble des pré-requis, voyons quels sont éléments important à prendre en considération dès aujourd’hui avant la mise en place du premier serveur Exchange 2010.

NB: Mise à jour après la sortie de la Release Candidate (RC).

Active Directory

Notez que des changements mineurs peuvent encore intervenir d’ici la sortie de la version finale.

  • Niveau fonctionnel Windows 2003 natif
    Il n’est pas possible d’installer Exchange 2010 dans un domaine Active Directory ayant un niveau fonctionnel inférieur à Windows 2003. Si c’est votre cas, il faut augmenter le niveau fonctionnel de votre domaine en Windows 2003 natif. Cela sous entend donc de supprimer tous les contrôleurs de domaine Windows 2000, ce qui ne doit pas être très problématique vu l’ancienneté de Windows 2000. Je rappelle qu’il est fortement recommandé de procéder à un état des lieux complet de votre environnement d’annuaire avant migration: une infra Active Directory dans un mauvais état c’est une infra Exchange dans un mauvais état !
  • Le Maitre du Schéma (schema master)  doit être au minimum en Windows Server 2003  Service Pack 1 Service Pack 2
  • Les catalogues globaux utilisés par Exchange doivent être au minimum en Windows Server 2003 Service Pack 1 Service Pack 2

Système d’Exploitation

  • Windows Server 2008 SP2 ou Windows Server 2008 R2
    Ce qui était fortement conseillé avec Exchange 2007 SP1 est maintenant devenu obligatoire : un serveur Exchange 2010 de production ne s’installe que sur du Windows Server 2008. Plus exactement Windows Server 2008 SP2 ou Windows Server 2008 R2.  N’attendez pas pour mettre à jour vos connaissances sur cet OS !

Exchange 2003/2007

Il est possible de mettre à niveau une organisation Exchange 2003 ou Exchange 2007 vers Exchange 2010.

  • Exchange 2003 SP2
    L’ensemble des serveurs Exchange 2003 de l’organisation doivent posséder le Service Pack 2.
  • Exchange 2007 SP2
    L’ensemble des serveurs Exchange 2007 d’un site Active Directory concerné par la migration doivent être en SP2. De plus dans une architecture multi-sites il est nécessaire de mettre à jour l’ensemble des serveurs CAS de l’organisation vers Exchange 2007 SP2.

Par ailleurs il est utile d’avoir en tête les éléments suivant :

  • L’outil de sauvegarde intégré dans Windows 2008 ne permet pas de sauvegarder Exchange 2007 SP1 ou Exchange 2010.  Habituez vous dès aujourd’hui à sauvegarder Exchange en VSS avec un outil dédié.
  • Le Cluster à stockage partagé (SCC) n’existe plus dans Exchange 2010. Inutile d’investir aujourd’hui dans ce type d’infrastructure pour la messagerie.
  • Avec la réduction des I/O disques (environ -50%) et la modification du type d’I/O (diminution sensible des écritures aléatoires et augmentation des écritures séquentielles) privilégiez plutôt des solutions de stockage à moindre coût (SAN devenu inutile en terme de sécurisation des données ou de performances).
  • Les versions d’Outlook antérieurs à 2003 ne sont pas supportées avec Exchange 2010. Migrez vers Outlook 2007 : avec le SP2 les performances d’Outlook font un bon en avant ! (le SP2 n’est pas encore public).
  • Exchange 2010 inclu une solution d’archivage : pourquoi investir maintenant dans une solution tierce partie onéreuse ?

Exchange 2010 est réellement plus simple (plus de gestion du clustering, interface graphique pour générer les certificats, PRA plus simple, DAG…), moins cher (HA possible avec deux serveurs contre quatre pour Exchange 2007, moins de disques (JBOD), disques moins onéreux ), plus performant (support sans problème de BAL de plusieurs Giga), et plus riche (archivage inclu, RMS) que Exchange 2007 !!! Ce millésime 2010 va faire du bruit !!

Publié dans Architecture, Exchange 2010 | Commentaires fermés

Exchange 2010 BETA est rendu public: première FAQ

Publié par Frédéric Laubel le avril 15, 2009


Cet article participe au jeu-concours Technet et concerne la question suivante :

image002

Les outils d’administration de Microsoft Exchange Server 2010 peuvent être installés sur … ? :

Windows 7 x64 (64 bits) uniquement.
Windows Vista SP1 x64 (64 bits) et Windows XP SP3 x64 (64 bits).
Windows Server 2008 SP2 x64 (64 bits), Windows Server 2008 R2 x64 (64 bits) et Windows 7 x64 (64 bits).

exchange2010

C’est officiel, j’ai donc maintenant le droit d’en parler, Youpi :)
La prochaine version d’Exchange qui succédera à Exchange 2007 se nommera…Exchange 2010. J’aurais l’occasion d’y revenir en détails.

Update du 30/08/09:
Mise à jour après la sortie de la Release Candidate (RC).

Update du 18/04/09:
Après l’annonce de la mise à disposition public de la Bêta d’Exchange 2010, j’ai décidé de créer une première FAQ, afin de répondre aux questions les plus fréquentes.

FAQ Exchange 2010 :

interroQu’est-ce que Exchange 2010 ?
Exchange 2010 est le successeur d’Exchange 2007. Il est aussi connu sous le nom de code "Exchange 14".

interroExhange 2010 est-il disponible ?
Exchange 2010 est encore un cours de finalisation. Après une première version Bêta public, la version Release Candidate (RC) est disponible en libre téléchargement depuis le 17 aout 2009.

interro Quand Exchange 2010 sera t-il finalisé ?
Il est prévu que Exchange 2010 soit finalisé avant la fin de l’année 2009.

questionPuis-je tester Exchange 2010 sur une machine 32 bits ?
Non: Exchange 2010 n’existe qu’en 64 bits. Vous ne pouvez donc pas installer Exchange 2010 en environnement 32bits. Contrairement à Exchange 2007 il n’existe pas de version d’évaluation en 32 bits. Bref, Exchange 2010 s’installe uniquement sur du 64bits que ce soit pour un environnement de production ou un environnement de maquette.

interroJ’ai entendu dire que les dossiers public ont disparus. Est-ce vrai ?
Pas du tout ! Exchange 2010 supporte toujours les dossiers public. Il n’y a pas de changement dans ce domaine par rapport à Exchange 2007.

interroPuis-je migrer mon infrastructure Exchange 2007 SP1 directement vers Exchange 2010 ?
Non, il n’est pas possible de migrer directement de Exchange 2007 SP1 vers Exchange 2010. Il faut préalablement mettre à jour les serveurs Exchange 2007 SP1 vers Exchange 2007 SP2. Plus précisément la migration vers Exchange 2010 nécessite que l’ensemble des serveurs Exchange 2007 d’un site Active Directory concerné par la migration soient en SP2. De plus, dans une architecture multi-sites il est nécessaire de mettre à jour l’ensemble des serveurs CAS de l’organisation vers Exchange 2007 SP2.

interroPuis-je migrer mon infrastructure Exchange 2003 SP2 directement vers Exchange 2010 ?
Oui, il est possible de migrer directement depuis Exchange 2003 SP2 vers Exchange 2010, à condition que l’ensemble des serveurs Exchange 2003 de l’organisation possèdent le Service Pack 2.

interroQuel système d’exploitation pour Exchange 2010 ?
Exchange 2010 peut s’installer soit sur Windows Server 2008 SP2,  soit sur Windows Server 2008 R2. En plus de ces deux systèmes, les outils d’administration peuvent s’installer sur Vista SP2 ou sur Windows 7 (toujours en 64bits).

interroEst-ce que Exchange 2010 utilise un nouveau type de base de données ?
Non. Exchange 2010 utilise toujours des bases de type Jet/ESE. Cependant le code à était entièrement revu de manière à réduire sensiblement les I/O disques et améliorer la haute disponibilité.

questionDonc aucunes nouveautés concernant le stockage et le fonctionnement du Store ?
Au contraire !! Le code du Store à était entièrement revu et optimisé. Par exemple le Store est maintenant compressé et les IOPS disques ont diminués de presque 70% par rapport à Exchange 2007 (et oui encore !). Avec Exchange 2010 il est possible d’avoir des boites aux lettres >10Go ou des boites aux lettres contenant des dizaines de milliers d’élèments sans avoir de problèmes de performances. De même comme les IOPS sont maintenant massivement séquentiels et ont très fortement diminués, il est possible d’utiliser des disques SATA à 7200 RPM.

interroQuoi de neuf coté Clustering ?
C’est simple : plus de cluster. En effet le cluster à stockage partagé (SCC) n’existe plus, et le cluster à stockage répliqué (CCR) à été fondu avec la solution de PRA au sein d’une nouvelle solution : Database Availability Group (DAG). Le DAG combine donc les fonctionnalités de CCR et de SCR. Vous n’avez plus à gérer de couche cluster !! Cependant il existe toujours une dépendance vis à vis des outils de clustering mais la gestion du cluster (type de cluster, ajout de disques, etc…) est entièrement géré par Exchange. Du coup il est maintenant possible d’installer Exchange, puis d’activer plus tard la haute disponibilité si besoin.

interroEst-ce que Exchange 2010 supporte les domaines Single-Labeled Domain (SLD) ?
La version Bêta ne permettait pas d’installer Exchange 2010 dans un environnement SLD. La version RC autorise l’installation en SLD, mais rien n’est encore fixé concernant la politique de support de la version RTM.

interroPuis-je mettre le CD d’Exchange 2010 dans mon serveur Exchange 2007 SP2 est procéder à la mise à jour ?
Non. Il n’est pas possible de procéder à une simple mise à jour d’un serveur Exchange 2007 SP2 vers Exchange 2010. Il faut procéder à l’installation d’un serveur Exchange 2010, puis déplacer les boites aux lettres.

interroQuelles sont les versions d’Exchange 2010 ?
Exchange 2010 existe en deux versions : la version Standard et la version Entreprise. La version Entreprise est requise pour bénéficier de la haute disponibilité (DAG).

interroPuis-je installer Exchange 2010 sur une version Core de Windows Server 2008 SP2 ou sur une version Core de Windows Server 2008 R2 ?
Non. Il n’est pas possible d’installer Exchange en mode Core.

interroJ’ai entendu dire que Exchange 2010 incorporera une solution d’archivage, pouvez-vous nous en dire plus à ce sujet ?
Oui :). En effet une solution d’archivage est  inclue dans Exchange 2010. Les utilisateurs peuvent, d’un simple glisser-déposer dans Outlook, migrer leur .pst dans une archive. L’archive est consultable en ligne, depuis Outlook 2010 ou OWA. L’avenir nous dira si c’est la fin des fichiers .pst.

questionOù l’archive est-elle stockée ?
L’archive est stockée dans la même base de donnée que la boite aux lettres utilisateur. En fait l’archive est une seconde BAL liée au compte de l’utilisateur. Les utilisateurs ont donc deux boites aux lettres : la BAL principale et la BAL d’archive.

questionComment peut-on accéder à l’archive ?
L’archive est accessible depuis le client lourd Outlook 2010 ou depuis OWA 2010. L’archive est uniquement accessible en ligne, elle n’est pas synchronisée avec le fichier .OST (donc pas d’accès à l’archive quand Outlook 2010 est déconnecté).

questionQu’elle version d’Outlook pour se connecter à Exchange 2010 ?
Les versions d’Outlook qui sont supportées avec Exchange 2010 sont: Outlook 2010, Outlook 2007, Outlook 2003, et Outlook 2002. Certaines fonctions sont disponibles uniquement avec Outlook 2010 (archivage et MailTips).

Le site officiel du produit:
http://www.microsoft.com/exchange/2010/en/us/default.aspx

Le site Technet sur Exchange 2010 :
http://technet.microsoft.com/en-us/library/bb124265(EXCHG.140).aspx

Publié dans Architecture, Exchange 2010 | Commentaires fermés

Exchange 2007 et l’OAB : principe et dépannage

Publié par Frédéric Laubel le avril 15, 2009


INTRODUCTION

Dans cet article je vais présenter le principe de fonctionnement du carnet d’adresses en mode hors connexion, alias l’Offline Address Book, alias l’OAB, et les méthodes pour diagnostiquer et réparer ses dysfonctionnements.

En effet j’ai constaté que beaucoup de problèmes Exchange sont liés au carnet en mode hors connexion. Parmi les symptômes les plus révélateurs d’un problème avec l’OAB, nous pouvons noter :

- Absence de l’OAB pour Outlook 2007 (mais il est bien présent pour Outlook 2003 et antérieur);
- Des utilisateurs créés dans Exchange qui n’apparaissent pas dans Outlook 2007;
- Des demandes permanentes d’authentification dans Outlook 2007 (demande sans arrêt de login);
- Des erreurs 0X8004010F lors du téléchargement de l’OAB dans Outlook.

PRINCIPE DE FONCTIONNEMENT DU CARNET EN MODE HORS CONNEXION (OAB)

Le principe de fonctionnement de l’OAB n’a que peut évolué jusqu’à Exchange 2007 et Outlook 2007.

Avant Exchange 2007 et Outlook 2007

Jusqu’à Exchange 2007 et Outllook 2007 le principe de fonctionnement de l’OAB était simple : Exchange génère l’OAB dans un dossier public et Outlook récupére l’OAB depuis ce dossier public. Il n’y a pas d’autre alternatives possibles, c’est assez basique.

Depuis Exchange 2007 et Outlook 2007

Les choses ont fortement évolués avec Exchange 2007 : il est devenu possible, à condition d’utiliser Outlook 2007, de se passer complètement des dossiers publics pour la gestion de l’OAB : sa distribution se fait en mode Web via IIS. Cela va dans le sens de la "webisation" des services Exchange : la connectivité entre le poste client Outlook et l’infrastructure de messagerie se fait désormais en HTTPS pour l’ensemble des services : Outlook Anywhere, ActiveSync, Free/busy, OAB, OWA. Parmi les avantages de la mise à disposition en mode web de l’OAB, notons un contrôle beaucoup plus fin des points de distribution (de simple URL) et un gain en bande passante (téléchargement via BITS). Notez que la mise à disposition de l’OAB en mode web n’est possible que depuis Exchange 2007 et il est nécessaire de disposer d’Outlook 2007. Les versions antérieurs d’Outlook continueront à se connecter directement sur les dossiers publics.

Je vais traiter en détails du fonctionnement de l’OAB dans une architecture Exchange 2007 et Outlook 2007.

ARCHITECTURE

Commençons par comprendre l’architecture logique pour ensuite allez plus loin dans le fonctionnement.

Schéma logique

Rien de vaut un schéma pour bien comprendre :)

Le schéma représente le processus logique de génération de l’OAB pour Outlook 2007. Dans cet exemple les postes clients Outlook 2007 appartiennent au même site Active Directory que les serveurs Exchange 2007. Cette précision est importante : En effet dans une architecture où les postes clients se trouvent à l’extérieur de l’organisation Exchange ou dans un site Active Directory différent des serveurs Exchange le processus est sensiblement différent.

oab3

J’ai distingué le processus de génération coté serveur (flux en bleu), du processus de récupération de l’OAB par Outlook 2007 (flux en vert).

Fonctionnement coté serveur

Il y a deux grandes étapes : la génération de l’OAB par le serveur Mailbox, puis la mise à disposition  aux clients de l’OAB par le serveur CAS. Et oui : le serveur responsable de la génération de l’OAB  est différent du serveur responsable de sa mise à disposition. Voyons en détails :

  1. Le service MSExchangeSA est responsable de la génération de l’OAB. Ce service est présent uniquement sur le rôle Mailbox. Il initie la génération de l’OAB, une fois par jour par défaut, via le fichier OABGEN.DLL en mettant les fichiers créés dans un dossier partagé.
  2. Le service MSExchangeFDS est reponsable de la copie de l’OAB depuis le serveur Mailbox vers le serveur CAS, par défaut toutes les 8 heures. Ce service est présent uniquement sur le rôle CAS. Une fois sur le serveur CAS l’OAB est mis dans un dossier WEB partagé. A ce moment L’OAB peut être téléchargé par Outlook 2007.

Allons encore plus loin :
Le service MSExchangeSA (Microsoft Exchange System Attendant) se nomme dans la version française d’Exchange 2007 "Microsoft Exchange – Surveillance du système". Le binaire (.exe) associé à ce service est MAD.EXE.

Version US :

msexchangesa

Version française :

surveillancesysteme

C’est MAD.EXE qui est responsable de la génération de l’OAB…enfin presque puisque si nous allons encore plus loin dans le détails nous voyons qu’il s’agit un fait d’une .dll gérée par MAD.EXE qui s’occupe spécifiquement de l’OAB :

oabgen

Résumons : Le service MSExchangeSA gère le binaire MAD.EXE qui lui même fait appelle à la .dll OABGEN.DLL pour créer l’OAB sur le serveur Mailbox.

Pour en avoir la certitude lançons des outils d’analyse :
creationoab1

Bingo ! Nous voyons bien que MAD.EXE créé les répertoires qui vont accueillir l’OAB. Le dossier par défaut est  [LettredeLecteur]:\Program Files\Microsoft\Exchange Server\ExchangeOAB. Notez que les fichiers ne sont pas créés directement dans le répertoire cible : ils sont d’abord créés dans un répertoire temporaire qui est C:\Windows\TEMP.

Une fois le processus de création validé dans  C:\Windows\TEMP les fichiers sont copiés dans le dossier qui devient partagé en \\[LeNomduServeur]\ExchangeOAB :

oab22

Une fois ces fichiers partagés le service MSExchangeFDS du serveur CAS peut venir les copier pour les mettre dans son partage WEB. Par défaut le service FDS va copier l’OAB depuis le serveur mailbox toutes les 8 heures. Le service MSExchangeFDS se nomme dans la version française d’Exchange 2007 "Distribution de fichiers Microsoft Exchange". Le binaire associé est MSExchangeFDS.exe.

Version française :

msexchangefdsfr

Version US :

fdsus

Retournons dans les outils d’analyse pour observer le comportement du service MSExchangeFDS :

2009-04-13_192317

Nous voyons que le binaire MSExchangeFDS.exe va lire le contenu du dossier partagé se trouvant sur le serveur Mailbox. Ici le répertoire partagé du serveur mailbox est celui par défaut : \\[LeNomduServeur]\ExchangeOAB.

Ensuite les fichiers sont bien copiés du serveur mailbox vers le serveur CAS :

fdscopycas

Notez le même comportement que celui observé sur le serveur Mailbox : les fichiers ne sont pas mise à disposition imméditament, mais copiés préalablement dans un répertoire temporaire.

Finalement les fichiers sont copiés dans leur emplacement final, ici dans le répertoire par défaut:  [LettredeLecteur]:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\[GUID] :

fdsfinal

NB : Point important sur le délais entre une modification de l’OAB (par exemple la création d’une BAL) et le changement effectif dans l’OAB vu par l’utilisateur.

Par défaut le serveur Mailbox génére l’OAB seulement une fois par jour (très tôt le matin). Puis le service MSEXchangeFDS va copier l’OAB toutes les 8 heures. Enfin le client Outlook 2007 va mettre à jour l’OAB. Donc il est tout à fait normal que la création d’une boite aux lettres ne soit pas immédiatement visible dans Outlook ! Évidemment tout ceci est parfaitement modifiable.

Pour modifier le délais de génération de l’OAB sur le serveur Mailbox :

A partir de la console Exchange 2007, allez dans Configuration de l’Organisation / Boite aux lettres / et onglet Carnet d’adresses en mode hors connexion.

2009-04-15_122454

Là il est possible de forçer la mise à jour en choisissant "Mettre à jour", ou de modifier la fréquence de mise à jour en allant sur "Propriétés".

Pour modifier le délais de copie de l’OAB du serveur Mailbox vers le serveur CAS :

A partir de la console Exchange 2007, allez dans Configuration du serveur / Accès au client / et onglet Distribution du carnet d’adresses en mode hors connexion.

2009-04-15_122857
En allant dans les Propriétés, il est possible de changer la valeur par défaut qui est de 8 heures (480 minutes).

Coexistance entre Outlook 2007 et les versions antérieurs

Dans Configuration de l’Organisation / Boite aux lettres / et onglet Carnet d’adresses en mode hors connexion, allez dans les propriétés de l’OAB, puis sur l’onglet "Distribution".

Pour les versions d’Outlook antérieur à Outlook 2007 cocher uniquement les cases correspondants à vos versions d’Outlook. Pour permettre la distribution WEB de l’OAB avec Outlook 2007 il faut cocher dans "Points de distribution", "Activer la distribution Web", puis ajouter le serveur CAS qui sera responsable de la mise à disposition de l’OAB :

pointdedistrib

Fonctionnement coté client

Pour avoir connaissance des serveurs Exchange 2007 et connaitres les URL des services WEB, Outlook 2007 se sert d’un nouveau service présent dans Exchange : l’Autodiscover. Sachez seulement que ce service est responsable de la gestion des Services Web dans Exchange 2007, à savoir : la disponibilité, l’autodiscover, ActiveSync, et l’OAB. Ce service est présent uniquement sur le rôle CAS. Voyons comment Outlook 2007 procède pour récupérer l’OAB :

  1. Outlook envoi une requête LDAP sur un contrôleur de domaine pour connaitre les points de connexions du service Autodiscover (SCP). Il existe un SCP par serveur CAS. Le SCP contient des attributs permettant de localiser le service Autodiscover.
  2. Outlook se connecte à l’URL du service Autodiscover donné par l’Active Directory. Si cela ne fonctionne pas il va alors se connecter sur des adresses préconfigurées par défaut (Ex : https://autodiscover.modomaine.com/autodiscover/autodiscover.xml)
  3. Le service Autodiscover renvoi un fichier .xml contenant les URL pour se connecter sur les différents services web : URL de l’OAB, URL du service de disponibilité, etc…
  4. Outlook se connecte en HTTP(s) au partage IIS du serveur CAS pour récupérer l’OAB

Allez allons dans le détails :)

Outlook 2007 se connecte à l’Active Directory pour récupérer les ponts de connexions (SCP). Le SCP est créé lors de l’installation du rôle CAS. Le rôle du SCP est d’indiquer l’adresse du service Autodiscover pour les clients du domaine Active Directory. Si le poste n’est pas dans l’Active Directory, Outlook utilisera le DNS pour se connecter aux adresses prédéfinies du service Autodiscover (typiquement pour une connexion Outlook Anywhere).

Voyons à quoi ressemble un SCP :

scp23

Notez l’adresse du service Autodiscover qui est une URL en HTTPS qui pointe sur le serveur CAS -> https://%5BNomFQDNduServeurCAS/Autodiscover/Autodiscover.xml.

Une fois les SCP récupérés (dans le cas où il ya plusieurs serveurs CAS et plusieurs sites Active Directory), Outlook à connaissance de l'emplacement du service Autodiscover et il essai de se connecter en HTTP(s). La connexion établie avec le service Autodiscover et celui-ci renvoi à Outlook 2007 un fichier .xml contenant les adresses des différents services WEB. Ce fichier se nomme Autodiscover.xml.

Extrait d'un fichier Autodiscover.xml :

<Protocol>
<ASUrl>https://w2k3ori.xchangeall.local/EWS/Exchange.asmx</ASUrl&gt;
<EwsUrl>https://w2k3ori.xchangeall.local/EWS/Exchange.asmx</EwsUrl&gt;
<OOFUrl>https://w2k3ori.xchangeall.local/EWS/Exchange.asmx</OOFUrl&gt;
<UMUrl>https://w2k3ori.xchangeall.local/UnifiedMessaging/Service.asmx</UMUrl&gt;
<OABUrl>http://w2k3ori.xchangeall.local/OAB/176554e4-8aeb-4a1b-909b-b15525c237e7/</OABUrl&gt;
</Protocol>

Les adresses des différents services WEB sont bien présent : ASUrl pour le service de disponibilté, EWSUrl pour le service Web, OOFUrl pour le service Out Of Office, UMurl pour le service Unified Messaging, et enfin OABUrl pour le service de l'OAB.

Donc pour récupérer l'OAB Outlook 2007 sait maintenant qu' il doit  se connecter sur http://w2k3ori.xchangeall.local/OAB/176554e4-8aeb-4a1b-909b-b15525c237e7.

Notez que contrairement aux autres adresses, l'URL de l'OAB est en HTTP et non pas en HTTPS. Par défaut Exchange 2007 utilise des certificats auto-signés valables un an. Seulement BITS qui est utilisé pour le téléchargement de l'OAB ne sait pas géré ce type de certificat. Donc par défaut l'URL de l'OAB n'est pas en HTTPS. Il est cependant possible, et même conseillé, d'utiliser le HTTPS à condition de disposer d'un certificat valide (soit par une PKI interne, soit par l'achat d'un certificat public).

Maintenant que vous connaissez le principe de génération de l'OAB et sa mise à disposition des postes Outlook 2007 nous allons voir comment résoudre les problèmes qui peuvent se poser. De part l'architecture il n'est pas difficile de déviner quels sont les problèmes que l'on peut rencontrer : problème de génération sur le serveur mailbox, problème de copie ou de mise à disposition depuis le serveur CAS et enfin problème d'authentification ou de certificats depuis les postes clients.

TROUBLESHOOTING

Je vais vous montrer quelle est la méthodologie à utiliser pour résoudre un problème lié à l'OAB : tout d'abord analyse coté serveur Mailbox, puis du coté du serveur CAS, et enfin depuis le poste client.

Dépannage depuis le serveur Mailbox

Il faut tout d'abord vérifier à la source, donc directement depuis le serveur Mailbox qui est à l'origine de la génération de l'OAB.

Vérification des services

Le premier point à vérifier est de s'assurer que l'ensemble des services Exchange requis sont démarrés. Bien des problèmes sont  simplement du à des services qui ne démarrent pas ! (typiquement suite à l'installation d'un Rollup).

Pour vérifier l'état des services lancer le Shell Exchange et taper : Test-ServiceHealth

tshmbx

La première colonne indique le rôle du serveur, ici un serveur Mailbox, la deuxième colonne indique si les services sont requis, et les deux dernières colonnes indiquent l'état des services. Il ne doit pas y avoir de service dans la colonne "ServiceNorRunning". Si c'est le cas démarrez le service manuellement : démarrer / éxécuter et taper services.msc.

Vérifier que l'OAB soit correctement généré

Pour s'assurer que le serveur Mailbox arrive à générer correctement l'OAB il faut augmenter le niveau de logging. L'augmentation du niveau de logging permet d'enregistrer dans le journal Application de Windows tout le processus de génération de l'OAB. Ainsi en cas de problème vous n'aurez plus qu'à aller dans le journal Application pour voir d'où vient le problème.

Nous avons vu précédement que le service responsable de la génération est le service MSExchangeSA. C'est donc le niveau de logging de ce service que nous allons augmenter. Ceci se fait soit en mode graphique, soit en ligne de commande.

Je vous conseille fortement d'utiliser le programme Exchange 2007 Diagnostic Logging Tool :

oalgenlog

Le service à cibler est MSExchangeSA\OAL Generator en mettent un niveau de diagnostique à High.

Pour obtenir le même comportement en ligne de commande :

Set-EventLogLevel -Identity "MSExchangeSA\OAL Generator" -Level High

Maintenant en allant dans le journal Application nous voyons le détails des opérations de génération de l'OAB. En cas de problème des évenements en erreurs seront signalés, et dans le détails vous pourrez voir ce qui pose problème.

2009-04-12_153214

Dans le cas présent tout est bon : il n'y pas d'événements en erreurs ou en avertissement.

Vérifier la présence du dossier partagé et des autorisations

Par défaut le serveur Mailbox doit partager le dossier se trouvant dans [LettredeLecteur]:\Program Files\Microsoft\Exchange Server\ExchangeOAB en \\[LeNomduServeur]\ExchangeOAB. Il peut arriver que le partage ne se fasse pas. Dans ce cas il faut créer le partage manuellement et positionner les autorisations.

Les autorisations de partage sont :

  • Exchange Servers : Lecture
  • System : Contrôle Total
  • Administrateurs : Contrôle Total

2009-04-15_1006231

Les autorisations fichiers (ACL) sont :

  • Exchange Servers : Lecture et Exécution
  • System : Contrôle Total
  • Administrateurs : Contrôle Total

2009-04-15_100656

Nous avons fait le tour des actions à mettre en place coté serveur Mailbox. Maintenant il faut s’assurer que tout se déroule correctement sur le serveur CAS.

Dépannage depuis le serveur CAS

Vérification des services

Comme sur le serveur Mailbox le premier point à vérifier est de s’assurer que l’ensemble des services Exchange requis sont démarrés..Il faut donc lancer un Test-ServiceHealth :

servicescas

Dans la cas présent le serveur est à la fois CAS et HUB. Le service à vérifier un particulier est le MSExchangeFDS qui doit être absolument demarré pour pouvoir copier l’OAB du serveur Mailbox. Nous allons d’ailleurs augmenter le niveau de logging de ce service.

Vérifier que le service MSExchangeFDS arrive à copier l’OAB

L’augmentation du niveau de logging permet de s’assurer que rien n’empêche le service MSExchange de copier l’OAB.

fdslog2

Le service à cibler est MSExchangeFDS\FileReplication en mettent un niveau de diagnostique à High.Vous pouvez aussi cibler le service MSExchangeFDS\General.

Pour obtenir le même comportement en ligne de commande :

Set-EventLogLevel -Identity "MSExchangeFDS\FileReplication" -Level High

Set-EventLogLevel -Identity "MSExchangeFDS\General" -Level High

Le résultat :

fdslog

Nous voyons bien que le service MSExchangeFDS est arrivé à copier l’OAB.

Vérifier le partage WEB et les ACL

Une fois copié sur le serveur CAS dans le répertoire [LettredeLecteur]:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\[GUID], le dossier est partagé par le serveur Web IIS. Il faut s’assurer que ce partage est bien présent.

oabiis1

Le nom du partage est "OAB". Il est INUTILE de changer les droits ACL du dossier [LettredeLecteur]:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\[GUID] !! En effet les droits sont positionnés au niveau de l’Active Directory et mis sur le répertoire par le service MSExchangeFDS à chaque recopie. Donc si vous changer les ACL, à la prochaine copie (par défaut toutes les 8 heures) les droits seront redescendus de l’AD. Les Utilisateurs Authentifiés doivent pouvoir télécharger l’OAB.

Vérifions cela en allant dans l’Active Directory :

oabadrights1

Nous avons bien notre groupe Utlisateurs Authentifiés qui à le droit de télécharger l’OAB, ouf ! :)

Il est possible de connaitre la configuration des droits dans l’Active Directory directement depuis une console Shell Exchange. Le script permet de s’assurer que le groupe Utilisateurs Authentifiés possède bien le droit sur l’attribut ‘ms-Exch-Download-OAB" et ‘ListChildren".

adoaball1

Si vous souhaitre modifier les permissions il faut utiliser la commande Add-Adpermission.

Dépannage depuis Outlook 2007

Le dépannage depuis Outlook 2007 est le plus simple : en effet il existe un test des services intégré dans le produit.

Lancer Outook 2007, puis allez dans la barre des tâches. Effectuer un clic droit sur l’icône Outlook tout en appuyant sur la touche "Ctrl". La choisir "Tester la configuration automatique de la messagerie…"

2009-04-15_133549

Renseigner le mot de passe et choisir "tester". L’interêt de ce test est de valider que Outlook 2007 arrive à se connecter au service Autodiscover.

Une fois la connexion au service établie, il est possible de forçer le téléchargement de l’OAB directement depuis Outlook 2007 :

2009-04-15_134205

Voilà ! Vous connaisez les actions à mettre en place pour résoudre 99% des problèmes posés par l’OAB. Cet article ne serait pas complet sans mentionner l’outil d’analyse de l’OAB "OABInteg"  dont vous trouverez le guide d’utilisation sur le site de l’auteur : http://blogs.msdn.com/dgoldman/archive/2005/08/28/oabinteg-and-how-to-use-it-to-troubleshoot-oab-generation-issues.aspx


Publié dans Architecture, Exploitation | 5 Comments »

Comment sauvegarder Exchange 2007 SP1 avec DPM SP1 ?

Publié par Frédéric Laubel le avril 8, 2009


En se faisant la main sur le produit grâce à un Lab Virtuel : http://go.microsoft.com/?linkid=9660244

Le principe du Lab Virtuel est de donner accès depuis un simple navigateur Internet (I6 SP1 minimum) à une infrastructure virtuelle distante. Vous n’avez donc rien à installer sur votre ordinateur. Pas besoin de télécharger le produit non plus…et ceci est accessible même depuis le réseau d’une entreprise (dans ce cas il faut configurer le proxy).

Le Lab vous demandera de procéder à un ensemble de manipulations pour un temps estimé de 90 minutes.

Petit récapitulatif des ressources DPM :

Parmi les apports du SP1 de DPM notons le support d’Hyper-V et la possibilité de sauvegarder une cible SCR !

Publié dans Architecture, Exploitation | Commentaires fermés

CCR ou SCC ?? DAS ou SAN ?

Publié par Frédéric Laubel le mars 21, 2009


Deux excellents documents qui abordent ces questions recurrentes lors du choix d’un design Exchange 2007…de plus écrit par une femme :)

CCR ou SCC :

http://www.3sharp.com/pdf/Continuous%20Cluster%20Replication%20or%20Single%20Copy%20Clustering.pdf

tableauccrvsscc

CCR et DAS :
http://www.3sharp.com/pdf/Continuous%20Cluster%20Replication%20and%20Direct%20Attached%20Storage.pdf

ccrvsdassan1

Publié dans Architecture | Commentaires fermés

Bascule SCR dans le cadre d’un PRA

Publié par Frédéric Laubel le décembre 1, 2008


Cet article à pour objectif de décrire les actions techniques à mettre en oeuvre en vu de basculer sur un site de secours en utilisant la fonctionnalité Exchange 2007 SCR.

En effet j’ai constaté qu’il n’existe pas beaucoup de littérature sur ce sujet…donc je me lance :)

Update du 16/03 : Mise en forme au format HTML.

Update du 09/04 : Le Rollup 7 corrige plusieurs bugs liés au SCR je vous conseille donc vivement de l’installer.

Introduction

L’objectif de ce document est de décrire la méthodologie d’activation d’un serveur SCR dans le cadre d’un PRA. Le serveur de secours (serveur cible SCR) est activé uniquement en cas de sinistre sur le site de production. Les serveurs sont sur deux sites géographiques distincts, mais appartiennent au même site logique Active Directory.

Présentation de l’architecture

L’infrastructure Exchange 2007 est composée de six serveurs répartis entre deux sites géographiques :

  • Sur le site de production quatre serveurs Exchange 2007 :
    • deux serveurs ayant les rôles CAS/HUB en NLB
    • un cluster CCR
  • Sur le site de secours deux serveurs Exchange 2007 :
    • un serveur ayant les rôles CAS/HUB
    • un serveur ayant un nœud passif boite aux lettres

Dans cet article les serveurs sont en Exchange 2007 SP1 Rollup 5. Il est fortement conseillé de passer le Rollup 7 qui corrige plusieurs bugs liés au SCR.

Important : Les serveurs sont installés sur Windows 2008 et le SCR est activé entre deux sites géographiques appartenant au même site Active Directory. En cas de mise en œuvre de cette architecture avec du Windows 2003 certains points techniques sont légèrement différents.

Le schéma suivant illustre l’architecture :

v21

Tableau 1 : Noms des serveurs Exchange

Noms Rôles Sites
TargetSCR Cible SCR Site de PRA
HUBCASSecours1 HUB/CAS de secours Site de PRA
CCRNodeA Noeud CCR Site de production
CCRNodeB Noeud CCR Site de production
MONCMS Cluster Mailbox Server (CMS) Site de production / Site de PRA
HUBCASProd1 HUB/CAS principal Site de production
HUBCASProd2 HUB/CAS principal Site de production

Comme le flux SMTP est réparti entre les serveurs d’un même site Active Directory, il est nécessaire de suivre la procédure que je décris dans cet article :
https://laubel.wordpress.com/2008/09/18/forcer-lutilisation-dun-serveur-hub/

Ceci est indispensable pour éviter que le serveur HUB du site de secours soit utilisé par les serveurs de boites aux lettres du site principal. Vous n’avez pas à effectuer cette opération si les serveurs sont sur deux sites Active Directory logique différents.

Pour indiquer sur le site de production la liste des serveurs HUB à utiliser par le cluster CCR :
Set-MailboxServer -Identity MONCMS -SubmissionServerOverrideList HUBCASProd1, HUBCASProd2

Pour vérifier que ce paramétrage est actif utilisez la commande Get-mailboxServer -identity MONCMS | fl :

submissionserveroverridelistprint1

Et observez la ligne "SubmissionServerOverrideList" qui doit vous donner la listes des serveurs HUB à utiliser par les serveurs Maillbox.

-> Lors de la bascule vers le site de secours il faudra mettre à jour ce paramétrage avec le nom du serveur HUB à utiliser sur le site de secours.

Pour connaitre la configuration de Exchange 2007 SP1 en NLB je vous invite à consulter cet article :
http://www.msexchange.org/articles_tutorials/exchange-server-2007/planning-architecture/load-balancing-exchange-2007-sp1-hub-transport-servers-windows-network-load-balancing-technology-part1.html

Présentation du SCR

Ce chapitre présentant le fonctionnement du SCR est issue du fichier d’aide d’Exchange 2007. Voir https://laubel.wordpress.com/2008/08/17/mise-a-jour-du-helpfile/

La réplication continue de secours (SCR) est une nouvelle fonctionnalité ajoutée au Service Pack (SP1) Exchange Server 2007. Comme son nom l’indique, la SCR est conçue pour les scénarios utilisant ou activant l’utilisation des serveurs de récupération de secours.

La SCR utilise la technologie d’envoi et de relecture des journaux utilisés par la réplication continue locale (LCR) et la réplication continue en cluster (CCR) afin de fournir des options et configuration de déploiement supplémentaires.

SCR permet de séparer la disponibilité élevée (constituée par la disponibilité des données et services) et la résilience de site. Par exemple, la SCR peut être alliée à la CCR pour répliquer localement des groupes de stockage dans un centre de données principal (qui utilise la CCR pour une disponibilité élevée) et à distance dans un centre de données secondaire ou de sauvegarde (qui utilise la SCR pour la résilience de site). Ce centre de données secondaire pourrait contenir un nœud passif dans un cluster de basculement qui héberge les cibles de SCR. Ce genre de cluster s’appelle un cluster de secours parce qu’il ne contient aucun serveur de boîtes aux lettres en cluster, mais qu’il peut être rapidement configuré avec un serveur de boîtes aux lettres en cluster de remplacement dans un scénario de récupération. En cas de défaillance ou de perte du centre de données principal, les cibles de SCR hébergées dans ce cluster de secours peuvent y être rapidement activées.

Le dessin ci-dessus montre un modèle de CCR vers SCR, une source et une cible. Cette architecture est l’objet de la procédure de bascule SCR.

image002

Les ordinateurs de gauche représentent les deux nœuds CCR physiques dans un même centre de données. Les ordinateurs de droite représentent deux cibles SCR dans un autre centre de données. Dans cet exemple, un groupe de stockage unique est répliqué vers une cible SCR à cluster unique (nœud passif). La récupération du groupe de stockage peut être effectuée selon l’une ou l’autre des méthodes suivantes :

  • /RecoverCMS
  • La portabilité de la base de données peut être utilisée pour la récupération de groupes de stockage depuis des sources CCR multiples.

Tout comme la CCR, la SCR nécessite que les chemins de la base de données et des fichiers journaux soient les mêmes dans la source et dans la cible.

Source et cibles SCR

Le point de départ de la SCR s’appelle la source, qui peut être n’importe lequel des groupes de stockage de :

  • serveur de boîtes aux lettres autonome ;
  • serveur de boîtes aux lettres en cluster dans un cluster à copie unique (SCC) ;
  • serveur de boîtes aux lettres en cluster dans un environnement de CCR.

Les groupes de stockage SCR ne peuvent contenir plus d’une base de données. Vous ne pouvez pas activer la SCR pour un groupe de stockage qui contient plus d’une base de données, et vous ne pouvez pas ajouter une seconde base de données ou une base de données subséquente à un groupe de stockage SCR.

Le point de terminaison de la SCR s’appelle la cible, et elle peut être :

  • serveur de boîtes aux lettres autonome non activé pour la LCR pour un groupe de stockage ;
  • nœud passif dans un cluster de basculement sur lequel le rôle de boîtes aux lettres est installé, mais aucun serveur de boîtes aux lettres en cluster n’est installé dans le cluster.

Un ordinateur cible de SCR doit être équipé du rôle de serveur de boîtes aux lettres, même s’il n’héberge pas de boîtes aux lettres de production. Le rôle serveur de boîtes aux lettres est requis parce qu’il inclut le services de réplication Microsoft Exchange et d’autres composants nécessaires à la fonctionnalité de SCR.

Une source peut avoir plusieurs cibles. Par exemple, une source peut avoir une cible dans le même centre de données qu’elle, et une deuxième cible dans un autre centre de données. Le nombre de cibles possibles pour une source est illimité. Cependant, nous vous conseillons de ne pas en utiliser plus de quatre par source. L’impact sur le serveur source doit être vérifié et prévu en conséquence si plus de quatre cibles sont configurées.

La SCR est disponible dans l’édition standard du SP1 Exchange 2007. Si un serveur de boîtes aux lettres dans un environnement SCC ou CCR est utilisé comme source SCR, le SP1 Exchange 2007 Enterprise Edition est nécessaire parce que la mise en cluster de Exchange 2007 nécessite l’Enterprise Edition. Si un cluster de secours est utilisé comme cible SCR, l’Enterprise Edition du SP1 Exchange 2007 est aussi requise.

Besoins pour les cibles SCR

Avant de déployer des cibles SCR, nous vous conseillons de vous familiariser avec les besoins des cibles SCR :

  • Chaque cible peut avoir de multiples serveurs sources. Le système source comme le système cible doivent être équipés de SP1 Exchange 2007. Il peut s’agir de n’importe quel système d’exploitation pris en charge par Exchange 2007 SP1 (par exemple, Windows Server 2008 ou Windows Server 2003). Toutefois, tous les ordinateurs cibles de SCR doivent exécuter le même système d’exploitation que l’ordinateur source de SCR correspondant. L’utilisation de différents systèmes d’exploitation pour une source de SCR et ses cibles (par exemple, lorsque la source de SCR est Windows Server 2003 et la cible de SCR Windows Server 2008, ou vice versa) n’est pas prise en charge.
  • L’ordinateur cible de la SCR doit être équipé du rôle serveur de boîtes aux lettres du SP1 Exchange 2007.
  • Pour utiliser la SCR, vous devez configurer vos chemins d’installation du serveur Exchange plus minutieusement si vous projetez d’utiliser un cluster de secours et la fonctionnalité de récupération du serveur de boîtes aux lettres en cluster (Setup /RecoverCMS) dans le processus d’activation de la cible SCR. Pour utiliser le processus de récupération du serveur, le chemin d’installation du serveur Exchange doit être le même dans l’ordinateur source de la SCR et dans celui cible. Si le serveur Exchange est installé dans %ProgramFiles%\Microsoft\Exchange Server sur l’ordinateur source de la SCR, il doit aussi être installé dans %ProgramFiles%\Microsoft\Exchange Server sur tous les ordinateurs qui seront les cibles SCR du serveur source. Si ces chemins d’installation ne correspondent pas, Setup /RecoverCMS échoue parce que le chemin d’installation dans le Registre ne correspond pas à la valeur de l’attribut msExchInstallPath de l’objet serveur de boîtes aux lettres dans le service d’annuaire Active Directory.
  • Vous devez également planifier les chemins d’accès aux groupes de stockage et base de données avec soin lorsque vous utilisez la SCR car le chemin d’accès aux groupes de stockage et base de données utilisé par une source de SCR sera utilisé pour la copie des groupes de stockage et base de données sur toutes les cibles de SCR correspondant à la source.
  • Les ordinateurs sources et cible de SCR doivent figurer dans le même domaine Active Directory mais peuvent se trouver dans le même site Active Directory ou dans des sites différents.
  • Chaque ordinateur cible prend en charge jusqu’à 50 cibles de SCR (50 groupes de stockage répliqués) lorsque l’édition Enterprise d’Exchange 2007 est utilisée, et jusqu’à 5 cibles de SCR lorsque l’édition Standard d’Exchange 2007 est utilisée.

Restrictions sur les ordinateurs cibles de la SCR

Lorsqu’un nœud passif ou un serveur de boîtes aux lettres autonome est configuré comme cible de SCR, les fonctionnalités suivantes sont bloquées :

  • Il n’est pas possible que la LCR soit activée pour un quelconque groupe de stockage sur un serveur de boîtes aux lettres autonome désigné en tant que cible SCR. Le service de réplication Microsoft Exchange n’a pas été conçu ni modifié pour gérer la LCR et la réplication à partir d’une autre source.
  • Un nœud passif désigné en tant que cible SCR doit faire partie d’un cluster avec basculement qui n’a aucun serveur de boîtes aux lettres en cluster.

Installation du serveur TargetSCR

Installation des pré-requis d’Exchange en Cluster

L’installation des pré-requis Exchange 2007 est effectué à l’aide de fichiers .xml créés par l’équipe produit Exchange. Ces fichiers sont valables uniquement pour Windows 2008.

Ces fichiers sont disponibles en libre téléchargement : http://msexchangeteam.com/files/12/attachments/entry448276.aspx

Tout d’abord, il faut installer les pré-requis Exchange 2007 :
servermanagercmd.exe -ip Exchange-Base.xml

requirements1

Puis il faut procéder à la même opération pour  les pré-requis de la mise en cluster d’Exchange Server 2007:
servermanagercmd.exe -ip Exchange-clusMBX.xml

clusmbx1


Installation du nœud passif Exchange

Avant installation du serveur Exchange il est nécessaire de créer un cluster MSCS. Le cluster sera formé d’un seul nœud.

image004

Le chemin d’accès aux données et logs Exchange doit être équivalent entre le serveur TargetSCR et les nœuds sources CCRNodeA et CCRNodeB.

image005

Important : Installer Exchange en prenant soin d’indiquer un chemin d’installation identique au chemin d’installation existant sur les serveurs sources.

Installer Exchange en nœud passif (il n’y aura pas de création de CMS).

image007

Le compte machine de la cible SCR (TargetSCR) doit avoir un accès total au compte machine du CMS.
Cela se fait dans Active Directory en allant sur les propriétés du compte du CMS (MONCMS) et en ajoutant le compte machine TargetSCR en accès Full. Ceci n’est valable que pour Windows 2008.

Activation et surveillance du SCR

Activation du SCR

L’activation du SCR se fait par la commande Enable-StorageGroupCopy.

Par exemple pour activer la réplication SCR sur le groupe de stockage SG-1 vers le serveur TargetSCR :

Enable-StorageGroupCopy MONCMS\SG-1 -StandbyMachine TargetSCR

Il est possible d’activer le SCR sur l’ensemble des groups de stockage avec une seule commande :

Get-StorageGroup -Server MONCMS | Enable-StorageGroupCopy -StandbyMachine TargetSCR

Surveillance du SCR

La surveillance de la réplication SCR se fait par la commande Get-StorageGroupCopyStatus :

Get-StorageGroupCopyStatus MONCMS\SG-1 -StandbyMachine TARGETSCR

Un état Healthy indique que la réplication fonctionne correctement.

L’ajout de l’option fl permet d’obtenir plus de détails :

Get-StorageGroupCopyStatus MONCMS\SG-1 -StandbyMachine TARGETSCR | fl

image009

Le paramétrage des options –ReplayLagTime et –TruncationLagTime est laissé par défaut.

Arrêt du site principal et activation du site de secours

Préparation des groupes de stockage

A la suite d’une défaillance du site principal il faut activer les copies de secours SCR sur le serveur TARGETSCR.

Il est nécessaire de préparer les groupes de stockage avec la commande Restore-StorageGroupCopy. Cette commande permet notamment de mettre les bases dans un état "mountable".

Par exemple pour préparer le groupe de stockage SG-1 :

Restore-StorageGroupCopy -Identity MONCMS\SG-1 | -StandbyMachine TARGETSCR -force

Il est possible de préparer l’ensemble des groupes de stockage à l’aide du script GetscrSources.ps1 disponible dans le répertoire d’installation d’Exchange 2007 SP1.

L’option -Force est obligatoire dans le cas où les serveurs sources ne sont pas en ligne, ce qui est le cas ici.

Suppression de l’enregistrement CMS dans le DNS

Supprimer l’enregistrement hôte du CMS dans le serveur DNS.

Désactivation du SCR

La commande Restore-StorageGroupCopy doit désactiver la réplication SCR. Si la réplication est toujours active il est nécessaire de la désactiver explicitement avec la commande Disable-StorageGroupCopy.

Disable-StorageGroupCopy -Identity MONCMS\SG-1 -StandbyMachine TARGETSCR -Confirm:$False


Restauration du CMS

La restauration du CMS se fait à partir du média d’installation d’Exchange 2007 en spécifiant la nouvelle adresse IP utilisée.

Setup.com /RecoverCMS /CMSName:MONCMS /CMSIPAddress:<IPAddress>

Où <IPAddress> est la nouvelle adresse IP à utiliser.
Exemple :

image010

Il est possible que la commande retourne une erreur lors de sa première exécution. Dans ce cas vérifier que les ressources cluster soient online, si besoin mettez les online manuellement  puis relancer la commande….

Mise à jour du paramètre -SubmissionServerOverrideList

Nous spécifions le serveur HUB  à utiliser sur le site de secours par le CMS.

Set-MailboxServer -Identity MONCMS -SubmissionServerOverrideList HUBCASSecours1


Vérification de l’intégrité des bases Exchange

Avant le montage des bases Exchange il est nécessaire de vérifier leur intégrité et les réparer le cas échéant.

La vérification des bases se fait avec l’utilitaire ESEUTIL.

Par exemple pour la base DB-1 dont le fichier .edb se trouve dans le répertoire M:\ExchangeDB\DB-1 :

Eseutil /MH M:\ExchangeDB\DB-1\db-1.edb

Si en retour la ligne State à pour valeur Dirty Shutdown il faut réparer la base avant de la monter (car il manque les logs permettant de remonter la base).

image011

Noter le numéro préfixe dans le répertoire logs de la base de données. Dans cet exemple les logs se terminent par 02.

Lancer la réparation avec ESEUTIL en spécifiant notamment le numéro de préfixe des fichiers de log.

Par exemple pour la base DB-1 dont le répertoire de logs se trouve dans le répertoire L:\SG-1 :

Eseutil /r E02 /s M:\ExchangeDB\DB-1 /l L:\SG-1 /a

La réparation se lance :

image0121

Vérifier de nouveau l’état de la base avec la commande Eseutil /MH M:\ExchangeDB\DB-1\db-1.edb

image014

Cette fois la ligne State renvoi la valeur Clean Shutdown permettant un montage sans risque de la base.

Montage des bases Exchange

Monter les bases de données Exchange avec la commande Mount-Database ou graphiquement par la console Exchange.

A cette étape à partir du moment ou les serveurs DNS et les postes clients possèdent la nouvelle adresse IP de MONCMS les clients doivent pouvoir se connecter normalement à leurs boites aux lettres par le client lourd Outlook ou par le client léger OWA.

En cas d’utilisation prolongé du site de secours ou de création de boites aux lettres il sera nécessaire de reconfigurer la distribution du carnet d’adresse en mode hors connexion (OAB) pour prendre en compte les nouveaux serveurs CAS.

Pour savoir comment modifier  la configuration de l’OAB :
http://technet.microsoft.com/en-us/library/bb124270.aspx

Préparation du site principal avant redémarrage

Dans ce document nous partons du principe que le nœud actif du cluster CCR est le serveur CCRNodeA.

Pour vérifier qui est le nœud actif utiliser la commande Get-MailboxServerStatus.

Il est nécessaire de procéder à remise en route maitrisé du site principal pour éviter tous conflits entre les services du site de secours (qui est maintenant en production) et les services du site principal (qui est en cours de redémarrage).

Procéder au redémarrage des contrôleurs de domaine du site principal, puis des serveurs Exchange HUB /CAS et enfin des nœuds CCR.

Supprimer le CMS des nœuds CCRNodeA et CCRNodeB :

Setup.com /ClearLocalCMS /CMSName :MONCMS

image015


Vérifier que les ressources du CMS n’apparaissent plus dans le gestionnaire de cluster.
Après avoir exécuté cette commande sur un ordinateur Windows Server 2008 le compte machine est désactivé. Il est nécessaire de le réactiver : Start / All Programs, / Administrative Tools, /  Active Directory Users and Computers. Rechercher le compte MONCMS et clic droit sur le compte / Enable Account.

Configuration du site principal comme cible SCR

L’ancien site principal doit devenir la cible SCR afin de s’assurer du bon retour en arrière sans perte des données. La procédure est la même que celle utilisée pour activer le SCR sur le site de secours.

Enable-StorageGroupCopy EXCMS1\SG-1 -StandbyMachine CCRNodeA

Pour rappel il est possible d’activer le SCR sur l’ensemble des groups de stockage avec une seule commande :

Get-StorageGroup -Server MONCMS\SG-1 | Enable-StorageGroupCopy -StandbyMachine CCRNodeA

Si les bases de données initiales ne sont plus utilisables il faut renvoyer la totalité des bases (reseed) du site de secours vers le site principal.

Cela se fait par la commande Update-StorageGroupCopy.

Redémarrage du site principal

Une fois que le site principal est prêt à revenir le site de production, nous pouvons commencer la procédure de bascule.

Démontage des bases Exchange du serveur TARGETSCR

Il faut commencer par démonter les bases Exchange sur le serveur TARGETSCR. Cela peut se faire en mode graphique depuis la console Exchange ou avec la commande Dismount-Database.


Préparation des bases Exchange sur CCRNODEA

La commande est identique à celle utilisé lors de la bascule initiale :

Restore-StorageGroupCopy -Identity MONCMS\SG-1 | -StandbyMachine CCRNODEA


Arrêt du service Cluster sur TARGETSCR

Arrêter le service cluster sur le serveur TARGETSCR soit par l’interface graphique, soit par la commande Stop-ClusteredMailboxServer.


Suppression de l’enregistrement DNS de MONCMS

Supprimer l’enregistrement DNS du CMS MONCMS qui contient l’adresse IP attribuée durant son utilisation sur le site de secours.

Désactivation du SCR

La commande Restore-StorageGroupCopy doit désactiver la réplication SCR. Si la réplication est toujours active il est nécessaire de la désactiver explicitement avec la commande Disable-StorageGroupCopy. Disable-StorageGroupCopy -Identity MONCMS\SG-1 -StandbyMachine CCRNODEA -Confirm:$False


Restauration du CMS

A partir du serveur CCRNODEA exécuter : Setup.com /RecoverCMS /CMSName:MONCMS /CMSIPAddress:<IPAddress> Où <IPAddress> est l’adresse IP utilisée avant la bascule pour le CMS.

Mise à jour du paramètre -SubmissionServerOverrideList

Nous remettons à jour la liste des serveurs HUB à utiliser sur le site principal.

Set-MailboxServer -Identity MONCMS -SubmissionServerOverrideList CCRNodeA, CCRNodeB


Montage des bases

Monter les bases Exchange soit par l’interface graphique soit par la commande Mount-Database.


Activation du CCR

Il est nécessaire de réactiver la réplication CCR, cela se fait soit par l’interface graphique soit par la commande Resume-StorageGroupCopy.


Vérification de la réplication CCR

Pour vérifier la réplication CCR il est possible d’utiliser la commande Test-ReplicationHealth. Celle-ci ne doit pas renvoyer d’erreur. 

Reconfiguration du site de secours


Suppression du CMS

Depuis le serveur TARGETSCR supprimer le CMS :

Setup.com /ClearLocalCMS /CMSName:MONCMS

Après avoir exécuté cette commande sur un ordinateur Windows Server 2008 le compte machine est désactivé. Il est nécessaire de le réactiver : Start / All Programs, / Administrative Tools, /  Active Directory Users and Computers. Rechercher le compte MONCMS et clic droit sur le compte / Enable Account.

Vérification des services Exchange

Pour s’assurer du bon démarrage du service Exchange « MSExchangeRepl » utiliser la commande Test-ServiceHealth.


Test-ServiceHealth

Si ce service n’est pas démarré, il est nécessaire de le redémarrer manuellement.

Le service « MSExchangeRepl » doit être démarré avant activation du SCR sur le serveur TARGETSCR :

image017

Activation du SCR vers TARGETSCR

L’activation du SCR se fait par la commande Enable-StorageGroupCopy.

Par exemple pour activer la réplication SCR sur le groupe de stockage SG-1 vers le serveur TARGETSCR :

Enable-StorageGroupCopy MONCMS\SG-1 -StandbyMachine TARGETSCR

Il est possible d’activer le SCR sur l’ensemble des groups de stockage avec une seule commande :

Get-StorageGroup -Server MONCMS\SG-1 | Enable-StorageGroupCopy -StandbyMachine TARGETSCR


Validation du SCR

La surveillance de la réplication SCR se fait par la commande Get-StorageGroupCopyStatus :

Get-StorageGroupCopyStatus MONCMS\SG-1 -StandbyMachine TARGETSCR

Un état Healthy indique que la réplication fonctionne correctement.

L’ajout de l’option fl permet d’obtenir plus de détails.

Get-StorageGroupCopyStatus MONCMS\SG-1 -StandbyMachine TARGETSCR | fl

image016

Fin du document

N’hésitez pas à me faire part de vos remarques et suggestions.

Happy PRA :)

Publié dans Architecture, Scripts, Windows 2008 | 1 Comment »

Release v16 du calculator Exchange !

Publié par Frédéric Laubel le septembre 26, 2008


A chaque mois sa nouvelle release :o)

Version 16.0

Bug Fixes / Enhancements

  • The changes introduced in v15.6 in the Storage Design worksheet introduced a logic error where the recommended RAID Configuration / Server would recommend a null configuration when you selected "–" for the database disk type in Configuration 3.  This has been corrected to ensure that only enabled disk configurations are considered when making a recommendation.
  • Validation logic was added to the custom database size input factor to remind you that you need to enter in a value greater than 0.
  • Fixed various input factor comments.
  • Fixed RAID-0 calculations for the database and log configuration options 2 and 3.  In previous releases, the RAID-0 values for these configurations were utilizing the RAID-1/0 data points.
  • Updated the backup and restore rate input factors to indicate that these only apply for steaming backup calculations.  Also added validation logic to disable the input options when VSS backup methodologies are chosen.
  • Fixed the streaming backup rate calculations to include all transaction logs generated in a day (user generation + move mailbox).  Previous releases only considered user log generation.
  • Updated the text and note for the "Additional I/O Requirement" field to indicate that the input value is per mailbox server.
  • Added streaming restore calculations for both full database restore and incremental / differential backup restore to the Backup requirements worksheet.
  • Added the following note to the Storage Design worksheet – Important: This tool should only be used for storage modeling purposes.  Please consult with the storage vendor regarding storage design and follow recommended storage design testing processes.  The example configuration provided within this calculator is just that, an example, and as such, each input option needs to be evaluated as to how it will affect your design.

Téléchargement :
http://msexchangeteam.com/files/12/attachments/entry438481.aspx

Publié dans Architecture, Documentation | Commentaires fermés

Forcer l’utilisation d’un serveur HUB

Publié par Frédéric Laubel le septembre 18, 2008


Par défaut la charge entre les serveurs MBX et les serveurs HUB est répartie automatiquement entre les serveurs HUB d’un même site AD.

Il est possible de modifier ce comportement pour forçer les serveurs MBX à utiliser des serveurs HUB spécifiques. Cela peut être utile, par exemple en cas de site AD répartie sur différents sites géographiques (Stretched Active Directory site).

Pour cela il faut jouer sur un paramétre de la commande Set-MailboxServer.

Ex:
Set-MailboxServer -Identity <ServeurMBX> -SubmissionServerOverrideList <ServeurHUB1>,<ServeurHUB2>

Référence :
http://technet.microsoft.com/en-us/library/aa998651(EXCHG.80).aspx

Publié dans Architecture, Exploitation, Scripts | 1 Comment »

Livre Blanc sur l’Autodiscover

Publié par Frédéric Laubel le août 17, 2008


Pour mieux comprendre l’importance de ce service et comment le configurer (notamment sur Internet) :
http://technet.microsoft.com/en-us/library/bb332063.aspx

Publié dans Architecture, Documentation | Commentaires fermés

 
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 25 followers