Mes 5 fonctions d’IADsTools les plus fréquemment utilisées

les objets
de connexion de réplication d’AD et la
topologie de sites. Comme je ne peux
pas couvrir toutes les fonctions dans
cet article, j’ai décidé de me concentrer
sur les cinq que j’utilise le plus et
que j’apprécie dans mon administration
au jour le jour des environnements
AD.

GetPDCFSMO(). Je commencerai
par décrire les fonctions simples
d’IADsTools. Par exemple, avez-vous jamais
dû découvrir quels DC (domain
controllers) dans votre environnement
AD jouent les rôles FSMO (Flexible
Single-Master Operation) ? Vous pouvez
recueillir des informations à  propos
des rôles FSMO interactivement au
moyen du snap-in Microsoft Management
Console (MMC) Active
Directory Users and Computers, mais
certaines circonstances pourraient
vous obliger à  obtenir cette information
programmatiquement. IADsTools
a cinq fonctions, dont chacune correspond
à  l’un des cinq rôles FSMO, pour
vous aider à  déterminer quel DC accomplit
quel job. Les fonctions sont
GetDomainNamingFSMO(), GetPDCFSMO(),
GetInfrastructureFSMO(), Get-
RidPoolFSMO() et GetSchemaFSMO().
Le script du listing 1 interroge l’infrastructure
AD pour identifier quel DC
dans la forêt AD joue le rôle PDC FSMO. Sachez que, par défaut, le script
utilise les références AD de l’utilisateur
qui exécute le script, sauf si vous
fournissez un paramètre facultatif
dans l’appel de fonction qui précise
que vous voulez utiliser des références
différentes. Ces références doivent ensuite
être spécifiées dans une fonction
séparée, que je décris ci-dessous.
La partie intéressante du script,
que le code du renvoi A du listing 1
montre, appelle la fonction GetPDCFSMO()
et utilise la commande
Wscript.echo pour renvoyer le résultat
à  l’écran. Le script passe deux paramètres
à  la fonction : le nom du DC auquel
je veux appliquer la commande
(Yquem, par exemple) et le nom
du domaine AD à  interroger (marelia.
com, par exemple). Un DNS ou un
nom LDAP (Lightweight Directory
Access Protocol) feront l’affaire. Bien
entendu, pour des rôles FSMO s’exprimant
dans toute la forêt (par exemple,
le schema role holder), vous pouvez
simplement pointer la fonction sur
n’importe quel DC et n’importe quel
domaine dans la forêt auquel vous
pouvez accéder avec les références par
défaut ou d’autres références que vous
indiquez.
Changer les références que vous
utilisez pour vous connecter au DC ou
au domaine n’est pas si simple. Au lieu
de passer les références alternées
comme paramètres à  la fonction Get-
PDCFSMO(), comme vous pourriez
l’espérer, vous devez appeler une fonction
IADsTools séparée, SetUser-
Credentials(), pour définir les références
alternatives avant d’appeler la
fonction FSMO. SetUserCredentials()
est une fonction générale que vous
pouvez utiliser avec les autres fonctions
IADsTools pour passer les références
alternées avec une requête.
Pour voir comment SetUserCredentials
fonctionne, modifions le script du listing
1 pour utiliser des références différentes
pour me connecter à  mon infrastructure
AD.

SetUserCredentials(). A noter que le code du renvoi A dans le listing
2 appelle la fonction SetUserCredentials()
et passe le nom d’utilisateur et le
domaine Windows NT 4.0 de bas niveau
ainsi que le DN (distinguished
name) AD LDAP. Le dernier paramètre,
« secret », est le mot de passe de l’utilisateur,
que vous pouvez ajouter en utilisant
une boîte d’entrée VBScript
simple plutôt qu’en codant en dur le
mot de passe en texte clair, comme je
l’ai fait. A noter que cet appel requiert
toute cette information NT 4.0 et AD –
vous ne pouvez éliminer aucun des
quatre paramètres requis quand vous
utilisez cette fonction. Après avoir accepté
les références alternées, le code
au renvoi B du listing 2 appelle à  nouveau
la fonction GetPDCFSMO(), mais
cette fois-ci passe le paramètre facultatif
de 1 pour indiquer que je veux utiliser
les références que j’ai extraites au
renvoi A dans le listing 2. Ces références
alternées restent en vigueur
pendant la durée du script, ou jusqu’à 
ce que celui-ci appelle la fonction
ClearUserCredentials().

