Limiter la consommation mémoire d’Exchange 2007 et Exchange 2010

Limiter la consommation de mémoire d'Exchange 2007 et 2010

Comment limiter la consommation de mémoire de Microsoft Exchange 2007 et 2010 ?

Vous avez un soucis de consommation de votre Exchange 2007 ou votre Exchange 2010?

Après avoir vérifié le Gestionnaire de Tâches, vous avez pu constater que le processus store.exe (Banque d’Information/Information Store) consomme toute cette mémoire.

Pour limiter cela, il “suffit” de jouer avec ADSIEDIT.MSC :

Aller dans Configuration/Services/Microsoft Exchange/<Domaine Exchange>/Administrative Groups/Exchange Administrative Group/Servers/<Nom du Serveur>/Information Store.

Faire un clic droit sur “Information Store” puis propriétés et rechercher l’attribut “msExchESEParamCacheSizeMax”.

Donner la valeur suivante à msExchESEParamCacheSizeMax en fonction du nombre de BAL hébergées sur le serveur (3ème colonne):

Usage

Mémoire recommandée

Valeur à insérer

Léger

2 Go + 2 Mo/BAL

(2097152 + 2048 * Nbre BAL) / 8

Moyen

2 Go + 3.5 Mo/BAL

(2097152 + 3584 * Nbre BAL) / 8

Fort

2 Go + 5 Mo/BAL

(2097152 + 5120 * Nbre BAL) / 8

Très Fort

2 Go + 5 Mo/BAL

(2097152 + 5120 * Nbre BAL) / 8

Extrêmement Fort

2 Go + 5 Mo/BAL

(2097152 + 5120 * Nbre BAL) / 8

La 3ème colonne correspond à formule de calcul permettant d’obtenir la valeur en KB/Page, obtenue en divisant par 8 le nombre Ko de mémoire nécessaire.

Par exemple, pour une messagerie de 50 BAL à usage Fort : 2 Go + 5 Mo / BAL = 2 Go + 250 Mo = 2298 Mo = 2353152 Ko = 294144 Ko/page.

Enfin, redémarrez le service Information Store :

net stop MSExchangeIS && net start MSExchangeIS

Références :

Planning Memory Configurations Exchange 2007 Help

ESE Database Cache Size in Exchange 2007

P2V sur un volume GPT

Comment perdre 1 journée à virtualiser une machine?

C’est très facile : prenez une machine un peu récente (avec un UEFI, au hasard), sur laquelle vous avez eu la bonne idée d’installer un Windows 2008 R2 et virtualisez-là.

VMware Converter, Xen Converter, SCVMM : vous pouvez y aller, c’est un vrai bonheur! Soit l’outil vous dit gentiment d’aller vous faire cuire un œuf car “Chez nous, on ne gère pas le GPT”, soit on vous dit que le système de destination doit gérer l’EFI pour que cela fonctionne.

Et bien voilà, maintenant que le problème est posé, il va falloir trouver une solution pour virtualiser cette machine vers un VMware vSphere 5, avec des hôtes ESXi 5 – donc, compatible EFI.

