Symptôme

Dans le cadre d’une migration depuis une plateforme Exchange Server 2007 SP3 vers une plateforme Exchange 2010 SP2 RU5v2, l’erreur MapiExceptionNetworkError apparaît de manière régulière dans les logs des requêtes de déplacement de boîtes aux lettres (MoveRequests).

Voici un exemple :

18/01/2013 19:03:15 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:13:54 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:19:31 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:25:48 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:36:51 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:42:58 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:53:52 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:00:00 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:11:11 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:17:22 [SRV] Transient error MapiExceptionNetworkError has occurred

Le code d’erreur détaillé est le suivant :

Error details: MapiExceptionNetworkError: Unable to open entry ID. (hr=0x80040115, ec=0)

Les déplacements de boîtes aux lettres ne se terminent jamais car à chaque occurrence de l’erreur réseau, le transfert des données depuis les serveurs Exchange 2007 vers les serveurs Exchange 2010 repart à zéro.

18/01/2013 20:17:53 [SRV] Restarting the move because checkpoint data doesn't exist or isn't valid in 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)'.
18/01/2013 20:17:53 [SRV] Connected to source mailbox 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)', database 'CLUST01\StorageGroup\DB001', Mailbox server 'CLUST01.domain.local' Version 8.3 (Build 213.0).
18/01/2013 20:17:54 [SRV] Request processing started.
18/01/2013 20:17:54 [SRV] An old copy of the mailbox was removed from the destination database. The operation will try again in 30 seconds.

En parallèle, on remarque sur les boîtes aux lettres migrées vers Exchange 2010, l’apparition de nombreux évènements ayant pour source Outlook et pour ID 26 sur les postes clients (équipés d’Outlook 2010).

L’évènement émis par Outlook avec ID 26 a pour description “La connexion MAPI a été rétablie”.

Explication

Par défaut les sessions MAPI initiées par les serveurs Exchange 2010 ont une durée de vie de deux heures (7200 secondes).

Il peut arriver qu’un équipement réseau (routeur, pare-feu, HLB…) détecté une connexion MAPI comme étant inactive (idle) et coupe la session. En cas de coupure de session les clients MAPI tentent généralement de se reconnecter.

Dans notre cas c’est ce qui se produisait d’une part avec les clients Outlook (d’où les nombreux évènements au sujet d’une connexion MAPI “rétablie”) et d’autre part lorsque les serveurs CAS déplaçaient des boîtes aux lettres (d’où les erreurs “réseau”, suivies d’une reprise de la copie à son état de départ).

Remarque : Cette problématique de timeout est documentée dans la fiche support KB 2535656 (http://support.microsoft.com/kb/2535656/en-us) mais l’impact possible sur les déplacement de boîtes aux lettres (erreur “MapiExceptionNetworkError: Unable to open entry ID”) n’y est pas référencé.

Résolution

Pour résoudre ce problème, deux approches sont possibles :

A) Identifier l’équipement réseau possédant un timeout trop court et reconfigurer ce timeout sur une valeur cohérente avec celle d’Exchange 2010 (2 heures)

B) Identifier la durée du timeout (dans notre cas 300s) et ajouter la clé de registre KeepAliveTime sur l’ensemble des serveurs Exchange 2010 et 2007 pour que le timeout Exchange soit inférieur au timeout de l’équipement (par exemple positionner la valeur KeepAlive sur 180 secondes)

Dans notre cas de figure l’option la plus simple et la plus pertinente a consisté à augmenter le timeout du “protocol profil” FastL4 sur les boitiers F5 (par défaut le timeout sur ce profil était configuré à 300 secondes et il a été relevé à 7200 secondes).

Cette opération a résolu l’ensemble des problèmes rencontrés sur la plateforme (plus d’erreurs 26 sur les clients ni d’erreur MapiNetworkException lors des transferts de boîtes aux lettres).

A titre informatif, voici un exemple de configuration de la clé KeepAliveTime (attention la valeur à entrer est en millisecondes).

Symptôme

Suite à la mise en place de la supervision SCOM sur une plateforme Exchange 2010 SP2 RU5v2, des erreurs se produisent toutes les 5 minutes sur les serveurs jouant le rôle CAS.

Ces erreurs ont pour source MSExchange Control Panel et correspondent aux ID 4 et 38. Voici le détail de l’erreur 38 (avec en rouge les éléments intéressants) :

Du côté de IIS, une erreur 500 est déclenchée et visible dans les logs W3C.

Explication

Ces erreurs se produisent à intervalles réguliers (toutes les 5 minutes) lorsque le compte de service utilisé par SCOM (extest_<id>) tente d’exécuter la commande PowerShell Test-EcpConnectivity.