DSGetSiteName(). Une autre
fonction IADsTools, DSGetSiteName(),
est intéressante pour dépanner des
problèmes avec l’authentification,
Microsoft DFS, ou autres processus
Win2K dont le comportement est déterminé
par l’affinité avec le site. Vous
pouvez appliquer cette fonction à  une
station de travail ou serveur (local ou
distant) pour savoir à  quel site AD l’ordinateur
pense qu’il appartient. Vous
invoquez DSGetSiteName() en passant
le nom du serveur ou de la station de
travail cible pour lequel ou laquelle
vous voulez recueillir des informations
de site (rappelons que Win2K stocke
l’information d’appartenance au site
sur la machine elle-même, pas dans
AD).

Le script du listing 3 complique un
peu les choses en utilisant la fonction
inputbox de VBScript pour demander
à  l’utilisateur d’entrer le nom de l’ordinateur
qu’il veut interroger, comme le
code du renvoi A dans le listing 3 le montre. Une fois que le script collecte
l’entrée de l’utilisateur, il utilise
Wscript.echo et du texte formaté,
comme le montre le code du renvoi B
dans le listing 3, pour passer un résultat
à  l’écran. La fonction UCASE()
convertit le nom de l’ordinateur en
majuscules et la constante vbCRLF
ajoute un retour chariot et un interligne
pour clarifier la sortie écran.
Enfin, le script appelle la fonction
DSGetSiteName(), en passant le nom
cible d’entrée comme un paramètre.
Notez que le code du renvoi B utilise la
fonction cstr() pour convertir la variable
strTargetComputer en une
chaîne appropriée que la fonction
DSGetSiteName() peut traiter. La figure
2 montre un exemple de sortie
obtenue après exécution du script du
listing 3.

GetGCList(). Une autre fonction IADsTools utile, et aussi légèrement
plus complexe, est GetGCList(), qui
renvoie une liste de tous les GC
(Global Catalogs) présents dans une
forêt. La difficulté ici est de savoir comment
obtenir la liste des serveurs. Le
code du listing 4 montre comment accomplir
cette tâche.
Le code du renvoi A dans le listing
4 invoque la fonction GetGCList()
contre un DC dans une forêt AD.
GetGCList() prend comme entrée le
nom du DC auquel la fonction devrait
s’appliquer et renvoie deux éléments.
Premièrement, la fonction renvoie une
valeur qui correspond au nombre de
GC que la fonction a trouvés dans la forêt.
La fonction stocke cette valeur
dans la variable NumberofGCs. Si la valeur
est -1, la fonction n’a pas trouvé de
GC, ce qui indique généralement un
problème concernant soit la connexion au DC, soit la bonne énumération
des serveurs GC disponibles. Si la variable
NumberofGCs est mise à  -1, le
code du renvoi B du listing 4 envoie un
message à  l’écran pour signaler l’erreur
à  l’utilisateur, met fin au script, et
renvoie une valeur non 0 (1). Le second
élément que la fonction
GetGCList() renvoie est une énumération
qui donne la liste des noms des
GC trouvés. Le script du listing 4 n’affiche
pas cette énumération immédiatement
; cependant, si vous examinez
la documentation d’IADsTools, vous
constaterez que la fonction Get-
GCList() renvoie une propriété sur
l’objet IADsTools appelée GCName,
qui est une matrice des noms de serveurs
GC que la fonction GetGCList() a
trouvés. En utilisant une boucle
For…Next simple dans le code au renvoi
C du listing 4, le script énumère
chaque nom de serveur de GC, jusqu’au
nombre trouvé et affiche la sortie
sur l’écran. Avec ce type de script
WSH, je conseille d’utiliser le moteur
cscript.exe ligne de commande plutôt
que wscript.exe pour exécuter le
script. Sinon, s i vous utilisez
wscript.exe, chaque nom de serveur
trouvé apparaîtra dans une boîte de
dialogue surgissante séparée. Vous
pouvez aussi utiliser FileSystemObject
de VBScript pour stocker les résultats
dans un fichier texte pour manipulation
ultérieure.

