Mise à jour du schéma des bases des données Exchange 2013

Je vous fais un petit résumé sur ce post Exchange 2013 database schema updates du blog EHLO concernant la mise à jour des bases.

Je trouve ce post intéressant dans le sens où la cmdlet Update-DatabaseSchema m’avait effectivement interpellé.

Mais d’abord, pourquoi faire une mise à jour de schéma de base de données, et qu’est-ce que cela implique?
La mise à jour d’un serveur Mailbox Exchange peut parfois induire des modifications dans la structure des bases de données Exchange, que ce soit pour des améliorations de performances, des correctifs (heureusement c’est un scénario relativement rare) ou pour apporter de nouvelles fonctionnalités. Il est cependant inconcevable aujourd’hui de perdre les mécanismes de haute disponibilité lors d’une phase de mise à jour tel que cela pouvait être le cas dans les versions précédentes, où dès lors qu’une base de données était mise à jour dans une DAG, les nœuds non patchés ne pouvaient plus monter cette base. Cela impliquait un chemin de migration long et compliqué, avec un risque opérationnel parfois critique.

La réponse apportée par l’équipe Exchange est de planifier cette mise à jour de schéma une fois tous les membres du DAG mis à jour. Concrètement, les bases de données disposent de nouveaux attributs, certains sont liés à la base de données physiquement sur le serveur :
– CurrentSchemaVersion
– RequestedSchemaVersion

D’autres aux bases de données en DAG :
– MinimumSupportedDatabaseSchemaVersion
– MaximumSupportedDatabaseSchemaVersion
– RequestedDatabaseSchemaVersion

Concrètement depuis le CU3, lorsque vous mettez à jour un serveur membre d’un DAG, celui-ci lance automatiquement cette cmdlet pour chaque base de données. L’attribut MaximumSupportedDatabaseSchemaVersion n’est mis à jour que lorsque tous les membres du DAG ont été mis à jour, si c’est le cas alors l’attribut RequestedDatabaseSchemaVersion est provisionné pour indiquer qu’une mise à jour de schéma est demandée. Celle-ci ne sera effective qu’après avoir démontée et remontée la base!

Pour rappel, le schéma d’une base de données Exchange 2013 est très différent de celui des versions passées : il existe une table globale des boites aux lettres, puis chaque boite aux lettres disposent de ses propres tables. Lors de la mise à jour du schéma, seul la table globale est mise à jour dans un premier temps. Le schéma des tables des boites aux lettres individuelles n’est mis à jour que lors du prochain accès à celle-ci. On peut obtenir le schéma d’une BAL via la cmdlet Get-MailboxStatistics ‘utilisateur’ | Select CurrentSchemaVersion

Cela semble impliquer qu’il ne sera pas possible d’intégrer dans un DAG un serveur Exchange qui ne disposent pas du CU nécessaire pour supporter la version actuelle des bases de données.
Mise à jour 16/01/2014 : on peut ajouter dans un DAG des serveurs disposant de CU inférieur à celui nécessaire pour le schéma de base de données, mais il sera impossible d’activer la base sur le serveur.

Ces changements semblent importants, mais il faut se rappeler qu’ils ont déjà été testés et approuvés sur O365, le mécanisme aujourd’hui semble donc assez robuste.

Cas d’usage : la réversibilité d’Office 365

Grâce à l’un de mes clients, j’ai pu valider la réversibilité d’Office 365 vers une offre On-Premise.

Le client avait migré l’ensemble de son infrastructure Exchange 2003 vers une offre BPOS (alors basée sur Exchange 2007), il avait alors suivi les différentes évolutions de la plateforme BPOS jusqu’à l’offre O365 actuelle basée sur Exchange 2013. Les orientations stratégiques qui l’avaient amené dans le Cloud ayant changés avec le temps, celui-ci souhaitait ré internaliser sa messagerie dans une organisation Exchange 2013 On-Premise.

Nous lui avons proposé un chemin de migration personnalisé prenant en compte ses particularités, avec la création d’une organisation locale Exchange 2013, puis la migration des différentes ressources depuis O365 vers Exchange.