Lorsque l’on effectue des recherches sur ces erreurs ont tombe très rapidement sur une fiche support indiquant qu’il s’agit d’un bug Exchange 2010 résolu dans la mise à jour RU3v3 du SP1 d’Exchange 2010.

Unnecessary events are logged in the Application log when you run the "Test-EcpConnectivity" cmdlet in an Exchange Server 2010 environment
http://support.microsoft.com/kb/2494389/en-us

Néanmoins dans notre cas, l’environnement est déjà mis à jour en version SP2 RU5v2 ce qui rend cette solution caduque.

Après investigation il s’avère que la commande Test-EcpConnectivity ne supporte pas les URL possédant des majuscules.

La solution au problème consiste à modifier les URL internes et externes du service Web ECP (Exchange Control Panel) de manière à remplacer le /ECP par un /ecp.

Ce problème est donc totalement indépendant de la supervision SCOM qui est dans ce cas un simple révélateur du problème (car SCOM exécute régulièrement la cmdlet Test-EcpConnectivity).

Résolution

Dès la correction des URL (via la cmdlet Set-EcpVirtualDirectory), les erreurs ne se produisent plus et il est possible d’exécuter sans erreur la commande Test-EcpConnectivity.

Remarque : La correction prend effet immédiatement. Un petit délai peut être nécessaire dans certains environnements, le temps que la réplication Active Directory ait lieu. Il n’est pas nécessaire de redémarrer IIS.

Cette solution a déjà été testée avec succès sur plusieurs environnement Exchange 2010 SP2.

L’une des principales utilité des GPOs est d’automatiser des tâches sur un large panel d’utilisateurs (ou d’ordinateur) évitant ainsi à l’administrateur de perdre un temps précieux…

Le déploiement des imprimantes fait partie de ces tâches qui peuvent être un tracas logistique sans l’utilisation des GPOs.

La première étape est la création d’une nouvelle GPO à l’aide de la console “Group Policy Management” dans l’OU où celle-ci s’appliqueras :

Une fois la nouvelle GPO créée, ouvrez la console “Print Management”, sélectionnez l’imprimante à déployer via GPO et cliquez sur “Deploy with Group Policy” :

La fenêtre “Deploy with group policy” apparait, cliquez sur “Browse” puis sélectionnez la GPO créée puis cliquez sur OK :

Les habitués des GPOs savent sans doute qu’une GPO peut être appliquée au niveau utilisateur, ordinateur ou les deux.

Ce choix dépend de votre organisation interne, j’ai pour ma part choisi le déploiement par utilisateurs :

Il faut ensuite cliquer sur “Add” puis sur OK.

A ce niveau l’imprimante est déployée sur les clients à partir de Windows Vista.

Pour la gestion des clients XP, il est nécessaire de passer par une étape supplémentaire car contrairement aux client 7, Vista et 8 qui utilisent “gpprnext.dll” les clients XP et les serveurs antérieurs à Windows Server 2003 utilisent PushPrinterConnections.exe.

Retournons dans la console Group Policy Management.

Sélectionnez la GPO et éditez là :

Sous “User Configuration” (ou Computer Configuration en fonction du choix d’application de la GPO fait plus haut), allez dans “Windows Settings” puis “Scripts” :

Dans les propriétés du “Logon”, cliquez sur “Add” puis dans “Script Name” choisir PushPrinterConnections.exe (que l’on trouve dans le dossier SYSWOW64 sur Windows Server 2008R2) et dans les paramètres du script tapez “-log” :

Au prochain Logon, vos utilisateurs auront l’imprimantes d’installée sur leur poste, ce sans même que l’administrateur n’ait eu à se déplacer !

Dans les nouveautés de Windows Server 2012 l’interface graphique de gestion granulaire de mot de passe vient simplifier le travail de l’Administrateur en lui évitant de passer par les GPO et ADSIEdit.

La gestion granulaire des mots de passe est déjà disponible depuis Windows Server 2008, un niveau fonctionnel de 2008 suffit donc pour bénéficier de l’interface graphique sur un serveur 2012.

Avant de commencer : il est très probable que dès la mise en place de la stratégie vos utilisateurs aient à changer de mot de passe, or certaines applications ne peuvent le gérer, je vous conseille donc d’appliquer la stratégie une fois vos utilisateurs délogué.

Dans le Server Manager, lancer le tool “Active Directory Administrative Center” :

Une fois lancé, basculer en vue arborescente (Tree View), puis dans le dossier System, double-cliquer sur le dossier “Password Settings Container”

Pour créer une nouvelle politique de mot de passe, sélectionner dans l’onglet de droite : New –> Password Setting

Nous arrivons alors sur cette fenêtre et l’on remarque que Windows Server 2012 se veut intuitif :