Concrètement, après plusieurs dizaines de recherches sur “Google n’est plus mon pote”, il s’avère:

  1. Microsoft eux-mêmes, indiquent qu’il faut d’abord convertir le volume GPT en volume MBR pour pouvoir virtualiser la machine (http://support.microsoft.com/kb/2705349)
  2. Bon, et comme la vie est mal faite, Microsoft indique que la conversion GPT vers MBR passe par… une suppression des partitions!
  3. Contournement proposé par l’éditeur : créer une image de la partition avec l’outil Disk2VHD de SysInternals (http://live.sysinternals.com/disk2vhd.exe), monter ce disque virtuel sur une VM HyperV, et lancer l’outil de réparation qui va bien pour régler le fameux problème d’UNMOUNTABLE BOOT VOLUME  qui s’en suivra.

Bon, et bien, avec tout ça, on devrait pouvoir s’en sortir!

Malheureusement, nous ne travaillons pas avec de l’HyperV, mais avec de l’ESXi. Et du coup, une étape complémentaire vient s’ajouter : convertir le disque VHD en VMDK.

Mais heureusement, il y a des outils pour ça : WinImage par exemple.

Malgré tout cela, cette méthode ne permet pas d’obtenir un résultat satisfaisant. De plus, même si cette méthode fonctionnait, elle aurait un gros problème : son temps d’exécution.

Mise à jour Jeudi 31 Mai 2012:

Une idée pour virtualiser “à chaud” et sans trop d’étapes:

  1. Utiliser Disk2VHD de SysInternals pour créer une image du volume GPT à virtualiser
  2. Créer un fichier de définition de VM VirtualPC (fichier .VMC) contenant des informations basiques sur la VM
  3. Avec VMware Converter, convertir la VM VirtualPC vers l’infrastructure VMware ESXi 5 (ou vSphere 5) sans démarrer la VM créée.
  4. Enfin, modifier la VM dans VMware pour lui donner un EFI (au lieu du BIOS), la bonne version d’OS, les bons éléments de RAM etc.
  5. Allumer un cierge, démarrer la VM et prier

Je pense que la réparation de Windows sera nécessaire pour ajouter les bons pilotes au niveau du noyau (un post de continuum sur les communautés VMware parle de l’utilisation du contrôleur LSI SAS de VMware, dans sa méthode pour la virtualisation de Windows 2008 et GPT à froid).

Mise à jour Finale:

Toutes les méthodes trouvées sur Internet ne fonctionnent malheureusement pas. Par contre, une solution existe, basée sur ARCserve D2D : LA Solution pour virtualiser une machine GPT/EFI sous VMware

Configuration d’un IMM à distance

Vous disposez d’un serveur IBM (ou Lenovo) chez un client, et vous avez déjà été obligé de faire 200 km pour simplement allumer physiquement la machine, car votre client ne trouvait pas le bouton Power?

L’IMM va vous sauver la vie!

Le problème majeur est que la configuration réseau de l’IMM s’effectue dans le BIOS (ou l’UEFI) et redémarrer le serveur d’un client peut s’avérer compliqué.

Qu’à cela ne tienne! Voici comment configurer l’IMM directement depuis l’OS de votre client (via une connexion bureau à distance, par exemple).

  1. Commencez par télécharger ce super outil qu’est ASU (Advanced Settings Utility) chez IBM : http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=TOOL-ASU
  2. Exécutez-le afin de récupérer le fichier asu.exe (ou asu64.exe pour les systèmes x64)
  3. Maintenant, il vous suffit d’utiliser les lignes de commande ci-dessous pour configurer votre IMM, sans devoir accéder au BIOS:
    asu64 set IMM.Network1 Enabled --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.DHCP1 Disabled --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 rebootimm --host 169.254.95.118 --user USERID --password PASSW0RD
  4. Tout le secret de la configuration réside sur la carte réseau USB NDIS qui apparait sous Windows et qui obtient une IP via le service d’attribution automatique utilisé par Windows : APIPA.
    L’utilitaire ASU va communiquer avec l’IMM au travers de cette interface, via l’IP 169.254.95.118 et envoyer les commandes de configuration.
  5. Une fois les 3 premières commandes exécutées, l’IMM ne recherche plus d’IP en DHCP et se voit attribuer l’IP 192.168.70.125 : vous pouvez utiliser cette IP pour effectuer le reste de la configuration via un navigateur Web à condition que la carte de Management ait été connectée au réseau.
  6. Si cette carte n’est pas connectée, il faudra effectuer quelques manipulations supplémentaires :
    asu64 set IMM.SharedNicMode Shared --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 rebootimm --host 169.254.95.118 --user USERID --password PASSW0RD
  7. Maintenant, vous devriez pouvoir pinger 192.168.70.125.Si cela n’est pas possible (impossibilité par exemple, d’ajouter un alias IP sur la carte du serveur), vous devrez continuer la configuration en ligne de commande :
    asu64 set IMM.HostName1 IMM-SRV2008 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.HostIPAddress1 172.18.0.3 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.HostIPSubnet1 255.255.255.0 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.GatewayIPAddress1 172.18.0.254 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.DNS_Enable Enabled --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 set IMM.DNS_IP_Address1 172.18.0.254 --host 169.254.95.118 --user USERID --password PASSW0RD
    asu64 rebootimm --host 169.254.95.118 --user USERID --password PASSW0RD
  8. Normalement, tout doit être configuré maintenant avec l’IP 172.18.0.3 et vous allez pouvoir gouter à la joie des reboot hard à distance, allumage du serveur qui s’était éteint après une coupure de courant…

Note importante sur le mode SharedNicMode : dans ce mode de fonctionnement, étant donné que la carte réseau de l’OS serveur est partagée avec celle de l’IMM, il y a un partage d’adresse MAC. Du coup :

  • Il est impossible d’accéder à l’IMM depuis l’OS du serveur : en effet, les paquets sont interceptés directement par l’OS et ne sont pas envoyés vers le réseau.
  • Par contre, les machines autres que ce serveur physique peuvent accéder à l’IMM

En résumé, le mode SharedNicMode est à utiliser lorsque l’on n’a pas la possibilité d’accéder physiquement à la machine, mais doit être “rétrogradé” au mode Dedicated dès que possible, pour plus de souplesse.

IMM (Integrated Management Module) – Présentation

L’IMM (Integrated Management Module) chez IBM et Lenovo est un module intégré aux cartes mères des serveurs, permettant un accès “low-level” à la machine et permettant d’accéder à distance à des informations sur l’état de santé de la machine :

  • Température
  • Voyants Warning et d’Erreur de la machine
  • EventLog de la carte mère
  • etc.

Avec l’option “Virtual Media Key”, l’IMM permet aussi de prendre la main sur l’OS comme avec un KVM IP, avec possibilité de monter un ISO, même au travers d’une connexion WAN et de booter dessus.

Le KVM IP utilise un protocole bien connu, VNC, pour l’affichage déporté de l’écran.

L’IMM est disponible sur tous les serveurs IBM depuis quelques années (et sur les serveurs Lenovo depuis) à la condition de connecter la carte de Management sur le réseau.

L’adresse IP par défaut de l’IMM est l’adresse acquise via DHCP, ou 192.168.70.125 si aucun DHCP n’est présent.

Les login et mot de passe par défaut sont :

Login : USERID
Password : PASSW0RD  (attention chiffre 0)

Sur certaines version récentes, l’IMM peut être atteint via une des 2 cartes réseaux classiques en activant la fonctionnalité “SharedNicMode”.

Welcome !

Bienvenue dans Browse deeper in IT Blog!

Ce blog, édité par Sylvain COUDEVILLE, Directeur Technique chez ORDISYS Informatique, vous met à disposition un ensemble d’outils et de solutions IT pour vos problèmes quotidiens.