Dans un environnement Active Directory relativement simple, l’installation d’Exchange 2013 ne pose pas de problème à partir du moment où l’on prend en compte la création d’un point de configuration Autodiscover, celui-ci doit être géré pour éviter que les clients internes ne soient redirigés automatiquement vers Exchange 2013 dès la fin de l’installation. Plusieurs méthodes permettent de contourner ce problème, pour ma part j’ai choisi de créer manuellement un SCP pointant vers le service Autodiscover O365. Alternativement, on peut changer le SCP du premier serveur installé via la cmdlet Set-ClientAccessServer, mais dans ce cas il est souhaitable de réaliser l’installation du premier serveur en heure non ouvrée. Dans cette configuration, les clients Outlook récupèrent le SCP le plus ancien, ce qui permet de travailler tranquillement par la suite.

Il est nécessaire de changer le mode de synchronisation de DirSync si celui-ci n’est pas en mode de coexistence, une partie des attributs O365 sont alors synchronisés avec l’annuaire local. Il faut cependant rattraper une partie des attributs AD, ceux-ci ne sont pas dans l’état attendu du mode Hybride, il faudra alors rattraper un certain nombre d’attributs, tel que l’ExchangeGUID qui servira lors des déplacements de boîtes aux lettres. La conversion des utilisateurs en RemoteMailbox permet d’arriver dans un état relativement proche de la cible, il est cependant souhaitable de sauvegarder l’ensemble des attributs AD locaux liés à Exchange avant de travailler sur la partie DirSync et le rattrapage.

Il est important d’avoir à minima une synchronisation des mots de passes avec 0365 et des UPN correspondants à l’adresse email, ce qui permet d’avoir une authentification identique sur les deux organisations. C’est d’autant plus pertinent qu’il faudra tôt ou tard basculer les services Autodiscover depuis O365 vers Exchange, avec à la fois une authentification vers Exchange, puis vers O365 pour les clients Outlooks. Accessoirement, cela permet de régler de façon transparente certains problèmes liés au Credential Manager apparu depuis Windows 7.

Une fois Exchange installé j’ai choisi d’utiliser l’assistant du mode Hybride pour créer automatiquement la configuration nécessaire, bien qu’il soit tout à fait possible de configurer manuellement chacun des aspects du mode Hybride :
– le routage des emails entre O365 et Exchange On-Premise
– la création d’une relation de Fédération, qui servira entre autre à partager les informations de disponibilité
– l’accès aux WebServices On-Premise (autodiscover, disponibilité, migration des BAL)

Les déplacements de données sont réalisés via le proxy MRS, la création d’un « Migration Endpoint » doit donc être prévue côté O365. Une fois celui-ci en place, les déplacements se font par lot via des fichiers CSV, très confortable, avec une étape de finalisation à la main de l’administrateur. Les mêmes limitations que celles liés à une migration Exchange vers O365 existent, en particulier les accès aux ressources partagées ou la configuration des périphériques ActiveSync.

Dans le cas de notre client, le processus de migration devait respecter une limite de temps stricte, la migration des 800 boites aux lettres a été réalisée en moins d’un mois.

Installation d’Exchange 2013 CU2, Windows Server 2012 et VMWare 5

Aujourd’hui j’ai installé Exchange 2013 sur un environnement virtualisé sous VSphere 5… enfin j’ai essayé! L’installation devait être effectuée sur un autre lecteur que celui du système, sans succès, par contre sur la même machine, l’installation sur le C fonctionne correctement.

Lors de l’installation de la partie Transport, l’installation s’arrête sur une erreur de droit d’accès concernant une fabrique DCOM. Les différents symptômes sont les suivants :
– dans le journal des évènements : des erreurs MSExchangeSetup 1002

Retrieving the COM class factory for component with CLSID {2DC947D7-A2DC-4276-A554-891346CE2032} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

– dans le journal de sécurité, après avoir activé l’audit du lecteur : des entrées Audit Failure 4656, Removable Storage

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          9/11/2013 8:46:40 AM
Event ID:      4656
Task Category: Removable Storage
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      BLABLABLA.brucejdc.local
Description:
A handle to an object was requested.

