Applications et services cruciaux

Par exemple, validez toutes les stratégies d’audit et
activez debug logging dans DNS, RRAS, Certificate Services,
SQL Server et Exchange Server. Il faut activer ce logging afin
que, si un patch détruit quelque chose, vous disposiez de
journaux d’audit utilisables pour détecter et diagnostiquer le
problème.
Pour écrire l’information de Stratégie de Groupe complète
dans le log Application, mettez à  1 la valeur REG_
DWORD nommée RunDiagnosticLoggingGroupPolicy sous
la sous-clé de registre HKEY_LOCAL_MACHINE\SOFTWAREMicrosoft\Windows NT\CurrentVersion\Diagnostics (il
vous faudra probablement créer à  la fois la valeur et la sousclé
Diagnostics) comme l’explique le white paper Microsoft
« Troubleshooting Group Policy in Windows 2000 » (http://
www.microsoft.com/windows2000/docs/gptshoot.doc) Si
vous devez journaliser des informations Stratégie de Groupe
plus détaillées, vous pouvez aussi valider le logging de l’environnement
utilisateur, comme le décrit l’article Microsoft
« How to Enable User Environment Debug Logging in Retail
Builds of Windows » (http://support.microsoft.com/?kbid=
221833).
Après avoir validé le logging sur tous ces
services, vérifiez les journaux pour voir si
tout se passe bien puis effacez les journaux
et appliquez vos patches. Il existe un moyen
rapide d’effacer un fichier log de texte (pas
un journal d’événements) ou de créer un fichier
de texte vierge : en exécutant la commande

echo 1>nul 2>c:\logfile.txt

dans laquelle 1>nul redirige la sortie standard
de la commande Echo vers rien et 2>c:\logile.txt redirige
la sortie d’erreur standard vers le fichier spécifié, en
écrasant son contenu s’il existe déjà  ou en créant le fichier s’il
n’existe pas.
Pour effacer les journaux d’événements Windows, utilisez
un fichier batch pour exécuter les commandes

cscript.exe ClearEventLog.vbs
127.0.0.1 Application
cscript.exe ClearEventLog.vbs
127.0.0.1 Security
cscript.exe ClearEventLog.vbs
127.0.0.1 System

pour invoquer ClearEventLog.vbs que montre le listing
Web 2. Le premier argument dans chaque commande est
l’adresse IP ou le nom de l’ordinateur (local ou distant) dont
vous voulez effacer le journal d’événements, et le second argument
est le nom du journal. Si vous avez des journaux
d’événements pour DNS, AD, ou autres services, effacez-les
aussi.Après avoir effacé les journaux, vous pouvez installer les
patches sur les machines de test et commencer à  exécuter les
applications en poussant les services pour essayer de causer
des erreurs. Appliquez toutes les fonctions que les utilisateurs
invoquent dans leur travail, en mettant l’accent sur
celles qui concernent le réseau, l’impression, les commandes
de sécurité, l’accès au système de fichiers, et tout ce qui
pourrait tomber en panne (d’après l’expérience passée).
Ainsi, vous pourriez écrire un fichier batch chargé d’exécuter
la commande

winword.exe C:\file.doc