Les textbox précédés d’un astérisque rouge sont des éléments requis pour la création de la stratégie.

Parmi ces éléments, il y a le champ “Precedence”, qui permet – dans le cas déconseillé ou plusieurs stratégies s’appliquerait aux mêmes utilisateurs ou groupes – de gérer quelle stratégie s’applique en priorité.

Une fois le paramétrage terminé, cliquer sur “Add” et la stratégie est immédiatement exécutée pour les utilisateurs concernés.

Lors de la création d’un master dans MDT, l’une des des étapes est l’intégration des pilotes. En principes ceux-ci sont généralement extractibles et il est possible de retrouver le .inf permettant l’installation du périphérique. Cependant dans quelques cas, cela n’est pas possible.

Pour pallier à ce problème, l’une des solutions est d’ajouter l’exécution d’un script Powershell dans la séquence de tâches.

Récupération des valeurs sur les postes cibles :

Tout d’abord il est nécessaire de récupérer certaines valeurs sur le modèle d’ordinateur concerné :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

Celles-ci vont nous permettre de détecter au moment du déploiement le modèle.

Script à intégrer dans la séquence de tâches :

Le script suivant est celui qui est intégré à la séquence de tâches (ici, le déploiement a été effectué sur un Elitebook 8440p de Hewlett-Packard) :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

$ModelName = $ModelName[2].replace(" ", "")

$VendorName = $VendorName[2].replace(" ", "")

if(($ModelName -eq "HPEliteBook8440p") -and ($VendorName -eq "Hewlett-Packard") ){

    Invoke-Expression "ligne_de_commande"

}

On récupère les mêmes valeurs que précédemment et ci ces dernières correspondent aux valeurs récupérées alors on exécute une commande permettant l’installation silencieuse du pilote.

Depuis Windows Server 2008 l’assistant d’installation est capable de détecter un ancienne installation de Windows Server et – dans le cas où celle-ci est compatible – l’assistant d’installation proposera un “Upgrade” vers l’OS désiré.

L’avantage de l’Upgrade est de conserver la configuration et les rôles du serveur après l’installation du nouveau système d’exploitation. Néanmoins, Microsoft recommande lors de l’installation (ou de la mise à jour) d’un serveur de passer par une “Clean Install”, soit une installation traditionnelle de Windows Server.

Pour information, il est impossible d’Upgrader d’une version 32 bits vers une version 64 bits, la seule solution est de recourir à une Clean Install.

Après une Upgrade du serveur, le dossier utilisé par l’ancien système d’exploitation est toujours présent et a été renommé Windows.old.

Pour supprimer correctement ce dossier il faut passer par le “Disk Cleanup” et les habitués de Windows Server seront surpris par son absence sur Windows Server 2012 :

Pour faire apparaitre le bouton Disk Cleanup, il faut lancer en tant qu’administrateur la commande PowerShell suivante :

Voici de retour le bouton Disk Cleanup :

Le Disk Cleanup ne propose pas immédiatement de nettoyer le dossier Windows.old, il faut passer par l’option “Clean up system files” :

L’assistant Disk Cleanup commence alors à vérifier les anciennes installations de Windows encore présentes sur le serveur :

Après analyse, l’assistant propose de nettoyer les dossiers correspondants aux anciennes installations de Windows :

En moyenne le gain d’espace fait est d’une dizaine de GB, bien entendu cela dépend de la taille de la précédente installation.

Introduction

Parmi les nouveautés apportées par Windows Server 2012 et aussi Windows 8 concernant le stockage, on trouve la fonctionnalité Espace de Stockage qui consiste à grouper des disques standard (SATA,SAS..) en plusieurs pools de stockage (Storage Pool) et ensuite créer des Espace de Stockage (Storage Space) à partir de la capacité disponible au niveau du pool de stockage.

Usage

Depuis la console Server Manager on peut accéder à l’interface d’administration du stockage en sélectionnant la fonctionnalité File and Storage Services :

Une fois la console File and Storage Services ouverte on peut  sélectionner Storage Pools ce qui nous donne accès à la console d’administration des Pools de Stockage

Cette interface unique nous permet de gérer :

• les Pools de stockage,
• les Disques physiques qu’on peut affecter à un Pool de Stockage,
• et les Disques virtuels créé.

Remarques

L’utilisation des espaces de stockage permet de :

• Simplifier le Provisionning en matière de stockage,
• Réduire les charges administrative relatif à la gestion du stockage,
• Allouer dynamiquement l’espace,
• Etendre rapidement les capacité de stockage des serveurs sans pour autant causer des arrêts de services,
• Consolider et optimiser les gestion du stockage pour des serveurs critiques.