Maintenant que nous avons vu les structures qui décrivent les partitions des disques basiques GPT, voyons où nous pouvons rencontrer une corruption et comment la réparer (ou pas)
Si nous reprenons notre schéma, une corruption pourrait arriver :
La structure GPT est très robuste en ceci que windows maintient une consistance entre les GPT Header de début et de fin, ainsi que dans les tables de partitions de début et de fin, de façon à ce que si quelqu’un vient à supprimer l’un d’eux, il sera réparé au moins au prochain reboot.
La partie non protégée est le MBR (secteur 0) et c’est jusqu’à présent la seule corruption que j’ai eu à réparer sur des disques GPT Basiques.
Nous n’allons donc voir que deux types de corruption
Premier type de corruption (le seul déjà rencontré au support) : Vidage du MBR
Voilà à quoi cela ressemble dans le gestionnaire de disque :
A l’éditeur hexa, on ne voit que des 00:
Le secteur 1 contient bien ce qui ressemble à un GPT Header
Ses données semblent correctes
Signature : EFI PART
Revision: 1.0
Header Size : 92
Header CRC: 2038912732
Reserved1 : 0
This LBA : 1
Alternate LBA : 266338303
First Usable LBA: 34
Last Usable LBA : 266338270
Partition Entry LBA: 2
Partition Count : 128
Partition Entry Size : 128
Partition Array CRC : 1909465771
Disk GUID : 51063D81-877B-4536-B69E-0958EDB891C2
Si on ouvre le GPT Header alternative, on retrouve les mêmes données :
Si on parcours la table de partition (LBA 2) on trouve une table de partition contenant la MSR et 3 partitions de données. Dans mon cas, je n’ai que 3 partitions sur mon disque donc, les autres LBAs (jusqu’au 33) sont vides.
On peut reporter les données dans ce tableau (pour l’interprétation, se référer au chapitre précédent)
Partition 1
Partition 2
Partition 3
Partition 4
Partition Type
E3C9E326-0B5C-4DB8-817D-F92DF00215AE
EBD0A0A2-B9E5-4433-47C0-68B6B72699C7
Partition GUID
18516D6A-C900-4A25-888C-E27974E44EAA
0DC137A4-CEFF-48ED-8EF8-E08282AA555B
32781219-85A3-470B-A075-DBD480A9D685
3D0A2A5F-8F8A-43B6-B859-8EA9930DCBE6
Starting LBA
34
264192
184416256
245854208
Attribute Flags
0
Ending LBA
262177
184416255
245854207
266334207
Partition Name
Microsoft reserved partition
Basic data partition
Dans le cadre d’une réparation, il faut bien vérifier que les secteurs 264192/184416255 , 184416256/245854207 et 245854208/266334207 sont des secteurs NTFS et contrôler qu’ils pointent bien vers une MFT a priori correcte. (nous avons traité ces points dans les articles précédents)
Donc:
Seul le MBR est à reconstruire
Il ne nous reste plus qu’à réparer le MBR en se souvenant qu’ils sont tous identiques.
Partition table entry
Start head : 0
End head : FF (255)
Start sector : 2
End Sector : 3F (63)
Start Cylinder : 0
End Cylinder : 3FF (1023)
Relative Sector : 1
Total Sectors : FFFFFFFF (4294967295)
Partition Type : EE (GPT)
Magic number : 55 AA
En utilisant un éditeur hexa il reste à écrire ces données :
Et c’est tout. Un rescan du disque et on n’en parle plus.
Serge Gourraud55 AA
Dans l'article précédent, nous avons vu comment sont structurés les partitions et volumes sur les disques. Nous allons voir cela da façon concrète sur un disque MBR Basique.
Pour cela, j'utilise un éditeur hexadécimal et ouvre le disque aux secteurs qui m'interressent. L'éditeur que j'utilise s'apelle dskprobe.exe (un outil Microsoft assez basique qui affiche les secteurs par pages de 512 Bytes) mais vous pouvez utiliser celui qui vous convient le mieux. Une liste est disponible sur http://fr.wikipedia.org/wiki/%C3%89diteur_hexad%C3%A9cimal
Ouvrons le secteur 0 d'un disque MBR Basique.
En rouge:
En surligné : La table de partition, contenant 4 entrée.
La partie au dessus est du code.
Focalisons-nous sur la première entrée de la table de partition, et essayons de lui faire correspondre la description disponible sur http://technet.microsoft.com/en-us/library/cc739412(v=ws.10).aspx
Offset
Taille du champ
Valeur
Nom du champ
01BE
1 byte
00
Indicateur de boot:
01BF
20
Starting Head : 0x20 = 32 en décimal
01C0
6 bits
21
Starting Sector : 0x21 = 00100001 -> 00 100001 = 33
01C1
10 bits
Starting Cylinder : 0x00 = 00000000 -> 00 00000000 = 0
01C2
07
Type de partition. 07 signifie NTFS
http://technet.microsoft.com/en-us/library/cc739412(v=ws.10).aspx
01C3
FE
Ending Head : 0xFE = 254
01C4
FF
Ending Sector : 0xFF = 11111111 -> 11111111
= 111111 = 63
01C5
Ending Cylinder : 0xFF = 11111111 -> 11 11111111 = 1111111111 = 1023
01C6
4 bytes
00 08 00 00
Relative Sector : 1er secteur de la partition (en GPT on appelera ça Starting LBA)
En little endian, lire : 00 00 08 00 = 0x800 = 2048
01CA
00 E8 DF 0F
Total Sectors : Le nombre de secteurs de la partition
0x0FDFE800 = 266332160
Ca veut dire que ce disque contient une partition NTFS qui démarre au secteur 2048 et occupe 266332160 secteurs.
Nous ne savons pas encore exactement quelle taille cela fait en Bytes, mais la plupart du temps, 1 secteur occupe 512 bytes. Ce qui nous fait (si on a des secteurs de 512 bytes)
Considérons maintenant quelque chose d'un peu plus fréquent: Un disque contenant plusieurs partitions.
Notre table de partition au secteur 0 pourrait bien ressembler à cela:
Ce qui nous donne ce petit tableau récapitulatif:
Partition
Indicateur de boot
Starting Head
20 = 32
254
Starting Sector
21 * = 33
63
Starting Cylinder
0 *
1023
System ID
07 (NTFS)
Ending Head
FE = 254
Ending Sector
63 *
Ending Cylinder
1023 *
Relative Sector
00000800 * = 2048
07547000 = 122974208
0A61B000 = 174174208
Total Sectors
07546800 * = 122972160
030D4000 = 51200000
03A98000 = 61440000
* *Toujours en suivant la petite moulinette de ne garder que 6 bits sur le 1er champ, et d'ajouter les 2 restants aux 8 d champs suivant
*A lire en little endian
Dans l’article suivant, nous détaillerons un disque contenant des partitions étendues.
Serge Gourraud
55 AA
Pour faire reparaitre une partition disparue, nous avons besoin de peu de chose pour faire cette recuperation:
Nous allons voir comment récupérer une partition qui a disparu suite à une opération manuelle malencontreuse.
Windows étant un petit paresseux, nous savons que quand on supprime une partition, seule l’entrée dans la table de partition est supprimée.
Vérification:
Dans les architectures récentes, les partitions NTFS commencent le plus souvent au secteur 2048 (les anciennes démarraient au secteur 63).
Si ce n’est pas le cas, il faut chercher sur le disque. Certains éditeurs hexa permettent de le faire, dskprobe le permet.
Dans notre cas, le secteur 2048 est bien un secteur d’amorçage NTFS :
Nous pouvons identifier facilement :
Donc le NTFS Boot Sector de backup devrait se trouver au secteur 266334207 ( = 2048 + 266332159 )
Allons voir :
Vérifions que nous retrouvons bien la MFT
Le secteur 6293504 ressemble bien au premier metafichier de la MFT
Le metafichier $Volume nous fournit bien le bon nom de volume (à vérifier avec l’administrateur)
Donc en résumer, même si la partition a été supprimée, les données sont toujours présentes :
Ce qui reste à faire est donc la chose suivante :
Un rescan devrait faire reparaitre le disque.
Ces étapes en image :
1. Sauvegarde du contenu du secteur 2048 avec dskprobe2.exe
2. Création de la partition sans la formater
Suivant … Suivant … Jusqu’à l’option de formatage : Choisir l’option "Do not format this volume"
Nous obtenons une partition RAW :
3. Ecraser le NTFS Boot sector par celui sauvegarder
Dans DskProbe se placer sur le secteur 2048 du disque, et ouvrir le fichier que nous venons de sauvegarder Ecrire le fichier sur le secteur 2048 Vérifier qu’on écrit bien 1 secteur sur le secteur 2048 et cliquer sur "Write" Retourner au secteur 0 et remplacer le "06" à l’offset 1C2 par "07" : bien presser la touche 0 et la touche 7. Puis faire un Write
Dans DskProbe se placer sur le secteur 2048 du disque, et ouvrir le fichier que nous venons de sauvegarder
Ecrire le fichier sur le secteur 2048
Vérifier qu’on écrit bien 1 secteur sur le secteur 2048 et cliquer sur "Write"
Retourner au secteur 0 et remplacer le "06" à l’offset 1C2 par "07" : bien presser la touche 0 et la touche 7.
Puis faire un Write
Un Rescan Disk dans le Disk Manager fait reparaitre le disque
Parmi les nouveautés (ce ne sont plus vraiment des nouveautés à l’heure actuelle) apportées avec Windows Server 2008, l’outil de diagnostic Validate en est une qui laisse parfois dubitatif.
En effet, il est expliqué que les clusters n’ayant pas satisfait les deux critères suivants ne sont pas supportés :
Mais alors, pourquoi un composant ne disposant pas du logo “Certified for Windows Server 2008” compromettrait la supportabilité de mon cluster alors que le passage de Validate n’indique aucune erreur ?
La réponse tient en deux points :
La mise en place d’un cluster étant toujours déterminé par un besoin de haute disponibilité, la mise en place de ces nouveaux critères de supportabilité apportent une assurance plus importante sur ces plateformes critiques.
De plus, un cluster est énormément dépendant des composants tiers qui sont mis en oeuvre pour le faire fonctionner : SAN, cartes réseau, drivers de carte HBA, etc… Comme Microsoft n’est pas maître pour le développement de ces parties, nous nous devions d’offrir cette garantie supplémentaire.
Concrètement, qu’apporte cette nouvelle stratégie de support ?
Auparavant, par le biais de la HCL (Hardware Compatibility List), les constructeurs proposaient des “solutions” cluster, autrement dit des packages en bon français. L’ensemble était validé par chaque constructeur suivant les préconnisations de Microsoft.
Désormais, le niveau de validation n’est plus au niveau du cluster mais du composant. Il est donc possible de choisir des composants disparates pour construire son cluster. Tant que ces éléments disposent du logo “Certfied for Windows Server 2008”…
En allant plus loin, il est possible d’installer un cluster Windows Server 2008 avec des serveurs de marques différentes même s’il est toujours recommandé de garder une configuration homogène.
Pour trouver des composants certifiés : Windows Server Catalog (en Anglais)
Une fois remplis le critère de la qualification des éléments qui formeront un cluster, Validate apporte un avantage important par rapport à Windows Server 2003 consistant à s’assurer du fonctionnement du cluster et de tous les composants impliqués dans son fonctionnement avant son installation.
Pour avoir un point de comparaison, jusqu’à Windows Server 2003 lorsque l’on planifait la mise en place d’un cluster MSCS, la seule façon de savoir si un cluster fonctionnerait correctement était de créer ce cluster (avec tous les problèmes potentiels à résoudre pendant l’installation) puis de le tester en forçant des bascules de groupes et de ressources.
Depuis Windows Server 2008, en utilisant Validate, il est possible de vérifier avant la création du cluster si la plateforme matérielle et logicielle sélectionnée fonctionnera de manière optimale.
Principalement, cet outil permet d’identifier les problèmes de configuration réseau (adressage, connectivité, …) et stockage (zoning, pré-requis SCSI, …) de manière proactive et d’y remédier avant l’installation du cluster.
Si le rapport de validation ne présente que des feux vert alors le cluster fonctionnera de manière optimale.
Autrement, il faudra traiter les erreurs remontées. A ce sujet, chaque erreur identifiée est accompagnée de commentaires permettant d’en identitifer la cause.
Validate est un assistant de diagostic visant donc deux objectifs principaux :
Validate, meilleures pratiques
Pour garantir la supportabilité d’un cluster dans le temps, il est recommandé (sinon requis) d’exécuter Validate à chaque fois qu’un changement est apporté au cluster (ajout d’un noeud, changement d’une carte HBA, …).
Les scénarios pour lesquels il est recommandé d’exécuter Validate sont identifiés ici : Understanding the validation tests required for your scenario (TechNet, en Anglais)
Au delà de la supportabilité, Validate peut également être utilisé pour diagnostiquer d’éventuels dysfonctionnement.
Grâce au rapport généré par cet outil, il peut être possible de mettre le doigt sur un problème de configuration qui permettra de corriger ce problème.
Ressources
Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster (TechNet, en Anglais)
KB943984 - The Microsoft Support Policy for Windows Server 2008 Failover Clusters (en Anglais)
Windows Server Catalog (en Anglais)
Failover Cluster Configuration Program (en Anglais)
Guillaume
Windows Core Support Escalation Engineer
Dans les articles qui suivent, nous évoquerons ces termes à maintes reprises. Autant se familiariser tout de suite avec ces termes :
L'objectif de ces articles est de parcourir les secteurs importants des disques pour comprendre où pourrait se placer une corruption et de la réparer (quand c'est possible) juste en écrivant la bonne information au bon endroit. Toutes les structures que nous allons parcourir sont déjà décrites dans MSDN.
Aussi, si vous souhaitez avoir plutôt une approche développeur, un bon point de départ serait d'invoquer un DeviceIoControl en utilisant le control code IOCTL_DISK_GET_DRIVE_LAYOUT_EX (cf. http://msdn.microsoft.com/fr-fr/library/windows/desktop/aa365174(v=vs.85).aspxpour plus de détails)
Ce contrôle vous fournira une structure de type DRIVE_LAYOUT_INFORMATION_EX
typedef struct _DRIVE_LAYOUT_INFORMATION_EX {
DWORD PartitionStyle; DWORD PartitionCount; union { DRIVE_LAYOUT_INFORMATION_MBR Mbr; DRIVE_LAYOUT_INFORMATION_GPT Gpt; }; PARTITION_INFORMATION_EX PartitionEntry[1];
DWORD PartitionStyle;
DWORD PartitionCount;
union {
DRIVE_LAYOUT_INFORMATION_MBR Mbr;
DRIVE_LAYOUT_INFORMATION_GPT Gpt;
};
PARTITION_INFORMATION_EX PartitionEntry[1];
} DRIVE_LAYOUT_INFORMATION_EX, *PDRIVE_LAYOUT_INFORMATION_EX;
Nous n'évoquerons pas d'avantage cette approche dans cette série, mais cela pourrait faire le sujet d'une autre série si la demande est forte.
Comme expliqué, la MSDn regorge de schémas explicatifs mais essayons de les présenter différemment afin d'afficher plutôt une comparaison de ces structures, si cela peut aider.
Comparaison MBR et GPT
Différences principales (liste non exhaustive) dans les fonctionnalités:
MBR
GPT
Nombre de partitions primaires
4
128
Taille de disque maximale
2 TB
2^64 LBA = 8*2^30 TB
Protection de la table de partition
NON
OUI
Quelques références:
Comparaisons des structures identifiables, écrites à plat sur les disques basiques
Pour avoir une vision complète des disques basiques, aller sur http://technet.microsoft.com/en-us/library/cc739412(v=ws.10).aspx
Comparaisons des structures identifiables, écrites à plat sur les disques dynamiques
Pour avoir une vision complète des disques dynamiques, aller sur http://technet.microsoft.com/fr-fr/library/cc758035(v=WS.10).aspx
Comparaisons des disques basique et dynamiques
Différences principales (liste non exhaustive) en terme de fonctionnalités
Basiques
Dynamiques
Nombre maximal de volumes
> 4*
RAID Logiciel
Protection des volumes
Extension de volumes
OUI **
* Le nombre de volumes que peut supporter un disque dynamique n'est pas illimité car la database est limitée à 1 MB. Sachant que chaque disque dynamique attaché à un système contient la descroption de tous les volumes de ce système, rajouter des disques n'augmentera pas cette limite. Au contraire, il faudra rajouter des enregistrement pour en plus pour décrire le nouveau disque.
**Il est possible d'étendre un volume sur plusieurs disques dynamique, mais sur des disques basiques, on ne peut rester que sur le même disque.
Les différents types de volumes sont décrit sur : http://technet.microsoft.com/fr-fr/library/cc737048(v=WS.10).aspx
Dans le post suivant, nous allons tenter de voir concrètement comment cela se traduit en donnée brute écrite sur les disques.
Recupération de partitions III : Structures des disques basiques MBR - Les partitions étendues
Dans l’article précédent, nous avons vu un exemple de partitionnement contenant une et plusieurs partitions primaires. Afin de pouvoir mettre plus de quatre partitions sur un disque, il existe un système de partition étendue. En quelques mots :
- Si vous souhaitez 1 à 4 partitions : Vous aurez 4 partitions primaires
- Si vous souhaitez 5 partitions ou plus : Vous aurez 3 partitions primaires et 1 partition étendue contenant autant de volumes que souhaité.
Si on observe la table de partition à l’éditeur hexa, on sait qu’il n’y a la place que pour 4 entrées et on voit bien que les 4 entrées sont occupées.
La dernière entrée a ceci de particulier qu’elle est de type 0x0F (partition étendue), et qu’elle occupe 30722048 secteurs (ce qui nous donnerait à peu près 14 GB pour des secteurs de 512 Bytes)
Donc, si nous refaisons notre petit tableau récapitulatif:
Boot indicator
21 = 33
0F (Extended)
00000800 = 2048
0E0B3000 = 235614208
07546800 = 122972160
01D4C800 = 30722048
Avant d’aller plus loin regardons à quoi ressemble le premier secteur d’une partition NTFS. La première partition (PPart01) est sensé démarrer au secteur 2048, et voici le secteur 2048 :
Nous détaillerons le contenu de ce secteur dans la partie 4, mais pour l’instant nous avons juste besoin de savoir que ce secteur est signé "55 AA" et qu’il contient bien le OEM ID "NTFS".
Regardons maintenant ce qui se trouve au secteur 235614208 (entrée de la 4ième partition). Il est quasiment vide, mais nous pouvons y reconnaitre une nouvelle table de partition dans la partie inférieure.
Cette table de partition contient deux entrées:
En passant tout ça à la moulinette, on peut construire ce petit tableau:
Entry 1
Entry 2
Entry 3
Entry 4
05 (Extended)
00FA0800 = 16386048
005DB800 = 6141952
003E8000 = 4096000
Quand on parcours une partition étendue, le Relative Sector ne fait pas référence au début du disque, mais au début de la partition étendue.
Comme notre partition étendue démarre au secteur 235614208, le premier volume NTFS devrait se trouver au secteur 235616256 ( = 235614208 + 2048 )
Cela reseemble bien à un secteur NTFS:
Maintenant, regardons ce qui se trouve à la seconde entrée de la table de partition. Son Relative Sector est 10242048 et la partition étendue démarrait au secteur 235614208. Donc l’entrée doit nous faire pointer vers le secteur 245856256 ( = 235614208 + 10242048 ). Allons voir :
C'est une nouvelle table de partition contenant ces informations:
La partition NTFS suivante démarre au secteur 245858304 ( = 245856256 + 2048 ) et la prochaine table de partition au secteur 252000256 ( = 235614208 + 16386048 )
Comme nous n’avons que 3 volumes dans la partition étendue, ce table de partition devrait être la dernière qui pointe vers une partition NTFS et nous n’avons qu’une seule entrée puisque nous n’avons pas d’autres volumes à déclarer.
Voilà comment Windows s’y prend pour faire entrer plusieurs partitions dans des tables qui ne peuvent en contenir que 4.
Dans l’article suivant, nous allons détailler le contenu d’un secteur d’amorçage NTFS afin de pouvoir commencer les réparations.
Objectif:
Nativement, le service Cluster maintient sa configuration en copiant sur tous les nœuds du Cluster la Hive Cluster. Cette Hive (une ruche en anglais) se situe dans HKLM\Cluster et contient tous les paramètres des ressources du Cluster. C'est-à-dire que les ressources utilisées dans le Cluster stockent leurs paramètres et propriétés dans cette Hive (@IP, nom du Network Name, chemin d’un File share , etc). On retrouve également une copie de cette Hive sur le disque du Quorum (Q:\MSCS) sous la forme d’un fichier CHKxxx.tmp.
Mais si une application clusterisée n’utilise pas la section HKLM\Cluster pour y stocker ses données, comment les autres nœuds peuvent recevoir ce contenu ?
Le registry Checkpointing dans un cluster a pour objectif de propager le contenu d’un bout de base de registre qui ne serait pas localisée dans HKLM\Cluster mais dans HKLM\Software, là où les applications enregistrent généralement leurs données.
Des fichiers 0000000x.CPT présents sur le disque du quorum représentent le contenu de base de registre qui sont à sauvegarder et donc a propager lorsque ces ressources basculent d’un nœud à un autre. Ils sont organisés comme suit :
ü 0000000x.CPT représente un checkpoint registry pour une ressource.
ü Il sont stockés sur le disque du Quorum comme ceci : Q:\MSCS\<GUID>\ Q : étant le disque du Quorum et MSCS le répertoire par défaut
ü Il sont stockés sur le disque du Quorum comme ceci : Q:\MSCS\<GUID>\
Q : étant le disque du Quorum et MSCS le répertoire par défaut
<GUID> est le GUID de la ressource nécessitant un checkpoint registry et que nous retrouvons dans HKLM\Cluster\GUID.
Ce principe est utilisé par SQL ou des applications génériques par exemple.
Ressources en ligne:
How a Server Cluster Works: http://technet2.microsoft.com/WindowsServer/en/library/4aa0be73-ef61-4f9c-a071-b390278b47731033.mspx?mfr=true
Checkpointing http://msdn2.microsoft.com/en-us/library/aa367195.aspx
ClusterRecovery tool: http://www.microsoft.com/downloads/details.aspx?familyid=2BE7EBF0-A408-4232-9353-64AAFD65306D&displaylang=en
Knowledge Base:
Restore registry check points stop working after you restore a server cluster
http://support.microsoft.com/default.aspx?scid=kb;EN-US;307469
174070 Registry replication in Microsoft Cluster Server
http://support.microsoft.com/default.aspx?scid=kb;EN-US;174070
Règles relatives au checkpoint Registry
cluster . /checkpoints
Ajouter un Checkpoint au Cluster
cluster . resource "< Nom de la ressource >" /addcheckpoints:"\Software\...”
Supprimer un Checkpoint au Cluster
cluster . resource "< Nom de la ressource >" /removecheck :"\Software\...”
Mise en situation :
Imaginons que nous avons créé une application Client/Serveur ‘Onyone’ dont les données de registre sont stockées sous HKLM\Software\Onyone et HKLM\Software\Onyone2. Nous souhaitons la mettre dans un cluster sous forme d’application générique afin d’offrir aux utilisateurs une haute disponibilité. Pour assurer la copie des clefs précédentes, nous allons ajouter à l’aide de la commande CLUSTER.EXE, deux checkpoints sur la ressource Network Name ‘Network Name DATA’ de cette application.
C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone" Adding registry checkpoint 'SOFTWARE\Microsoft\onyone' for resource 'Network Name DATA'...
C:\>cluster resource "Network Name DATA" /addcheckpoints:"SOFTWARE\Microsoft\onyone2" Adding registry checkpoint 'SOFTWARE\Microsoft\onyone2' for resource 'Network Name DATA'...
Regardons maintenant la prise en compte de ces commandes :
C:\>Cluster . resource /checkpoints No resource name specified.
Listing registry checkpoints for all resources... Resource Registry Checkpoint -------------------- -------------------------------------------------------- Quorum Disk None Cluster IP Address None Cluster Name None Disk P: None IP File Share None Network Name DATA 'SOFTWARE\Microsoft\onyone' Network Name DATA 'SOFTWARE\Microsoft\onyone2' File Share None
Listing registry checkpoints for all resources...
Resource Registry Checkpoint -------------------- -------------------------------------------------------- Quorum Disk None
Cluster IP Address None
Cluster Name None
Disk P: None
IP File Share None
Network Name DATA 'SOFTWARE\Microsoft\onyone'
Network Name DATA 'SOFTWARE\Microsoft\onyone2'
File Share None
Sur le disque du quorum, nous retrouvons dans le répertoire \MSCS (par défaut), un nouveau répertoire qui a été créé et ayant le GUID de la ressource concernée et contenant deux fichiers CPT :
Ce GUID est peut être retrouvé dans la clef HKLM\Cluster.
Lionel
Un peu de nostalgie...
La blonde pris dans les phares
Au taquet, même en plein déménagement
Ne pas perdre sa concentration
Il tient bien la pose, non ?
Les machines à café...
Sous le bureau de Dan...
Faire parti de l'équipe Core requiert un certain état d'esprit
On laisse un peu de déchets derrière nous
La loi de la gravité s'appliquait aussi aux Ulis
Pour pouvoir récupérer une partition NTFS, il faut savoir l'identifier. Une partition NTFS contient essentiellement:
Pour une description complète de chacun des champs : http://technet.microsoft.com/fr-fr/library/cc781134(WS.10).aspx
Pour rappel, la table de partition 0 nous montrait une partition démarrant au secteur 2048 et occupant 122972160 :
Examinons en détails le NTFS Boot Sector
Si on dresse un tableau de ces données on obtient ça:
Byte Offset
Field Length
Sample Value
Field Name
0x00
3 bytes
EB 52 90
Jump Instruction
0x03
8 bytes
NTFS
OEM ID
0x0B
2 bytes
00 02 (512)
Bytes per sector
0x0D
08
Sectors per Cluster
0x0E
00 00
Reserved Sectors
0x10
00 00 00
Must be 0
0x13
0x15
F8
Media Descriptor
0x16
0x18
3F 00
Not used
0x1A
FF 00
0x1C
00 08 00 00 (0x800 = 2048)
0x20
00 00 00 00
0x24
80 00 80 00
0x28
FF 67 54 07 00 00 00 00 (122972159)*
0x30
00 00 0C 00 00 00 00 00 (786432)
Clusters to $MFT
0x38
02 00 00 00 00 00 00 00 (2)
Clusters to $MFTMirr
0x40
F6 (246) **
Clusters Per MFT Record
0x41
0x44
01
Clusters Per Index Buffer
0x45
0x48
31 DD 45 AE 2B 46 AE FE
Volume Serial Number
0x50
*La table de partition présente au secteur 0 nous avait indiqué une partition occupant 122972160 secteurs. Ca fait un secteur de plus, car dans cette table, on compte le 1er secteur de la partition ainsi que le dernier. Dans le secteur d’amorçage NTFS on compte un secteur de moins. Il faudra s’en rappeler quand nous ferons des réparations.
**La taille de chaque enregistrement. NTFS fera un enregistrement pour chaque fichier et répertoire de son volume. Ceux dont la taille est inférieur à la taille d’un enregistrement sont résident dans la MFT. Si ce nombre est positif (entre 00 et 7F) alors il represente le nombre de cluster par enregistrement. Si le nombre est négatif (de 80 à FF), alors la taille d’un enregistrement est 2 à la puissance la valeur absolue de la valeur de ce champ.
Clusters to MFT est de 786432, et nous avons 8 secteurs par cluster. Donc, la MFT est localisée au secteur 6293504 ( = 2048 + 786432 * 8 )
Nous pouvons voir à cet emplacement, le premier fichier de la MFT : $MFT
Sachant que chaque enregistrement occupe 1K, il est possible de parcourir tous les enregistrements de la MFT jusqu’à, par exemple, l’enregistrement $Volume qui fournit le nom du volume. Puisqu’il s’agit du 4ième, nous le trouverons au secteur 6293510.
Si nous ne trouvons rien de ce genre à cet emplacement, c’est que soit la donnée a été écrasée, soit qu’on n’est pas au bon endroit : Le secteur d’amorçage n’est peut-être pas le bon, ou contient de mauvaises informations
Dans l’article suivant nous récupérons une partition.
La HCL , WSC ou matrice de compatibilité Cluster, ça vous dit quelque chose?
Mais si, ce sont ces fameuses listes qui répertorie l'ensemble des élements composant une solution Cluster 2000/2003. L'ennui est qu'il est difficile de trouver sa configuraiton et les matériels et logiciels évoluant, elle n'est pas forcement à jour. C'est pour cela que je vous ai regroupé différents pointeurs vers les OEM les plus connus pour limiter les spectres de vos recherches. Si vous avez un doute sur la compatibilité de votre matériel avec le MSCS, il est facile de demander à votre OEM le lien vers vers votre solution en place.
Et pour Failover Cluster 2008 et 2008 R2? et bien, c'est beaucoup plus simple : il suffit que vos composants (hosts, HBA, SAN et softtware) aient reçus le logo Certified for Windows Server 2008 ou Certified for Windows Server 2008 R2 et que les tests de Validate passent avec succès. That's All!
The Microsoft Support Policy for Windows Server 2008 Failover Clusters : http://support.microsoft.com/kb/943984
Marc Bouchard de l’équipe Domaine & Sécurité a écrit un bulletin listant nos recommandations concernant la virtualisation des contrôleurs de domaine.
Ce bulletin regroupe des points très importants à respecter.
Pour le consulter : DC Virtuel: Les règles de bases
Avec l’augmentation du nombre de machines virtuelles, par intérêt ou par simple curiosité vous souhaitez manipuler vos hôtes Hyper-V ou les machines virtuelles hébergées autrement que par la console Hyper-V ?
Tony Soper a mis à disposition 35 scripts PowerShell permettant de répondre à de nombreux besoins liés à la maintenance d’une plateforme de virtualisation Hyper-V.
Téléchargement : Hyper-V PowerShell Example Scripts.zip
Autre ressource utile, disponible sur CodePlex : PowerShell Management Library for Hyper-V
Windows Support Escalation Engineer
Tout comme il l’est fait pour le cluster, un article KB est désormais disponible pour référencer les correctifs recommandés pour System Center Virtual Machine Manager 2008.
Cette fiche liste également les correctifs requis et recommandés pour les hôtes Hyper-V gérés par SCVMM.
KB962941 - Recommended hotfixes for System Center Virtual Machine Manager 2008
Après nous être concertés longuement, nous sommes tombés d’accord sur ce que nous pouvions vous souhaiter pour l’année à venir.
Tout ce que nous espérons pour vous c’est de n’être impactés que par peu de problèmes (suffisament pour nous permettre de vous aider et de toujours faire ce métier passionnant) et surtout nous ne vous en voudrons pas si la complexité des incidents que vous nous remontez baisse un peu l’an prochain, cela nous permettra de souffler un peu !
Plus traditionnellement, meilleurs voeux, bonne santé et réussite pour vous et vos proches !
Restez connectés !
L’équipe de Support Windows Core
Dans le cadre des déploiements de Windows XP ou de Windows Server 2003, si les drivers ne sont pas intégrés dans l’image ou dans l’installation unattended, l’apparition des messages annonçant la découverte d’un nouveau périphérique peut se révéler très vite agaçant !
Cette nouvelle fiche technique met à disposition un correctif permettant de les supprimer :
KB938596 - Hotfix adds new functionality to suppress Plug and Play-related UI messages in Windows Server 2003 or in Windows XP
Tous les aficionados du cluster auront remarqué la disparition de la fonctionnalité pourtant très appréciée de partage automatique des sous-répertoires d’un partage clusterisé.
En dehors de la création manuelle de ces partages, point de salut.
Voilà une petite commande pour partager tous les sous-répertoires du répertoire courant.
FOR /F %i IN ('dir /b /a:d') DO net share %i=%CD%\%i
Si les partages doivent être cachés, la commande devient :
FOR /F %i IN ('dir /b /a:d') DO net share %i$=%CD%\%i
Explication :
dir /b /a:d renvoie la liste des répertoires contenus dans le répertoire courant
/b pour une liste simple et /a:d seulement les fichiers qui sont des répertoires (directory)
La boucle FOR va donc exécuter le code qui suit le DO pour chacune des entrées renvoyée par le dir
la commande net share permet le partage, on lui indique le nom du partage et le chemin d’accès complet au partage
%i ou %i$ sera le nom du partage (respectivement visible et caché), ce nom est le nom du répertoire lui même
%CD%\%i est la concaténation du chemin d’accès complet (répertoire actuel) et du nom du sous-répertoire à partager
Les 2 lignes de commandes citées devront être exécutées directement depuis l’invite de commande
Pour celles et ceux qui veulent inclure ces lignes dans un fichier .cmd ou .bat, voici la syntaxe à utiliser :
FOR /F %%i IN ('dir /b /a:d') DO net share %%i=%CD%\%%i
FOR /F %%i IN ('dir /b /a:d') DO net share %%i$=%CD%\%%i
le %i qui est la variable locale à notre commande doit avoir un double % pour être correctement interprétée
Le %CD% est une variable système et n’a donc pas besoin d’être doublé au niveau du %
Le terme de “support” peut parfois être réducteur et faire penser à de la hotline mais dans le cas des grands fournisseurs de logiciels ou de matériel, le support est une entité à part entière qui tient sa place dans la stratégie. Chez Microsoft, le support représente un outil reconnu dans la relation avec ses clients car il permet de mieux aider les entreprises à assurer le suivi des produits déployés en production.
De toutes les manières, ne dites jamais à un ingénieur support Microsoft qu’il fait de la hotline :-)
Le périmètre
Afin d’avoir une idée de notre rôle de support dans le cadre de la plateforme Windows, il faut tout d’abord mettre en avant les produits et technologies qui font partis de notre domaine de compétences. Tous ne sont pas listés, il y a environ 80 briques, mais cela peut donner une idée de la complexité de la tâche !
Tout d’abord, la série Windows :
Les applications :
Enfin, les grandes technologies :
Quel est notre rôle ?
Concrètement, notre rôle consiste à assister nos clients quand ils font face dans leur environnement à des dysfonctionnements ou comportements inattendus liés aux produits et technologies Microsoft.
C’est ce que nous appelons le service de support réactif :
Nous avons également un autre rôle vis à vis de nos clients que nous identifions comme des services de support proactifs. Ce type de services fournit aux clients une assurance de supportabilité avant le déploiement d’un produit ou d’une solution Microsoft ou permet de délivrer des formations ou des présentations techniques.
Services proactifs :
Comment nous intervenons auprès de nos clients ?
Pour pouvoir faire appel à nous il faut disposer d’un contrat de Support Premier, étant donné que nous n’intervenons que dans des problématiques impliquant des produits professionnels auprès des sociétés ayant souscrit ce type de contrat. L’équipe de support Française Windows Core est engagée avec des clients présents en Europe du Sud, Afrique du Nord et au Proche Orient et nous sommes le point de contact pour tous les clients parlant Français en Europe.
Le principe est simple, pour être mis en contact avec l’un d’entre nous :
Bien évidement, nous avons des processus permettant de gérer le flux des dossiers afin d’assurer le meilleur service possible. Le premier mécanisme qui entre en œuvre est le respect des SLAs définies en fonction de la criticité de chaque incident.
Les cinq niveaux de criticité sont les suivants :
Nos principales tâches
Pour la partie la plus sympathique, la plupart de nos journées sont occupées par l’analyse des journaux d’évènements, des fichiers log divers et variés, des traces collectés sur les systèmes impliqués dans les dysfonctionnements qui nous sont remontés.
Plus délicat, les traces perfmon représentent également une part non négligeable ainsi que l’analyse de dumps, soit générés lors de crashes systèmes ou manuellement initiés.
De manière moins fréquente, la revue d’éléments de configuration et de documents d’architecture fait aussi partie de nos responsabilités.
Pour terminer, l’équipe Windows Core, qui est représentée par 17 ingénieurs aujourd’hui (je ne compte pas Elena et Laurentiu qui viennent de nous rejoindre et sont en formation), traite en permanence une moyenne de 200 incidents qui vont du plus simple (ce qui devient rare) au plus complexe et du moins critique au plus impactant.
A savoir que nous ne sommes pas en permanence 17 à gérer les incidents étant donné que nous nous déplaçons également pour délivrer des formations ou ateliers techniques et que nous sommes aussi impliqués dans des projets, que les Tech Leads ont des tâches administratives, etc. Le nombre d’incidents par ingénieur atteint régulièrement la quinzaine.
Voici donc brièvement décrit la mécanique mise en action au sein du support pour toujours améliorer l’expérience des clients autour de nos produits.
En espérant avoir levé un coin du voile… à très bientôt pour des bulletins plus techniques !
Chacun devrait le savoir, WSUS 2.0 SP1 ne sera plus supporté à partir de la fin Avril 2009, tout comme la version 3.0 (RTM = SP0). Reste donc WSUS 3.0 SP1 aussi appelé WSUS 3.1.
Plus d’informations sur la fin du support sur la page FAQ du produit : http://technet.microsoft.com/en-us/wsus/bb980625.aspx
Q. When does support end for WSUS 2.0?
A. Support for WSUS 2.0 has already ended. WSUS 2.0 SP1 support will end April 2009 (two years after WSUS 3.0 was released).
Nous allons voir comment procéder à la migration d’un serveur WSUS 2.0 vers WSUS 3.1
La migration vers WSUS 3.1 se fait en lieu et place de la version déjà installée contrairement au passage de SUS 1.0 vers WSUS 2.0. Sur le papier tout doit se faire sans problème, mais pour peu que votre WSUS ait un peu de vécu, on n’est pas à l’abris d’un petit problème. La procédure qui va suivre va nous permettre de faire l’opération de migration même en cas de pépin.
Tout d’abord, préparons le terrain en téléchargeant les prérequis et quelques outils qui pourront se réveler utiles !
Prérequis:
Outils supplémentaires:
Installons les 2 versions des “API Samples and Tools” et le WSUSMigrationImport dans le répertoire WSUSMigrate\WSUSMigrationImport des API v3 (cette version corrige le problème décrit dans l’article http://support.microsoft.com/kb/945348)
Par mesure de précaution, nous allons sauvegarder la base de données SQL sur laquelle est basé WSUS. Un simple backup des fichiers de la base avec NTBackup suffit. Les 2 fichiers à sauvegarder sont SUSDB.MDF et SUSDB_LOG.LDF. Cela permettra un retour arrière si nécessaire.
Sauvegarder vos paramètres de synchronisation (proxy, source des mises à jour, classifications, produits, langues …) sur le support de votre choix (papier, document word, capture écran)
Après la ceinture, les bretelles … Nous allons exporter les approbations et les groupes WSUS (les 2 sont liés) dans un fichier .xml, si jamais il fallait repartir d’une installation “from scratch” cela évitera de revalider les mises à jour une par une en rejouant automatiquement ces approbations. Lancer la commande suivante :
%Program Files%\Update Services API Samples and Tools\WSUSMigrate\WSUSMigrationExport\wsusmigrationExport groupapprobations.xml
Une fois l’export terminé, la migration en temps que telle peut commencer. La bonne pratique consiste à lancer le setup d’installation de WSUS 3.1 par la ligne de commande pour lui ajouter le paramètre /g (qui signifie : upGrade)
WSUSSetup_30SP1_x86.exe /g
La migration commence, et devrait normalement aboutir correctement. Sauf que la vie est parfois injuste et que le setup peut s’arrêter avant la fin. Dans ce cas, une installation propre ou “from scratch” est obligatoire. Désinstaller la version 2.0, le moteur de base de données si vous utilisez MSDE ou wMSDE car la version 3 est basée sur WIDB (Windows Internal DataBase). Garder seulement le “Content” ce qui épargnera le retéléchargement des binaires des mises à jour. Une fois le serveur débarassé de la version précédente, installer la version 3.1. A la fin de l’installation, l’assistant de configuration s’ouvre et vous demande de remplir les champs nécessaires à son fonctionnement (Proxy, Source des données, Classifications et Produits à synchroniser, Langues à prendre en charge …). Synchroniser le serveur afin de récupérer le catalogue des mises à jour que vous souhaitez déployer sur votre parc. Lorsque le serveur a fini sa synchronisation, que toutes les mises à jour de chacun des produits et des classifications sont bien présentes, vous pouvez alors réimporter les groupes et les approbations. Pour cela, utiliser la commande suivante (celle téléchargée sur Codeplex) :
%Program Files%\Update Services API Samples and Tools\WSUSMigrate\WSUSMigrationImport\wsusmigrationImport groupapprobations.xml All None
Lorsque la magie de la commande a fini d’opérer, vous avez un serveur WSUS 3.1 prêt à distribuer les mêmes mises à jour aux mêmes clients que votre ancien WSUS 2.
Les clients devront effectuer leur cycle de détection avant de réapparaitre dans la console. Au bout de 2 ou 3 jours, l’ensemble du parc devrait s’être réinscrit.
Le cas SQL Server 2005 …
Certains d’entre vous auront peut être effectué un déplacement de la base de données de WSUS vers la version complète de SQL afin de bénéficier des outils d’administration ou pour pouvoir déporter la base sur une autre machine.
Le guide d’opérations de WSUS décrit la marche à suivre (http://technet.microsoft.com/en-us/library/cc708558.aspx), sauf qu’il y a un petit manque. Cette démarche ne modifie pas les informations dans le registre et a pour conséquence de bloquer la migration de WSUS vers la version 3 (ou vers le SP1 pour ceux qui sont déjà en 3.0) . Le setup ne peut plus se connecter à la base de données avec ces informations. En modifiant les valeurs de registre suivantes sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup on peut rétablir la situation :
wMSDE
Windows Internal DataBase
SQL Server 2005 Local
SQL Server 2005 Remote
WmsedInstalled
wYukonInstalled
1
SqlInstanceIsRemote
Après avoir ajusté vos valeurs de registre, la migration doit s’effectuer correctement.
GaetanB – Windows Core Support Engineer
Nous allons analyser ensemble un dump relatif à des problème de crash réguliers sur un serveur de fichiers.
D’abord, regardons sur quel type de serveur le crash s’est produit :
0: kd> vertarget
Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp1_rtm.050324-1447
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af988
Debug session time: Tue Oct 21 02:22:03.749 2008 (GMT+2)
System Uptime: 6 days 7:23:43.156
Il s’agit donc d’un serveur 2003 en SP1, un premier plan d’action serait de le mettre à jour en SP2 :-)
D’autre part, le serveur semble avoir tourné pendant 6 jours avant la génération du dump.
Aussi, chaque crash ou stop est associé un code qui définie le type de problème rencontré, examinons le stop en question :
0: kd> .bugcheck
Bugcheck code 0000007F
Arguments 00000008 80042000 00000000 00000000
C’est un stop 7F avec le paramètre 00000008 ….intéressant !!
Les documents techniques qui détaillent ce type de stop, font référence à un problème de stack overflow :
“Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP
The UNEXPECTED_KERNEL_MODE_TRAP bug check has a value of 0x0000007F. This bug check indicates that the Intel CPU generated a trap and the kernel failed to catch this trap.
This trap could be a bound trap (a trap the kernel is not permitted to catch) or a double fault (a fault that occurred while processing an earlier fault, which always results in a system failure).
0x00000008, or Double Fault, indicates that an exception occurs during a call to the handler for a prior exception. Typically, the two exceptions are handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. There are two common causes of a double fault: A kernel stack overflow Or A hardware problem”
Ok, nous savons maintenant qu’il peut s’agir d’un stack overflow ..il va falloir se mettre sur le thread qui a causé le crash pour en savoir plus :
0: kd> .tss 0x28
eax=854b8300 ebx=854b8310 ecx=00000003 edx=89756000 esi=89fc3f30 edi=89756000
eip=bae30bf7 esp=f78f7f88 ebp=f78f81b8 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
q57xp32+0x9bf7:
bae30bf7 53 push ebx
0: kd> .thread
Implicit thread is now 8ab868d0
0: kd> !thread
THREAD 8ab868d0 Cid 0004.0048 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0
IRP List:
859c0370: (0006,0220) Flags: 00000010 Mdl: 00000000
85391008: (0006,0220) Flags: 00000884 Mdl: 00000000
8a02af68: (0006,0094) Flags: 00000000 Mdl: 00000000
Not impersonating
DeviceMap d6402818
Owning Process 8ab8a238 Image: System
Wait Start TickCount 34881482 Ticks: 0
Context Switch Count 21126271
UserTime 00:00:00.000
KernelTime 00:03:14.531
Start Address nt!ExpWorkerThread (0x8083f671)
Stack Init f78fb000 Current f78f9150 Base f78fb000 Limit f78f8000 Call 0
Priority 12 BasePriority 12 PriorityDecrement 0
ChildEBP RetAddr Args to Child
00000000 bae30bf7 00000000 00000000 00000000 nt!_KiTrap08+0x75 (FPO: TSS 28:0)
WARNING: Stack unwind information not available. Following frames may be wrong.
f78f81b8 bae29c53 89756000 89fc3f30 8975bf54 q57xp32+0x9bf7
f78f8200 bae29edb 854b8310 f78f8278 f78f8248 q57xp32+0x2c53
f78f8210 bae2a199 02756000 878032e0 897ef950 q57xp32+0x2edb
f78f8248 f76ee804 00000001 f78f8278 00000000 q57xp32+0x3199
f78f8260 80a7a24f 897ef850 00000000 86e62a20 NDIS!ndisMProcessSGList+0x90
f78f828c f76ee6fe 86e62a20 897ef850 878032c0 hal!HalBuildScatterGatherList+0x1c7
f78f82e4 f76d249d 8a3d5008 854b8310 862fe230 NDIS!ndisMAllocSGList+0xd9
f78f8300 ba782f37 89e90290 854b8310 89d16c48 NDIS!ndisMSendX+0x1a0
f78f8328 ba78223a 8a3d5008 854b8310 8638eae8 tcpip!IPRcvComplete+0x12d3
f78f8350 ba782622 8638ea02 f78f8402 00000001 tcpip!IPRcvComplete+0x5d6
f78f848c ba783c01 ba7bbbb8 862fe2a4 862fe230 tcpip!IPRcvComplete+0x9be
f78f84fc ba783da0 f3b3f555 00000002 875d30c0 tcpip!IPRcvComplete+0x1f9d
f78f8524 ba784478 00000001 00000000 00000002 tcpip!IPRcvComplete+0x213c
f78f8558 bab209ac 875d3008 89443364 89d2d540 tcpip!IPRcvComplete+0x2814
f78f857c bab29a46 89e8e000 89429058 89e8e000 msiscsi+0x99ac
f78f8624 bab2c101 01429058 84f25502 84f2552c msiscsi+0x12a46
f78f8644 bab1a435 808a5180 84f25502 00000000 msiscsi+0x15101
f78f866c bab036ca 8a02b65c 89e8e000 f78f8698 msiscsi+0x3435
f78f867c bab03afc 897c31a0 84f2552c 884b7d28 iscsiprt!RaCallMiniportStartIo+0x1e
f78f8698 bab0c182 84f2552c 870a48a0 89d17e18 iscsiprt!RaidAdapterPostScatterGatherExecute+0x5e
f78f86b8 bab07823 00000000 00000001 00000000 iscsiprt!RaUnitStartIo+0xc4
f78f86d8 bab0b575 89d17e18 014b7d28 00000000 iscsiprt!RaidStartIoPacket+0x49
f78f86fc bab0c8a6 89d17d30 884b7d28 84c6d270 iscsiprt!RaidUnitSubmitRequest+0x63
f78f8718 bab06844 89d17d30 884b7d28 f78f873c iscsiprt!RaUnitScsiIrp+0x92
f78f8728 8083f9d0 89d17c78 884b7d28 89e8caa0 iscsiprt!RaDriverScsiIrp+0x2a
f78f873c f7409440 884b7d28 884b7dfc 884b7d28 nt!IofCallDriver+0x45
f78f8764 f74094e0 89cfba88 884b7d28 884b7d28 mpio!MPIOReadWrite+0x19e
f78f8830 f7409b34 89cfba88 84c6d1f0 884b7dd8 mpio!MPIOPdoHandleRequest+0x76
f78f8848 f7408945 89cfbb40 884b7d28 884b7d28 mpio!MPIOPdoInternalDeviceControl+0x3c
f78f8870 f740916f 89cfba88 89cfbd78 01000000 mpio!MPIOPdoCommonDeviceControl+0x1fb
f78f8890 f74062ef 89cfba88 884b7d28 f78f88b4 mpio!MPIOPdoDispatch+0x8f
f78f88a0 8083f9d0 89cfba88 884b7d28 84f25480 mpio!MPIOGlobalDispatch+0x19
f78f88b4 f7139a20 84f25480 68d0e000 f78f88f8 nt!IofCallDriver+0x45
f78f88c4 f7139635 84f25480 89419b70 85a52e2c CLASSPNP!SubmitTransferPacket+0xbb
f78f88f8 f7139712 00000000 00001000 85a52e50 CLASSPNP!ServiceTransferRequest+0x1e4
f78f891c 8083f9d0 89419ab8 00000000 8ab96b38 CLASSPNP!ClassReadWrite+0x159
f78f8930 f74d80cf 8756c3a8 85a52e50 f78f8954 nt!IofCallDriver+0x45
f78f8940 8083f9d0 893e7780 85a52cc0 85a52cc0 PartMgr+0x10cf
f78f8954 f73b4802 890bd008 8756c3a8 89595d08 nt!IofCallDriver+0x45
La, il n’y a pas de doute, nous somme bien en présence d’un beau “stack overflow”.
En effet, chaque thread a le droit à un espace limité pour gérer la stack.
Ici la limite est à f78fb000 (on commence la stack à à l’adresse f78f8000 ) : Stack Init f78fb000 Current f78f9150 Base f78fb000 Limit f78f8000
Le dernier appel a été fait à l’adresse f78f81b8 ; par conséquent l’appel d’après aurait utiliser de la mémoire et dépasser ainsi la limite du f78f8000 d’où le stack overflow et le crash.
Voici les détails de consommation de la stack au moment du Stop:
Module Stack Usage Percentage
fltMgr 280 2
volsnap 584 5
Ntfs 4844 42
iscsiprt 188 2
NDIS 140 1
msiscsi 276 2
q57xp32 144 1
CLASSPNP 104 1
mfetdik 144 1
hal 44 0
dmio 328 3
tcpip 600 5
mpio 356 3
PartMgr 16 0
mfehidk 660 6
nt 1988 17
df2k 848 7
Nous constatons que Ntfs utilise 42% de celle-ci ce qui est beaucoup. Maintenant si l’on regarde attentivement la stack nous allons constater que c’est le driver df2k.sys qui est réentrant dans le file system.
0: kd> kv 100
00000000 bae30bf7 00000000 00000000 00000000 nt!_KiTrap08+0x75
f78f899c f73cdfa3 8756c3a8 010bd008 04000000 dmio!voldiskiostart+0x482
f78f89ec f73bf8dc 8756c3a8 f78f8a44 f78f8a38 dmio!vol_subdisksio_start+0x107
f78f8a5c f73b5e2c 8712c408 00000001 00000001 dmio!volkiostart+0x32c
f78f8a88 f73b85e2 88dc1a60 85a52cc0 8ab50418 dmio!volrdwr+0xa0
f78f8a9c 8083f9d0 88dc1a60 85a52cc0 85a52e98 dmio!volread+0x58
f78f8ab0 f73899c4 8ab2d248 88db7af0 88d246d0 nt!IofCallDriver+0x45
f78f8ac8 8083f9d0 88d246d0 85a52cc0 85a52cc0 volsnap+0x19c4
f78f8adc f70d9881 88db7a38 88db7af0 88ba5c98 nt!IofCallDriver+0x45
f78f8b34 f70dae17 88db7a38 85a52cc0 85a52cc0 df2k+0x6881
f78f8b5c f701d0ce f78f8e40 f78f8d40 f701c702 df2k+0x7e17
f78f8b68 f701c702 f78f8e40 88db7a38 9c09a000 Ntfs!NtfsSingleAsync+0x91
f78f8d40 f701a75e f78f8e40 85a52cc0 88ba5c98 Ntfs!NtfsNonCachedIo+0x2db
f78f8e2c f701d8de f78f8e40 85a52cc0 00000001 Ntfs!NtfsCommonRead+0xaf5
f78f8fd8 8083f9d0 88be6718 85a52cc0 85a52cc0 Ntfs!NtfsFsdRead+0x113
f78f8fec f7117b43 88f2aae8 85a52cc0 88eeb008 nt!IofCallDriver+0x45
f78f9010 f7117d03 f78f9030 88f2aae8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f78f9048 8083f9d0 88f2aae8 85a52cc0 88db7af0 fltMgr!FltpDispatch+0x11f
f78f905c f70d8ab1 89944588 89944640 88fcd5c0 nt!IofCallDriver+0x45
f78f9100 f70dae17 89944588 85a52cc0 85a52ebc df2k+0x5ab1
f78f9128 ba9efa40 88d1da08 89705218 88bed008 df2k+0x7e17
f78f913c 8083f9d0 88aacf10 85a52cc0 85a52cc0 SYMEVENT!SYMEvent_AllocVMData+0x5f00
f78f9150 f7117d36 0010e000 8a0d1768 00000000 nt!IofCallDriver+0x45
f78f917c 8083f9d0 88d1da08 85a52cc0 85a52cc0 fltMgr!FltpDispatch+0x152
f78f9190 8082f0de 83e86308 8ab868d0 83e862f8 nt!IofCallDriver+0x45
f78f91a8 8082f17c 88f04f0c 83e86330 83e86310 nt!IoPageRead+0x109
f78f922c 80849ce5 00000001 c16ce000 c0305b38 nt!MiDispatchFault+0xd2a
f78f9288 8082fd4f 00000000 c16ce000 00000000 nt!MmAccessFault+0x64a
f78f92b8 80845b53 c16ce000 00000000 f78f93e4 nt!MmCheckCachedPageState+0x48e
f78f9300 80845d5a 88ba5b60 f78f9340 00001000 nt!CcMapAndRead+0x93
f78f9394 8092f599 88f04f90 f78f93d4 00001000 nt!CcPinFileData+0x24a
f78f9408 f7054d25 88f04f90 f78f9440 00001000 nt!CcPinRead+0xc4
f78f9430 f704842b 84f7a168 88ba5c98 0010e000 Ntfs!NtfsPinStream+0x76
f78f945c f7049751 84f7a168 88be67f8 00870000 Ntfs!NtfsMapOrPinPageInBitmap+0x9d
f78f94d8 f704851f 84f7a168 88be67f8 0087312e Ntfs!NtfsAllocateBitmapRun+0x4b
f78f9614 f7040136 84f7a168 88be67f8 87342a00 Ntfs!NtfsAllocateClusters+0x9fd
f78f96d4 f7047e53 84f7a168 87342a00 00000020 Ntfs!NtfsAllocateAttribute+0x156
f78f9774 f704835c 84f7a168 d6650468 00000020 Ntfs!NtfsCreateNonresidentWithValue+0xde
f78f9874 f706e627 84f7a168 d6650468 d1911898 Ntfs!NtfsConvertToNonresident+0x2ec
f78f99cc f7076cc4 84f7a168 d6650468 00000240 Ntfs!NtfsChangeAttributeValue+0x467
f78f9ab8 f7071d04 84f7a168 d6650468 000fe6ad Ntfs!NtfsAddToAttributeList+0x177
f78f9ca0 f7047a50 84f7a168 d6650530 f78f9cd0 Ntfs!NtfsAddAttributeAllocation+0xf71
f78f9d64 f70845ef 84f7a168 8523cc68 d6650530 Ntfs!NtfsAddAllocation+0x397
f78f9e74 f7041c94 84f7a168 8523cc68 859c0370 Ntfs!NtfsSetAllocationInfo+0x3dd
f78f9ee0 f701d2fb 84f7a168 859c0370 00000000 Ntfs!NtfsCommonSetInformation+0x48c
f78f9f48 8083f9d0 88be6718 859c0370 859c0370 Ntfs!NtfsFsdSetInformation+0xa3
f78f9f5c f7117b43 88f2aae8 859c0370 88eeb008 nt!IofCallDriver+0x45
f78f9f80 f7117d03 f78f9fa0 88f2aae8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f78f9fb8 8083f9d0 88f2aae8 859c0370 88db7af0 fltMgr!FltpDispatch+0x11f
f78f9fcc f70d8ab1 89944588 89944640 f78fa0e8 nt!IofCallDriver+0x45
f78fa070 f70dae17 89944588 859c0370 859c056c df2k+0x5ab1
f78fa098 ba9ef7b1 859c056c 859c0590 f78fa0e8 df2k+0x7e17
f78fa0b0 ba9f8d68 89944588 00000000 f78fa0e8 SYMEVENT!SYMEvent_AllocVMData+0x5c71
f78fa0cc ba9ef91b f78fa0e8 8082b0b9 ba9ef9e3 SYMEVENT!EventObjectCreate+0xba8
f78fa10c 8083f9d0 88aacf10 859c0370 859c0370 SYMEVENT!SYMEvent_AllocVMData+0x5ddb
f78fa120 f7117b43 88d1da08 859c0370 88bed008 nt!IofCallDriver+0x45
f78fa144 f7117d03 f78fa164 88d1da08 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f78fa17c 8083f9d0 88d1da08 859c0370 859c0370 fltMgr!FltpDispatch+0x11f
f78fa190 8098911f 85391008 84c497a0 f78fa434 nt!IofCallDriver+0x45
f78fa1c8 f707e07c 0123cc68 00000013 85391018 nt!IoSetInformation+0x1c2
f78fa1f4 f706c7b7 84c497a0 85391008 d66506b8 Ntfs!NtfsCompleteLargeAllocation+0x40
f78fa3f4 f70531e5 84c497a0 85391008 f78fa434 Ntfs!NtfsCommonCreate+0x1472
f78fa4f8 8083f9d0 88be6718 85391008 85391008 Ntfs!NtfsFsdCreate+0x17d
f78fa50c f7117b43 00000000 85391008 85391198 nt!IofCallDriver+0x45
f78fa530 f71255af f78fa550 88f2aae8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f78fa56c 8083f9d0 88f2aae8 85391008 853911d8 fltMgr!FltpCreate+0x23b
f78fa580 f70da51c 8081fd79 899446b0 899446f4 nt!IofCallDriver+0x45
f78fa5b0 f70d942b 899446b0 85391008 00000000 df2k+0x751c
f78fa5e4 f70d8fed 89944640 85391008 89944588 df2k+0x642b
f78fa690 f70dae17 89944588 85391008 853911e0 df2k+0x5fed
f78fa6b8 ba9ef8a1 853911e0 85391204 f78fa718 df2k+0x7e17
f78fa6e0 ba9f8d58 89944588 00000000 f78fa718 SYMEVENT!SYMEvent_AllocVMData+0x5d61
f78fa6fc ba9ef91b f78fa718 8082b0b9 ba9ef9e3 SYMEVENT!EventObjectCreate+0xb98
f78fa73c 8083f9d0 88aacf10 85391008 85391008 SYMEVENT!SYMEvent_AllocVMData+0x5ddb
f78fa750 f7117b43 00000000 85391008 85391204 nt!IofCallDriver+0x45
f78fa774 f71255af f78fa794 88d1da08 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b
f78fa7b0 8083f9d0 88d1da08 85391008 85391008 fltMgr!FltpCreate+0x23b
f78fa7c4 8092e269 f78fa96c 88dc1a48 00000000 nt!IofCallDriver+0x45
f78fa8ac 80936caa 88dc1a60 00000000 88e62860 nt!IopParseDevice+0xa35
f78fa92c 80936aa5 00000000 f78fa96c 00000240 nt!ObpLookupObjectName+0x5a9
f78fa980 80936f27 00000000 00000000 00000100 nt!ObOpenObjectByName+0xea
f78fa9fc 80936ff8 8a2f22e4 0012019f f78fab7c nt!IopCreateFile+0x447
f78faa58 8092ed98 8a2f22e4 0012019f f78fab7c nt!IoCreateFile+0xa3
f78faa98 80834d3f 8a2f22e4 0012019f f78fab7c nt!NtCreateFile+0x30
f78faa98 8083c1ec 8a2f22e4 0012019f f78fab7c nt!KiFastCallEntry+0xfc
f78fab3c f7396acb 8a2f22e4 0012019f f78fab7c nt!ZwCreateFile+0x11
f78fabc4 f739c6f7 8a2f22d0 00000001 f78fabec volsnap+0xeacb
f78fabf8 f73a5d5d 86a966e0 12c00000 00000000 volsnap+0x146f7
f78fad50 f73945e5 8aa020d8 851a5798 8ab868d0 volsnap+0x1dd5d
f78fad6c 809180a0 875603d0 88eb2ab8 808b70dc volsnap+0xc5e5
f78fad80 8083f72e 875603d0 00000000 8ab868d0 nt!IopProcessWorkItem+0x13
f78fadac 8092ccff 875603d0 00000000 00000000 nt!ExpWorkerThread+0xeb
f78faddc 80841a96 8083f671 00000001 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
La stack contient aussi plusieurs occurrences du module SYMEVENT qui est connu pour causer des problèmes de stack overflow
La solution au problème rencontré passera par:
- Désinstallation ou mise à jour du composant Df2K.sys
- Suivi des recommandations de Symantec pour la partie Symevent : http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2002071208532048?Open&src=w
Mounia
Windows Core Technical Lead
Travaillons aujourd’hui sur un autre scénario assez simple : Celui de la suppression accidentelle d’une partition.
Supposons que cette partition
soit devenue
Comme d’habitude, on contrôle les secteurs habituels et on voit celui qui pourrait manquer.
Au secteur 0, on a un MBR montrant une partition GPT qui occupe tout le disque
Au secteur 1, on retrouve un GPT Header :
Données:
Et le secteur 266338303 montre la même chose.
Le secteur 2 nous montre une table de partitions ne contenant que la partition MSR (comme quoi, rien n’est perdu), et le secteur 266338271 (Last usable +1) nous montre la même chose.
Allons donc voir si une partition NTFS pourrait trainer sur le disque.
Comme la partition MSR finit au secteur 262177, on devrait en trouver une plus loin, en principe aligné sur 64KB.
C’est au secteur 264192 que nous allons la trouver
Total Sectors : 266072063 (~126.8 GB) : Le secteur de fin devrait se trouver 266336255 ( = 266072063 + 264192 )
Clusters to MFT / MFTMirr : 786432 (LBA 6555648 = 264192 + 8*786432 ) / 2 (LBA 264208 = 264192 + 8*2)
Et ce sont bien des entrées de MFT que l’on trouve à ces secteurs:
Résumons-nous :
En principe, comme pour une partition MBR :
Quand vient le moment de formater, ne pas formater.
A ce moment-là, le secteur 264192 a été vidé de son contenu (puisque nous n’avons pas fourni de file system)
En écrasant ce secteur par celui que nous avons sauvegardé, c’est comme si nous formatons la partition.
DskProbe.exe permet d’écraser un secteur du disque.
Après vérification rapide (secteur de fin de partition, MFT, MFTMirr) un rescan du disque fait revenir la partition comme par magie.
ALERTE performance : la classe Win32_OperatingSystem !
La classe WMI Win32_OperatingSystem est très populaire (à juste titre) chez les administrateurs système. Elle est fréquemment utilisée par exemple pour exécuter des actions spécifiques ou appliquer des stratégies de groupes (GPO) spécifiques à une version de Windows.
Cette classe (cf http://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx ) semble bien anodine et ne « collecte » que des « informations statiques » .
C’est sans compter avec le champ NumberOfProcesses !
NumberOfProcesses
Data type: uint32
Access type: Read-only
Number of process contexts currently loaded or running on the operating system.
Pour déterminer la valeur de NumberOfProcesses, le provider WMI fait lui-même une requête WMI « SELECT __RELPATH FROM Win32_Process » qui charge considérablement le système.
Par exemple sur un « large serveur » RDS/Citrix avec :
Plusieurs GPOs ayant un filtre du type :Select * FROM Win32_OperatingSystem WHERE Version like '6.3%'
De scripts de logon avec des « select * Win32_OperatingSystem »
Des « brokers » ou des outils de monitoring exécutant des « Select * from Win32_Process »
De nombreux « logon »
Vous observerez rapidement :
une forte consommation CPU dans le process WMIPRVSE
des temps de « logon » important
une forte contention « kernel » liée à l’énumération des processus qui peut avoir des conséquences diverses et variées (lenteur lors du lancement du gestionnaire de tâches,…)
La solution est de limiter les champs retournés par la requête WQL. Le provider de la classe Win32_OperatingSystem ne collecte alors que les infos demandées. La requête « select Version from Win32_OperatingSystem » n’énumère pas la liste des processus.
Tip :
L’activation du tracing « WMI-Activity » (http://msdn.microsoft.com/en-us/library/aa826686(v=vs.85).aspx) permet d’identifier ce type de problème.
[10/17 03:46:47.0051 PM] [wbemtest.exe] [201c.1f84] ExecQuery: select * from win32_operatingsystem
[10/17 03:46:47.0401 PM] [wmiprvse.exe] [12a0.15d4] ExecQuery: references of {__Win32Provider.Name="CIMWin32"}
[10/17 03:46:47.0578 PM] [wmiprvse.exe] [12a0.15d4] ExecQuery: SELECT __RELPATH FROM Win32_Process
Dans le cadre du déploiement de systèmes Windows, il vous est peut-être arrivé d’utiliser un média bootable (CD-ROM, DVD) contenant votre image de référence incluant elle-même toutes les applications que vous utilisez dans votre environnement.
Vous aurez remarqué que plus Windows et les applications (quelles qu’elles soient) évoluent et plus l’espace nécessaire pour stocker cette image est important.
Dans ce cas de figure il peut arriver que l’image (ou les images) dépassent les 4GB, entrainant une impossibilité de démarrer sur ce média.
Ceci concerne les médias de démarrage construits avec WinPE 2.x et oscdimg (fourni avec le WAIK) et l’erreur se concrétise par le message suivant lors des tentatives de démarrage :
File: \Boot\BCD Status: 0xc000014c Info: An error occurred while attempting to read the boot configuration data.
File: \Boot\BCD
Status: 0xc000014c
Info: An error occurred while attempting to read the boot configuration data.
Cette erreur peut survenir si les fichiers requis pour le démarrage sont situés au delà des 4 premiers Giga Octets sur le DVD.
La partie bootable de WinPE doit être dans les 4 premiers Go du DVD.
Il est nécessaire d'ordonner la façon dont les fichiers sont placés sur le media afin que les fichiers critiques pour le boot se trouvent au dessus du reste des données. Avec 4, 7 GO, les fichiers de boot ne sont pas disponibles assez tôt dans l'ISO et on obtient l'erreur ci-dessus.
OSCDIMG -m -n -yoC:\TEMP\bootorder.txt -bC:\WINPE_X86\etfsboot.com C:\WINPE_X86\ISO C:\TEMP\WINPE.ISO
où :
Exemple de fichier BOOTORDER.TXT :
bootmgr boot\bcd boot\boot.sdi boot\bootfix.bin boot\bootsect.exe boot\etfsboot.com boot\memtest.efi boot\memtest.exe boot\en-us\bootsect.exe.mui boot\fonts\chs_boot.ttf boot\fonts\cht_boot.ttf boot\fonts\jpn_boot.ttf boot\fonts\kor_boot.ttf boot\fonts\wgl4_boot.ttf sources\boot.wim
Une fois le fichier ISO généré, vous pouvez le graver à l’aide de DVDBURN.EXE (inclus dans le Resource Kit de Windows Server 2003).
Note : OSCDIMG et DVDBURN sont les seuls outils permettant de générer des fichiers ISO bootables et de les graver sur des médias de manière supportée par Microsoft.
Liens complémentaires:
http://technet.microsoft.com/en-us/library/cc749036.aspx
Laetitia
Technical Lead
Problématique
En complément de cet article Technet Comment créer un Windows PE 2.x Multiboot 32 et 64 bit, je souhaiterais vous proposer un autre post permettant par exemple, un multiboot entre votre OS de production et WinPe
Objectif
En plus d'être un outil de déploiement, WinPe est aussi un outil de "récupération".
En proposant une solution de démarrage parallèle, vous pouvez par la suite essayer de recopier des fichiers manquant ou défectueux, lancer un Chkdsk, modifier la base de registre, ou, dans le pire des cas, redescendre directement un master.
Prérequis
Les prérequis sont les même que dans l'article technet Comment créer un Windows PE 2.x Multiboot 32 et 64 bit
Procédure
Imaginons le scénario suivant:
Attention : la manipulation ci-après va mettre à jour/modifier la séquence de démarrage de votre serveur vers une séquence Windows Vista/Server 2008/Seven
La séquence passe donc de :
Attention-2: (Le retour)
Note : c'est un peu lourd mais ça a son importance pour la suite. Vous pouvez consulter les informations sur ces secteurs en utilisant un outil comme DskProbe
Après ces petites remarques, voici donc les commandes qui peuvent être réutilisées dans un batch:
Le résultat devrait être le suivant:
Vincar (pour les intimes) Windows Core Support Engineer
A l’occasion des Microsoft TechDays 2010, nous aurons le grand plaisir de présenter une session technique traitant des meilleurs pratiques et de notre retour d’expérience sur la technologie cluster.
Au menu, entre autres sujets, les nouveautés de Windows Server 2008 R2, comment mettre à jour votre cluster de Windows Server 2003 ou 2008 à Windows Server 2008 R2, comprendre l’outil de validation, les actions proactives à mettre en oeuvre pour assurer la stabilité du cluster, etc…
Le teaser :
Meilleures pratiques et retour d'expérience sur le cluster de basculement (Failover Clustering)
Le choix de la mise en place d'un cluster est guidé par le besoin de haute disponibilité mais il ne faut pas se laisser tromper par son apparente simplicité. Les ingénieurs support sont les premiers impliqués dans la gestion des incidents cluster. Venez profiter de notre retour d'expérience et de nos conseils concernant les bonnes pratiques et recommandations concernant la mise en place, le geo-clustering, l'upgrade ou l'exploitation d'une plateforme en cluster.
Nous serons pas moins de trois sur scène pour vous présenter cette session qui fait partie du parcours Windows 7 & Windows Server 2008 R2.
Suite au bulletin identifiant après quelques mois les incidents le plus souvent rencontrés avec Hyper-V, voici le premier bulletin présentant les meilleurs pratiques a adopter afin d’optimiser la mise en place de Hyper-V.
Certains comportements, peut-être liées au côté parfois un peu intrusif des anti-virus (ou au côté parfois un peu protecteur des mécanismes Windows), peuvent avoir pour conséquences certains dysfonctionnements comme ceux-ci :
Dans ces cas de figure, nous recommandons d’ajouter des exclusions au scan temps-réel des anti-virus installés sur les hôtes.
Exclure :
Vous retrouverez l'intégralité de l'article technique à l'adresse suivante : http://support.microsoft.com/kb/961804
Pour de plus amples informations, je vous propose de vous inscrire pour assister à la JTE du 31 mars prochain :
http://blogs.technet.com/windowsinternals/archive/2008/12/18/journ-e-technique-d-expertise-th-matique-windows-server-2008.aspx
Raphael
Windows Core Support Engineer