Fonctions liées au GPO. Cet ensemble
de fonctions vous permet d’obtenir
des informations sur les GPO
dans vos domaines AD. Pour la plus
grande partie, vous ne pouvez pas utiliser
de scripts pour créer ou modifier
des GPO dans Win2K. Cette limitation
changera probablement dans un futur
proche mais, en attendant, vous pouvez
utiliser une poignée d’outils de
scripting pour obtenir des informations
sur les GPO. IADsTools.dll en
fournit quelques-uns d’excellents. Le
code du listing 5 utilise plusieurs fonctions
liées aux GPO pour interrogertous les GPO dans un domaine et,
d’après l’entrée utilisateur, comparer
le numéro de version d’un Group
Policy Container (GPC – la portion du
GPO stockée dans AD) avec le numéro
de version d’un Group Policy Template
(GPT – la portion du GPO stockée dans
SYSVOL). Pour être traités par le client,
les numéros de version GPC et GPT
d’un GPO doivent être les mêmes sur
un DC donné pour ce GPO. Par conséquent,
le script peut vous aider à  détecter
des discordances sur le DC auquel
le script s’applique.
Le code du renvoi A dans le listing
5 définit deux variables qui contrôlent
le domaine AD et le DC auxquels le
script s’appliquera. Vous pouvez tout
aussi simplement passer ces variables
dans le script comme des paramètres
ligne de commande, mais j’ai préféré
les coder en dur. Le code au renvoi B
dans le listing 5 demande à  l’utilisateur
d’indiquer le nom convivial du GPO
que l’utilisateur veut interroger. Le
nom convivial est simplement le nom
de texte par lequel le GPO est connu
dans l’outil éditeur Group Policy (pas
le nom globally unique identifier –
GUID – de 128 bits par lequel le GPO
est connu dans AD). Par exemple,
« Default Domain Policy » est le nom
convivial pour le GPO que le GUID
{31B2F340-016D-11D2-945F-00C04FB984F9} représente. La seconde
instruction du renvoi B appelle
la fonction GetGPOs() qui renvoie une
énumération de tous les GPO trouvés
dans le domaine sur le DC cible. A noter
que le numéro de version d’un
GPO peut varier d’un DC à  un autre.
Par conséquent, si vous voulez vraiment
que le script fasse son travail, il
vous faudra peut-être l’appliquer à  plusieurs
DC.
La première ligne de code au renvoi
C du listing 5 crée une boucle
For…Next qui vérifie chaque GPO
trouvé pour déterminer si le GPO correspond
au nom de celui entré par
l’utilisateur. La ligne de code suivante au renvoi C compare le nom convivial
de chaque GPO trouvé par la fonction
GetGPOs() au nom GPO convivial entré
par l’utilisateur. La fonction
VBScript LCase() met les deux noms
en minuscules pour empêcher les
éventuelles discordances en raison de
différences de casse. La fonction
GPOName() contient le nom convivial
de chaque GPO renvoyé à  partir du
code au renvoi B. Vous pourriez utiliser
la fonction GPOGuid() pour obtenir le
GUID du GPO à  partir de son nom
convivial. Le code au renvoi D du
listing 5 donne les résultats de la
recherche.
Une fois que le script a trouvé le
GPO correct, il utilise les fonctions
GPOVersion() et GPOSysvolVersion()
pour obtenir les versions GPC et GPT
du GPO. Enfin, la boucle If…Then…
Else dans le code au renvoi E du listing
compare les versions GPC et GPT et
indique s’ils sont identiques (synchronisés)
ou non concordants (désynchronisés).
Utilisez cscript.exe pour exécuter
ce script et songez à  capturer la sortie
du script dans un fichier pour analyse
ultérieure. Pour vérifier les numéros de
versions pour tous les GPO sur un DC
donné, supprimez simplement la ligne
de code au renvoi B qui demande une
entrée à  l’utilisateur – le script comparera
ensuite les versions pour chaque
GPO que la fonction GetGPOs() trouvera.