Test d’adéquation

quel serveur répondant au test,
même s’il avait un GC préchargé, un
DC distant relié par une connexion
lente, ou un serveur qui n’avait pas répliqué
entièrement le contenu d’AD.
Tous ces scénarios causent des ennuis
à  Exchange : le routage des messages
ralentit, les utilisateurs constatent des
timeouts quand des clients tentent
d’accéder au GAL et des messages
pourraient même être envoyés à  des
adresses périmées.

Les tests d’adéquation vérifient
que le serveur est contactable, qu’il répond
aux requêtes en temps opportun,
et qu’il offre des services que
DSAccess peut utiliser. Les tests sont
classés en trois catégories : hard tests,
soft tests et side tests.
• Les hard tests déterminent si
DSAccess peut utiliser un serveur. Si
un serveur ne réussit pas ces tests,
DSAccess l’ignore. Ainsi, si un serveur n’est pas atteignable par le
port 389 (pour un DC) ou 3268
(pour un GC), DSAccess reconnaît
que le serveur n’est pas un serveur
AD. Pour empêcher DSAccess de se
connecter à  une copie désynchronisée
d’AD et d’utiliser une information
périmée, d’autres hard tests déterminent
si les données AD sur le
serveur sont synchronisées et participent
à  des activités de réplication
classiques.
• Les soft tests déterminent les
meilleurs serveurs à  utiliser par
DSAccess. Par exemple, un test détermine
si un serveur est dans le
même site Win2K que le serveur
Exchange. D’autres tests déterminent
la charge sur le serveur en mesurant
la promptitude avec laquelle
le serveur répond aux requêtes LDAP
et le nombre de requêtes LDAP en attente.
DSAccess préfère ne pas se
connecter à  un serveur très chargé
parce que des réponses lentes aux
requêtes AD retarderont le traitement
des messages au travers du
moteur de routage. De même,
DSAccess évitera un serveur qui joue
un rôle Operations ou FSMO
(Flexible Single-Master Operation)
pour le domaine ou la forêt, parce
qu’un tel serveur risque lui aussi
d’être très chargé.
• Les side tests déterminent si
DSAccess peut utiliser un serveur
comme un DC ou un GC.