pour lancer Microsoft Word et faire ouvrir file.doc à  l’application.
Dans file.doc, créez une macro nommée AutoOpen
qui imprime le document sur une imprimante distante, sauvegardez
une copie du fichier dans un dossier partagé ou
WebDAV (Web Distribited Authoring and Versioning), rendez
le document dans un fichier .pdf Adobe Acrobat d’Adobe
Systems et ainsi de suite. Le fait de nommer la macro
AutoOpen oblige Word à  l’exécuter quand Word ouvre le fichier
qui la contient. La création des macros Microsoft Office
ne demande généralement pas de programmation. Par
exemple, dans Word XP et Word 2000, sélectionnez Macro
dans le menu Tools (Outils), sélectionnez Record New Macro
(Nouvelle macro), nommez la macro AutoOpen, stockez-la
dans le document courant (pas dans le template) puis effectuez
les tâches voulues. Word enregistrera vos frappes et vos
clics de souris. Dans Microsoft Excel XP et Excel 2000, nommez
la macro Auto_Open pour qu’Excel l’exécute quand l’application
ouvrira le fichier qui contient la macro. Vérifiez si
vos applications non Microsoft ont des fonctions d’automatisation
similaires.
Découvrez quels arguments ligne de commande vos
applications supportent et utilisez-les au maximum dans vos
fichiers batch. Certaines applications confient beaucoup de leurs fonctionnalités à  des commutateurs ligne de commande.
Mais même si vous devez tester une fonction qui ne
peut être entrée qu’à  la main dans une interface graphique,
tout n’est pas perdu. Le script keystrokes.vbs que montre le
listing Web 3 montre comment utiliser la matériel Send-
Keys() pour envoyer des frappes à  une application graphique.
Faites attention aux commandes que vous tapez
pendant le test d’un programme GUI – n’oubliez pas que la
touche Alt peut servir pour dérouler des menus – puis faites
entrer les mêmes commandes par votre script.
Comme on le voit dans keystrokes.vbs, la méthode
AppActivate(« App Title ») donne à  l’application avec App Title
dans sa barre de titre, la focalisation d’entrée pour que la
bonne application reçoive bien les frappes du script. La méthode
Sleep(Milliseconds) aide l’application à  rester au niveau
du script, en faisant attendre le script pendant le
nombre de millisecondes spécifié avant de poursuivre l’exécution.
Les commentaires dans keystrokes.vbs indiquent les
frappes pour les touches et combinaisons de touches spéciales
et utilisées fréquemment. Avec un peu de débogage
par essais successifs, vous pourrez faire fonctionner la plupart
des applications graphiques sans intervention manuelle.
Vous pouvez utiliser d’autres scripts
pour pousser les services à  distance. Pour
cela, exécutez une application sur des systèmes
distants en interaction avec le service
à  tester sur la machine cible du lab. Pour
consulter la liste alphabétique des outils
disponibles et leur description, voir les fichiers
Help qui accompagnent les kits de
ressources Microsoft et Support Tools. Pour
tester des serveurs IIS, étudiez les simulateurs
de charge tels que ACT (Application
Center Test) que décrit l’article Microsoft
« INFO: Application Center Test (ACT) Tests Your Web
Applications by Simulating Load », http://support.microsoft.
com/?kbid=307492).
Quand vous exécuterez vos fichiers batch et d’autres
scripts pour mettre vos services à  l’épreuve, certaines erreurs
seront faciles à  déceler : comme un écran mort ou un
pointeur de souris figé. Mais certains services défectueux se
contenteront d’enregistrer en silence leurs erreurs dans un
ou plusieurs de vos journaux. Examiner ces derniers manuellement
n’est pas pratique : c’est fastidieux et le risque
d’erreur est grand. Il vaut mieux explorer les journaux avec
des outils ou des scripts capables d’extraire des erreurs, des
avertissements, et autres symptômes intéressants.
Les journaux de fichiers de texte sont les plus faciles à 
explorer. L’utilitaire Windows findstr.exe extrait des fichiers
les lignes qui correspondent aux modèles que vous avez
indiqués, y compris des expressions ordinaires basiques.
Pour commencez, examinez les journaux de texte généralement
produits par le service que vous testez et identifiez
toutes les chaînes (comme Fail, Error, or 500) qui indiquent
des problèmes. Sauvegardez ces chaînes, à  raison d’une par
ligne, dans un fichier de texte nommé signatures.txt. (Vous
aurez un fichier de signatures séparé pour chaque type de
journal que vous explorez régulièrement.) Puis, utilisez la
commande

findstr.exe /g:signatures.txt
logfile.log > output.txt

pour rechercher dans un journal de texte toutes les lignes
qui ont au moins un de ces profils et les rediriger vers un fichier
de sortie. Si le fichier output.txt dépasse 0 octet, vous
aurez un hit et vous devrez analyser le problème. Pour plus
d’informations sur findstr.exe, voir la Command Line
Reference dans l’aide Windows. Pour un tutoriel des expressions
normales (regular expressions) et des outils beaucoup
plus puissants et conviviaux que findstr.exe, allez à 
http://www.regular-expressions.info/tutorial.html.
Convertissez les journaux d’événements Windows binaires
en texte clair et recherchez-les aussi avec findstr.exe.
L’utilitaire dumpel.exe du Microsoft Windows 2000 Resource
Kit convertit les données des journaux d’événements en
texte délimité par des tabulations, que vous pouvez ensuite
canaliser dans findstr.exe. Par exemple, dumplog.bat, que
montre le listing Web 4, contient les commandes pour n’extraire
que les messages d’erreur et d’avertissement des journaux
Application et System et que les défaillances d’audit du
journal Security. Le commutateur /R dans le script indique
que la chaîne de recherche d’aspect bizarre est une expression
normale. Vous pouvez aussi utiliser EventQuery.vbs de
XP pour n’obtenir que les erreurs et les avertissements, ou
simplement les audits de défaillance, comme le montre le listing
Web 5. Sachez que si vous validez le logging de débogage
Stratégie de Groupe (comme je l’ai mentionné précédemment), vous risquez d’obtenir beaucoup d’événements d’erreur
en provenance du source Userenv dans le journal
Application, aussi il vaut mieux mettre debug logging sur off
ou au moins filtrer ces entrées. Pensez aussi à  changer votre
WSH (Windows Script Host) par défaut de wscript.exe en cscript.
exe quand vous travaillez beaucoup dans les fenêtres de
commande. Pour cela, tapez la commande

cscript.exe //h:cscript
//nologo //s