Assembler les éléments du script

concentre sur sa mise en place. Dès que la version locale du script fonctionne, je me sers de ce code pour traiter d’autres scénarios de capture. Vous trouverez ci-dessus le format de syntaxe de base de DesktopDiag.bat. Il contient une ligne d’en-tête suivie d’une ligne vierge, puis inclut la sortie d’une commande ou utilitaire suivie d’une ligne vierge.

Les doubles caractères de redirection (>>) envoient la sortie à un fichier dans un mode append. S’il n’existe pas déjà, le fichier est créé. S’il existe, l’information est ajoutée à la fin du fichier. Un simple caractère de redirection (c’est-àdire, >) crée un fichier, en écrasant les anciennes données qui pouvaient se trouver dans un fichier de même nom. La syntaxe de base suivante est utilisée pour les 14 utilitaires et commandes intégrées que j’ai identifiées :

ECHO ********** Title Information Line **********>>"%file%"
ECHO.>>"%file%" C:\UtilLoc\ToolName.exe >>"%file%"
ECHO.>> "%file%"

Le listing 1 montre comment la syntaxe est mise en oeuvre dans un script avec l’outil Gpresult.exe du Microsoft Windows 2000 Resource Kit.

Pour traiter le deuxième scénario de capture, Desktop-Diag.exe extrait les données d’une machine distante. Heureusement, nous ne sommes plus au temps où la plupart des commandes et des outils ne fonctionnaient que localement. La fonctionnalité distante intégrée d’outils tels que Srvinfo.exe du Microsoft Windows Server 2003 Resource Kit et PsInfo de Sysinternals, et l’existence d’outils d’exécution à distance comme PsExec et BeyondExec autorisent des requêtes éloignées impossibles voilà encore quelques années.

Le code pour la capture de données en provenance d’une machine distante est très semblable à celui pour la capture en provenance d’une machine locale, mais il ajoute quelques commentaires N/A à certaines commandes qui ne fonctionnent pas bien à distance. A noter le point de rupture pour le code à distance dans le listing 2. Si l’opérateur du script ne spécifie pas un argument à l’exécution, le script s’exécute localement. Si un argument unique est spécifié, le flux du script saute à la section distante du code.

Le troisième scénario de capture se produit quand un nom d’utilisateur est spécifié et utilisé en lieu et place du nom d’utilisateur connecté dans une requête de machine à distance. L’entrée username est un argument <domain\ userID> spécifié à l’exécution du script qui suit immédiatement le nom de PC de l’ordinateur cible.

Tant que nous en sommes aux arguments spécifiés, l’un des aspects les plus ardus mais les plus nécessaires du coding de script est de déterminer si l’entrée d’un utilisateur est défectueuse, particulièrement quand le script est destiné à quelqu’un de peu familiarisé avec le scripting. Si je n’avais pas inclus un code de traitement d’erreurs dans Desktop- Diag.bat et si exécutiez le script avec un nom d’ordinateur ou un nom d’utilisateur incorrect ou si vous spécifiiez un PC déconnecté, le script s’exécuterait au travers du code renvoyant des erreurs et produisant en définitive un rapport blanc comme neige, à votre grande surprise.

Pour revenir au troisième scénario de capture, l’une des premières choses à faire est de tester l’existence du PC et son état connecté. Le renvoi A du listing 3 contient le code « If Exist » pour tester l’existence du PC. Si le share C$ sur l’ordinateur distant n’existe pas, le script se termine avec un message d’erreur qui demande à l’opérateur de vérifier le nom de l’ordinateur ou la condition online. Le code du renvoi C détermine si le compte utilisateur existe, en le vérifiant avec l’utilitaire GetUserInfo de joeware. Si GetUserInfo renvoie la chaîne « memberships » dans le cadre de sa sortie, c’est qu’il a trouvé un compte utilisateur valide et il renvoie les appartenances de l’utilisateur aux divers groupes. Si GetUserInfo ne renvoie pas « memberships », le script se termine et envoie un message d’erreur à l’opérateur. Cette opération évite de perdre du temps à exécuter l’utilitaire avec une entrée fantaisiste. En effet, certains outils envoient indéfiniment des erreurs en cas d’entrée incorrecte.

En ce qui concerne le compte utilisateur spécifié comme un second argument dans le listing 3, notez le point de rupture où le flux du script détecte le second argument dans le code au renvoi B. Premièrement, la variable DUres est laissée vierge puis rendue égale à %2, ou le second argument du script. Le code « If defined » teste si la variable DUres a un contenu, puis la commande For divise cette chaîne en information domaine et nom d’utilisateur qui est testée par rapport à l’utilitaire GetUserInfo.

La capture de données sur une machine distante pendant que de multiples utilisateurs sont connectés localement, est le quatrième scénario de capture. Vous vous demandez peut-être « comment un PC ou noeud de serveurs peut-il avoir de multiples logons locaux ? » Terminal Services permet à de multiples utilisateurs de se connecter localement à un noeud en même temps. Comme Desktop Diag.bat ignore de quel utilisateur il est question dans la portion utilisateur du code, vous devez contourner ce problème potentiel. Vous pouvez utiliser l’outil Findgrp du kit de ressources Win2K avec une boucle For pour capturer les appartenances aux groupes d’utilisateurs multiples.

Toutefois, si nous utilisons l’outil Gpresult pour obtenir le RSoP de l’utilisateur connecté, l’outil ne renverra pas de résultats corrects parce que chaque fois qu’il s’exécutera, il n’adressera la requête qu’au compte de l’utilisateur de la console. Par conséquent, le script doit détecter s’il y a plusieurs utilisateurs connectés et désactiver Gpresult pour les stratégies utilisateur si plusieurs utilisateurs locaux sont détectés. Le listing 4 contient le code de la commande For qui utilise la variable usercntr pour compter le nombre d’utilisateurs connectés localement. Le listing 5 contient le code de la commande If qui désactive la portion run du code de l’utilitaire Gpresult, si plus d’un utilisateur (c’est-à-dire si %user cntr% GTR 1) a été détecté.