> Tech > Autres entrées comme arguments

Autres entrées comme arguments

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Les noms de serveurs ne sont pas les seuls arguments que vous pourriez juger utile de fournir. Pour dire au script où il doit obtenir son entrée, vous pouvez lui ordonner de la lire dans un fichier de texte contenant une liste des noms de serveurs, ou lui demander de

vérifier tous les serveurs présents
dans le domaine. Vous pouvez aussi dire au script que vous
avez besoin d’aide. Si vous ne fournissez pas d’arguments, le
script peut supposer que les arguments fournis sont les
noms des ordinateurs sur lesquels le script devrait s’exécuter.
Voyons comment tester toutes ces possibilités. (Par
exemple, nous organisons simplement le script afin qu’il
puisse travailler différemment selon l’entrée qu’il obtient.
Par la suite, nous donnerons au script le moyen de traiter
cette information.)

Si la personne qui exécute le script ne fournit aucun argument,
il s’exécutera sur l’ordinateur local. Pour vérifier les
services sur l’ordinateur local sans coder en dur ou fournir le
nom de celui-ci, vous pouvez utiliser la syntaxe WMI. Vous
pouvez spécifier l’ordinateur courant en donnant son nom,
mais vous pouvez aussi utiliser un point (.) pour ordonner à 
WMI d’exécuter ce script sur l’ordinateur local. Pour que le
script s’exécute localement par défaut, demandez-lui de
vérifier la valeur de Wscript.Arguments(0), qui est le premier
élément dans la collection Arguments. Si l’élément est vide,
le script donnera un point comme valeur de sComputer-
Name.

Autre possibilité : le script obtient la liste des noms de
serveurs à  partir d’un fichier. Comme l’emplacement des
fichiers de texte ne devrait pas changer, vous pouvez le coder
en dur dans le script. Mais vous devez
préciser que le script doit lire un fichier.
Pour cela, vous pouvez tester pour déterminer
si la valeur de Wscript.Arguments(
0) est file.

Vous pouvez configurer le script
pour qu’il s’applique à  tous les ordinateurs
dans l’AD ou à  un sous-ensemble
d’ordinateurs que vous coderez dans le
script. Pour rester simples, appliquonsle
à  tout le monde. Si un utilisateur veut
vérifier l’état des services sur tous les
ordinateurs utilisant WMI, il tapera all
comme argument. (De la même manière,
vous pourriez laisser les utilisateurs
fournir le nom d’une OU – organizational
unit – comme argument,
tester l’entrée pour déterminer si c’est
une OU, puis ne vérifier que les ordinateurs
qui se trouvent dans l’OU en question.)

Comme ce script peut accepter divers types d’entrées, il
a besoin de quelques instructions. Dans mes articles précédents
à  propos des scripts qui prennent des arguments, il
n’était pas question de n’avoir aucun argument. Si l’utilisateur
du script ne fournissait pas les arguments nécessaires, le
script annonçait qu’il avait besoin d’une entrée et stoppait
son exécution. Cette façon de faire ne vaut pas pour ce script,
parce qu’il est tout à  fait licite de ne pas fournir d’arguments.
Dans ce cas, le script s’exécutera localement. Par conséquent,
donnons à  la personne qui exécute le script la possibilité
d’utiliser la commande /? bien connue pour obtenir de
l’aide à  propos du script. Quand le script verra ces deux caractères
dans Wscript.Arguments(0), il imprimera des instructions
sur l’utilisation du script.

J’ai utilisé les instructions Select Case dans beaucoup
d’articles précédents. Par conséquent, vous ne serez pas
étonnés que je l’utilise dans ce script pour vérifier la valeur
des entrées. Le listing 3 montre un extrait de la partie du
script qui décide de la manière d’attaquer l’entrée. Le code
convertit l’entrée en minuscules (pour éviter les différences
de casse : ALL, All et all ne sont pas des valeurs de chaîne
identiques), puis teste pour déterminer la valeur de Wscript.Arguments(0) et exécute du code conformément à 
cette valeur. Bien entendu, le script final fera bien plus qu’indiquer
simplement la manière dont le script s’exécutera,
mais le listing 3 montre la structure générale. Vous savez
maintenant comment fournir une entrée autre que des noms
de serveurs.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010