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

Exchange 2013 : “The Module DLL C:\Exchange\Bin\Kerbauth.dll failed to load. The data is the error”

Si vous avez réaliser plusieurs installations d’Exchange sur le même serveur en modifiant le chemin, il est possible que la DLL Kerbauth, utilisé dans l’authentification du VDir Powershell, soit enregistrée vers l’un de ses anciens chemins d’installation. Vous aurez alors dans le journal d’évènement partie Application des entrées IIS-W3SVC-WP 2280 avec le message du type “The Module DLL C:\Exchange\Bin\Kerbauth.dll failed to load. The data is the error”.

Il faut la mettre à jour, pour cela :

  • arrêter le service IIS
  • aller dans C:\Windows\System32\InetSrv\config
  • éditer applicationHost.config et mettre à jour la ligne concernant kerbauth.dll
  • relancer IIS

 

Et voila :)