Posté par Frédéric Laubel le novembre 5, 2009
L’équipe Exchange vient d’annoncer qu’il va être très bientôt possible d’installer Exchange 2007 sur Windows Server 2008 R2 !
En effet jusqu’à présent la seule version d’Exchange qui peut s’installer sur Windows Server 2008 R2 est Exchange 2010. Vivement la sortie du patch !
J’en connais un qui va devoir modifier sa matrice de compatibilité 
Publié dans Architecture, Exploitation | 3 Commentaires »
Posté par Frédéric Laubel le août 26, 2009
Exchange 2007 SP2 est disponible !
Ce Service Pack 2 est une mise à jour majeur. En effet non seulement le SP2 contient l’ensemble des correctifs (Rollup) sortis depuis Exchange 2007 SP1, mais il apporte aussi des nouveautés, citons entre autres :
Le Service Pack 2 pour Exchange 2007 est indispensable pour pouvoir migrer les boites aux lettres d’un serveur Exchange 2007 vers Exchange 2010 .
Un ajout réclamé depuis longtemps, il est enfn possible de sauvegarder Exchange 2007 avec la logiciel de backup intégré dans Windows 2008. Il existe cependant quelques limitations.
Exchange 2007 SP2 intègre l’équivalent l’outil Diagnostic Logging Tool directement dans la console, à l’image de Exchange 2010.
Il est possible d’auditer très finement les modifications apportées à l’environnement de messagerie, voir l’excellent White Paper à ce sujet.
Cependant :
Publié dans Exploitation, Rollups et Bugs | Laisser un commentaire »
Posté par Frédéric Laubel le juin 18, 2009
Lors de l’installation d’Exchange 2007 celui-ci rajoute des compteurs dans l’outil de collecte de performance Windows (perfmon.msc).
Ces compteurs sont utiles pour superviser des rôles ou des points précis sur Exchange, notamment la réplication CCR ou SCR (Voir l’article Technet sur l’utilisation de perfmon pour superviser Exchange).
Cependant pour faire du troubleshooting poussé ces compteurs ne sont pas suffisant. Heureusement il est possible d’alimenter perfmon avec de nouveaux compteurs spécifiques à Exchange 2007 via des fichiers .xml.
Ces fichiers .xml sont spécifiques à chaque rôles Exchange 2007 :
Prenons l’exemple d’un serveur mailbox sur lequel je souhaite diagnostiquer un problème de lenteur.
Important : Cette procédure n’est valable que pour une configuration sur Windows 2008 en anglais. (Pour une version française sur W2K8 il est nécessaire d’utiliser un outil supplémentaire, et pour Windows 2003 il faut utiliser d’autres fichiers sources. Ça marche bien dans les deux cas mais les procédures sont sensiblement différentes.)
Tout d’abord je récupère le fichier .xml spécifique à mon serveur, ici il s’agit du rôle mailbox donc du fichier Exchange_2007_Perfwiz-MBX.xml.
Dans Server Manager je me positionne sur Reliability and Performance / Data Collector Sets / User Defined / et je crée une nouvelle collecte :
Je donne un nom à ma collecte et je choisi la création depuis un modèle :
Je sélectionne depuis “Browse” le fichier Exchange_2007_Perfwiz-MBX.xml
Sélection du répertoire cible :
Je termine en décidant de ne pas démarrer la collecte immédiatement.
En retournant sur perfmon, la collecte personnalisée apparait bien.
En allant dans les propriétés de la collecte, je peux voir l’ensemble des compteurs de performance inclus dans la collecte. Personnellement je préfère changer le format du fichier en .CSV (en effet j’ai constaté un bug avec le format .BLG en cas d’analyse avec PAL)
Évidemment libre à vous de supprimer ou ajouter des compteurs ou de conserver le format .BLG.
La collecte peut démarrer.
La collecte est bien en statut Running.
Laissez tourner la collecte le temps qui vous semble pertinent en fonction de vos problèmes, généralement une journée.
Une fois la collecte terminée il est le temps de passer à l’analyse du fichier.
Le programme PAL, pour Performance Analysis of Logs, est un outil graphique gratuit dédié à l’analyse des logs de performances, que ce soit pour Exchange, mais aussi SQL, Active Directory,IIS, etc…Il est développé par des gens de Microsoft (surtout par Mike Lagase).
Le gros intérêt de PAL est sa capacité à analyser les données brutes des compteurs de performance (depuis un fichier .csv ou .blg), pour les comparer aux best practices Microsoft et en faire ressortir les dérives éventuelles (avec des codes couleurs, vert, jaune ou rouge). Bref PAL est votre meilleur ami dès qu’il s’agit de troubleshooter des problèmes de performances en environnement Microsoft…
Première étape il s’agit de récupérer la dernière version de PAL et de l’installer. Aucunes difficultés particulières sur ce point, évidement PAL doit s’installer sur une station de travail et non pas directement sur le serveur à analyser.
Une fois la collecte terminée j’importe le fichier dans PAL (onglet Counter Log).
La seule subtilité de l’outil consiste à ne pas oublier de spécifier dans l’onglet Threshold File le type d’analyse. Ici je précise que le fichier provient d’un serveur Exchange 2007 ayant uniquement le rôle Mailbox :
Ensuite j’exécute l’analyse, attention ça peut prendre pas mal de temps en fonction de la durée de la collecte !
Le résultat est un rapport au format HTML (plusieurs centaines de pages !) me permettant de voir tout de suite les points posant problème en rouge.
Contenu du sommaire :
Extrait :
Avouez que c’est quand même beaucoup plus rapide, pratique, pertinent, sérieux et sexy qu’une analyse à la mano !!!
Et coup de chapeau à Mike Lagase et John Rodriguez (Monsieur Performance sur Exchange)…
Publié dans Exploitation | 8 Commentaires »
Posté par Frédéric Laubel le juin 1, 2009
Comme je l’ai déjà indiqué à l’occasion du Rollup6 (voir dans la catégorie Rollup et Bugs) pour connaitre précisément la version d’un serveur Exchange 2007 il est nécessaire d’aller voir dans le registre. En effet les outils intégrés dans Exchange (get-ExchangeServer | fl ) ne permet pas de récupérer la version du Rollup !
Pour éviter ce travail, Jeff Guillet, MVP Exchange, à eu la bonne idée d’automatiser ça grâce à un ch’tit script 
Illustration sur ma maquette :
Le script est disponible ici.
Publié dans Exploitation, Rollups et Bugs, Scripts | Laisser un commentaire »
Posté par Frédéric Laubel le avril 15, 2009
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.
Le principe de fonctionnement de l’OAB n’a que peut évolué jusqu’à 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.
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.
Commençons par comprendre l’architecture logique pour ensuite allez plus loin dans le fonctionnement.
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.
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).
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 :
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 :
Version française :
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 :
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 :
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 :
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 :
Version US :
Retournons dans les outils d’analyse pour observer le comportement du service MSExchangeFDS :
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 :
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] :
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.
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.
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 :
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 :
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 :
Notez l’adresse du service Autodiscover qui est une URL en HTTPS qui pointe sur le serveur CAS -> https://[NomFQDNduServeurCAS/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>
<EwsUrl>https://w2k3ori.xchangeall.local/EWS/Exchange.asmx</EwsUrl>
<OOFUrl>https://w2k3ori.xchangeall.local/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://w2k3ori.xchangeall.local/UnifiedMessaging/Service.asmx</UMUrl>
<OABUrl>http://w2k3ori.xchangeall.local/OAB/176554e4-8aeb-4a1b-909b-b15525c237e7/</OABUrl>
</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.
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.
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.
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
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.
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 :
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.
Dans le cas présent tout est bon : il n'y pas d'événements en erreurs ou en avertissement.
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 :
Les autorisations fichiers (ACL) sont :
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.
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 :
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.
L’augmentation du niveau de logging permet de s’assurer que rien n’empêche le service MSExchange de copier l’OAB.
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 :
Nous voyons bien que le service MSExchangeFDS est arrivé à copier l’OAB.
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.
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 :
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”.
Si vous souhaitre modifier les permissions il faut utiliser la commande Add-Adpermission.
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…”
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 :
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 | 3 Commentaires »
Posté 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 | Laisser un commentaire »
Posté par Frédéric Laubel le mars 31, 2009
Dans cet article je vais traiter d’un problème vieux comme Exchange 5.5 …il s’agit de la gestion des logs et plus précisément du problème d’espace disque qu’ils peuvent poser en cas de dysfonctionnement de la sauvegarde.
Si la sauvegarde se déroule correctement, les logs sont supprimés après chaque sauvegarde complète ou incrémentielle. Les logs ne sont pas supprimés après une copie ou une sauvegarde différentielle.
Dans le cas où la sauvegarde ne se déroule pas correctement, les logs ne sont pas supprimés et ils peuvent prendre toute la place au point de saturer le disque. Les bases sont alors démontées et il n’y a plus de messagerie… se pose la question des logs : que faire ? supprimer tous les logs ? Seulement quelques logs ? les déplacer ?
Tout d’abord petite explication sur le fonctionnement des logs dans Exchange.
Les logs sont là pour enregistrer dans la base Exchange toutes les modifications (transaction) : envoi d’un email par exemple. Tous les fichiers de logs ont la même taille : 5Mo pour Exchange 2000/2003 et 1Mo depuis Exchange 2007. Dans le cas d’un envoi d’un email l’information est stockée dans un fichier de log (un fichier texte) avant d’être enregistrée dans la base Exchange (base de type ESE). Or si les services Exchange s’arrêtent de manière inattendu (par manque d’espace disque par exemple) Exchange n’a pas eu le temps d’enregistrer tous les logs dans ses bases…Il n’est donc pas question de supprimer tous les logs sans discernement !! Il faut différencier précisément les logs qui peuvent être supprimés pour gagner de l’espace disque, des logs qui sont indispensables à la reprise des bases (le montage des bases).
Nous allons voir comment récupérer cette information cruciale.
Je vais prendre un cas concret : Une infrastructure où les services Exchange 2007 SP1 ne fonctionne plus. L’administrateur constate que les disques sont remplis à 100% à cause des logs. On peut penser que le serveur à crashé lamentablement…donc les bases doivent être en état “dirty shutdown”…Comment procéder ?
Et bien c’est très simple et très rapide : il faut lancer ESEUTIL avec les options permettant de récupérer les informations pertinentes, à savoir eseutil /MH :
Pour mémoire l’utilitaire ESEUTIL se trouve dans le répertoire \Bin d’Exchange.
La commande renvoi des informations très utiles. La ligne qui nous intéresse ici est celle qui se nomme “Log Required” :
Il y a deux possibilités, soit la base est dans un état inconsistant (il y a de forte chance), soit la base est dans un état consistant (vous êtes chanceux !).
La ligne Log Required renvoi l’information suivante : 368-377 (0×170-0×179)
Kesako ?? et bien c’est la réponse à notre problème !
Un état inconsistant (dirty shutdown) signifie que certains logs n’ont pas été enregistrés dans la base. Si vous supprimez tous les logs, y compris les logs qui ne sont pas encore enregistrés, Exchange ne pourra pas redémarrer (remonter les bases). Il vous faudra passer par une réparation, donc une perte de données… à éviter.
La ligne Log Required (que l’on pourrait traduire par logs en attente) indique précisément quels sont les logs qui ne sont pas enregistrés. L’information est donnée sous forme décimal et hexadécimal (uniquement depuis Exchange 2007 SP1). Ici le serveur Exchange est en attente des logs 368 à 377, ou formulé de manière hexadécimal des logs 0×170 à 0×179.
Dans les deux cas on arrive bien au même nombre de logs (neuf), ouf
Après avoir récupérer cette information il faut aller dans le répertoire des logs :
Nous retrouvons bien nos neuf logs qui ne sont pas encore enregistrés en base. Maintenant nous pouvons déplacer en toute sécurité tous les autres logs, à l’exception de ces neuf fichiers, du log courant (Enn.log) et du checkpoint (.chk). Simple
Et concernant l’état des bases me direz vous ? Et bien lors du remontage le processus de restauration va automatiquement se lancer pour enregistrer les logs manquant. Le processus est transparent. Encore une fois cela fonctionne uniquement grâce à la présence des logs indispensables au montage ! Si votre base est dans un étant inconsistant et que les logs requis sont absent il faudra réparer les bases (avec ESEUTIL ou ISINTEG).
Si je reprend mon serveur Exchange et que je monte les bases, tout ce déroule correctement. Si je relance ESEUTL /MH je constate que la base est bien en état consistant ! Vous voyez que la ligne Log Required est à zéro, donc tous mes logs sont bien enregistrés en base
En allant dans le journal système on constate des événements de source ESE et d’ID 301 :
On retrouve nos logs 0×170 à 0×179 !
Dans ce cas, tous les logs sont enregistrés en base, vous pouvez déplacer (au pire supprimer) tous les logs, toujours à l’exception du log en cours (Enn.log) et du fichier de chekpoint (Enn.chk).
Voilà j’espère avoir était clair. Et surveillez le bon déroulement de vos sauvegardes !
Publié dans Exploitation | Laisser un commentaire »
Posté par Frédéric Laubel le janvier 12, 2009
Question récurrente : Comment empêcher certains utilisateurs d’envoyer des emails vers Internet ou d’en recevoir d’Internet ?
Avec Exchange 2007 cela est très simple.
Pour cet article j’ai nommé mon groupe “Pas Internet”.
Valider et voilà ! les membres du groupe “Pas Internet” ne peuvent plus envoyer des messages vers Internet.
Publié dans Exploitation | 1 commentaire »
Posté par Frédéric Laubel le décembre 21, 2008
Avez vous déjà essayer de supprimer le dernier dossier public d’un Exchange 2007 ? Essayez sur votre maquette c’est pas gagné…
La solution passe par deux scripts :
Les scripts suppriment tout le contenu des dossiers utilisateurs (réplicas), puis tout le contenu des dossiers systèmes. Remplacer les barres rouges par le nom de votre serveur et le tour est joué
Il ne vous reste plus qu’à faire un copier/coller :
Get-PublicFolder -Server <NOM_DU_SERVEUR> “\” -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server <NOM_DU_SERVEUR> -Recurse -ErrorAction:SilentlyContinue
Get-PublicFolder -Server <NOM_DU_SERVEUR> “\Non_Ipm_Subtree” -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server <NOM_DU_SERVEUR> -Recurse -ErrorAction:SilentlyContinue
Encore une fois ceci ne s’applique qu’au dernier dossier public de votre organisation Exchange 2007.
Si malgré tout vous n’arrivez pas à le supprimer, passez par ADSIEDIT pour le supprimer directement dans l’Active Directory. Dans ce cas allez dans la partition de Configuration / Services / Microsoft Exchange / le nom de votre Organisation Exchange / Administrative Groups / Exchange Administrative Group (FYDIBOHF23SPDLT)/ Servers / Le nom du serveur / InformationStore / Le nom du groupe de stockage / Le nom de la base de dossier public à supprimer.
Publié dans Exploitation, Scripts | Laisser un commentaire »
Posté par Frédéric Laubel le décembre 21, 2008
Dans certains conditions il est parfois impossible d’installer Exchange 2007 sur Windows 2008. Le setup plante dès la préparation du schéma (setup.com /ps) et des events 1000 venant de la source Application Error sont enregistrés dans le journal d’Application.
Nous voyons que le setup crash en faisant un fault du kernel32.dll.
Après investigation il apparait que cela vient de l’UAC qui empêche toutes modifications dans le dossier C:\windows pour tous les comptes sauf pour le compte Administrateur local du serveur et pour le compte initial Administrateur du Domaine. Par exemple le compte “toto” bien que membre du groupe Administrateurs du Domaine et membre du groupe Administrateur local du serveur Excahnge se trouve bloqué en écriture sur C:\Windows ! Ce comportement n’est pas systèmatique.
La solution passe donc par la désactivation de l’UAC pour le setup d’Exchange 2007.
Allez dans le panneau de configuration, puis dans les comptes utilisateurs :
Désactiver l’UAC :
Il est nécessaire de redémarrer le serveur pour que le changement prenne effet. L’installation d’Exchange 2007 (ou la préparation du schéma) se déroule ensuite correctement.
Publié dans Exploitation, Rollups et Bugs, Windows 2008 | Laisser un commentaire »