Subject:
            Security ID:                 NETWORK SERVICE
            Account Name:                       BLABLABLA$
            Account Domain:                   BRUCEJDC
            Logon ID:                   0x3E4

Object:
            Object Server:             Security
            Object Type:               File
            Object Name:              F:\Exchange\FIP-FS\Bin\FSCConfigurationServer.exe
            Handle ID:                  0x0
            Resource Attributes:    -

Process Information:
            Process ID:                  0x2fc
            Process Name:            C:\Windows\System32\svchost.exe

Access Request Information:
            Transaction ID:                       {00000000-0000-0000-0000-000000000000}
            Accesses:                    SYNCHRONIZE
                                               ReadData (or ListDirectory)
                                               Execute/Traverse
                                               ReadAttributes

C’est l’entrée du journal de sécurité qui est la plus parlante : les droits demandés sont des plus classiques (lecture, execution), par contre la source est du type “Removable Storage”. En effet avec VSphere 5, les disques présentés sont hotswap, ils peuvent être changé à chaud. Hors il existe une erreur sur Windows Server 2012 qui bloque pas mal d’accès sur les fichiers dès lors que ceux-ci sont sur un disque hot swap et que l’accès en audit sur les fichiers est configuré pour l’audit ou laissé en non configuré.

Il existe deux solutions : configurer l’audit pour ne pas auditer les accès aux fichiers, ou appliquer la KB 2811670 (https://support.microsoft.com/en-us/kb/2811670).
Attention a bien prendre la KB en anglais, la procédure complète n’est pas indiquée dans la version française.

Exchange 2013 : les cycles de mise à jour par Cumulative Update

Dans le modèle de mise à jour d’Exchange 2013, chaque Cumulative Update (CU) comprend l’intégralité des binaires d’installation d’Exchange, un Cumulative Update peut donc aussi bien servir à installer un nouveau serveur Exchange, comme mettre à jour un serveur existant.

On peut s’attendre à la sortie d’environ 4 Cumulative Update par an (un tous les 3 mois environ), dont l’un est classé Service Pack. Il n’y a pas de différence fondamental entre un Cumulative Update et un Service Pack, la dénomination Service Pack est utilisée dans le modèle du cycle de vie du produit. Certains partenaires qui garantissent la compatibilité de leurs propres produits avec Exchange ne peuvent pas suivre le cycle des Cumulative Update, trop rapide, et garantissent la supportablité par rapport aux Service Pack.

Il est possible de mettre à jour un serveur Exchange 2013 RTM directement avec le dernier Cumulative Update en date, cependant il faut prendre en compte un autre facteur, moins connu mais très important : les Cumulative Update ne sont supportés que jusqu’à la version N-2. La mise à jour vers le Cumulative Update 5 par exemple n’est supportée et surtout testée que pour les 2 précédant Cumulative Update, soit le Cumulative Update 4 (qui correspondant au Service Pack 1) et le Cumulative Update 3. Rien n’empêche de réaliser une mise à jour depuis la RTM, le Cumulative Update 1 ou 2, cependant ces chemins de mise à jour n’ont pas été validés par Microsoft. Dans la pratique, cela peut engendrer un certain nombre de problèmes, des étapes portées par les Cumulative Update intermédiaires ne sont pas forcément joués comme prévus.

Il existe des patchs indépendants, en général liés à des problèmes critiques, et qui sont intégrés dans le prochain Cumulative Update.

Pour la mise à jour de l’infrastructure, il n’y a pas d’ordre particulier, les nouveaux rôles Exchange 2013 n’ont presque pas d’affinités avec la version utilisée, un FrontEnd en CU4 peut toujours communiquer avec un BackEnd CU5 par exemple.

Un seul cas particulier à ma connaissance, si vous avez un DAG mise à jour vers un CU particulier, vous pouvez toujours joindre à ce DAG un serveur dans un CU inférieur, mais si il y a une mise à jour du schéma des bases de données entre les deux versions, le nouveau membre n’arrivera pas à répliquer les bases.

Restaurer un serveur Exchange 2013

La procédure est sensiblement la même que pour les versions précédentes d’Exchange :

– réinstaller l’OS
– rejoindre le système au domaine, il est préférable de réinitialiser le mot de passe de l’ordinateur, surtout dans un environnement virtualisé pour éviter des doublons
– remettre en place l’environnement et les pré requis
– en ligne de commande, avec la même version d’Exchange 2013 (et même CU):

setup.exe /mode:recoverserver /IAcceptExchangeServerLicenseTerms

Si la source n’est pas la bonne, vous aurez droit à l’avertissement suivant :

     Exchange Server version Version 15.0 (Build 712.22) or later must be used to perform a recovery of this server.
     For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DrMinVersionCheck.aspx

Il ne reste plus ensuite qu’a restaurer les paramètres locaux du serveur (clé de registre, fichiers de configuration, etc.)

La restauration ne recrée pas les dossiers contenant les bases de données. Si le dossier n’existe pas, le serveur ne sera pas capable de remonter la base.

Exchange, virtualisation, CSV et formatage

J’ai effectué pendant plusieurs semaines une campagne de JetStress pour un client dont les serveurs Exchange 2013, virtualisés, utilisaient des disques VHDX posé sur des CSV Hyper-V.

On connait bien sur la recommandation Exchange de faire un formatage 64KB sur les disques de données, mais qu’en est-il des volumes CSV? Dans notre cas de figure, la recommandation avait été suivi sur les VM Exchange, mais pas sur les volumes CSV des hôtes Hyper-V : ceux-ci étaient restés à la taille par défaut (4KB).

La différence n’était pas flagrante au départ, on obtenait au final des courbes de latence correcte en situation nominale. C’est devenu beaucoup plus flagrant lorsqu’on a commencé à stimuler un peu plus le stockage (dans notre vas via une reconstruction de raid group). En observant la latence des IO entre les VM et les hôtes Hyper-V, il y avait certes des courbes ayant la même allure, mais pas la même amplitude : un pic de latence de 200ms côté Hyper-V pouvait se transformer en pic de 1000ms côté VM!

Une fois les volumes CSV formatés en 64KB, nous avons pu récupérer en moyenne 10% de latence en moins et surtout des pics de latence beaucoup moins prononcés pendant les phases de reconstruction raid.

Je n’ai pas l’explication technique, qui est plutôt dans les mains d’un expert stockage, mais je suppose que mes IO random 32KB ou pire mes IO Séquentiels 256KB étaient fragmentés par l’hôte Hyper-V, qui attendait d’avoir l’acquittement de l’ensemble des blocs avant d’acquitter la VM.

Exchange 2016 & ReFS

Pour ceux qui ont suivi l’actualité, le nouveau formattage conseillé pour les volumes contenant les bases de données Exchange 2016 est le ReFS.

Il s’agit d’un nouveau format qui remplace NTFS dans certains scénarii, il était déjà supporté sous Exchange 2013, et les retours d’expérience ont montré une meilleure résilience des bases de données Exchange lorsqu’elles sont sur ce type de volume.

Vous pouvez consulter l’excellent blog sur l’architecture préférée Exchange 2016 : http://blogs.technet.com/b/exchange/archive/2015/10/12/the-exchange-2016-preferred-architecture.aspx

Je cite : “Each disk that houses an Exchange database is formatted with ReFS (with the integrity feature disabled) and the DAG is configured such that AutoReseed formats the disks with ReFS”

Par contre, Exchange comme ReFS réalisent tous les deux un travail identique sur la vérification des pages défectueuses : Exchange via la BDM et ReFS via la vérification d’intégrité. Il est donc nécessaire de désactiver l’une des deux pour des performances optimales.
Sous Exchange 2013, il était conseillé de désactiver la BDM, mais désormais on préférera désactiver l’intégrité ReFS.

Pour le faire sur le volume entier, il est nécessaire de passer par PowerShell avec la commande Format-Volume et le paramètre -SetIntegrityStreams $false

Par exemple :

Format-Volume -DriveLetter E -AllocationUnitSize 64KB -FileSystem ReFS -SetIntegrityStreams $false