Autres considérations

pour les agences qui n’ont pas
de DC, parce que les clients utilisant de telles applications essaient
d’abord de trouver un serveur hôte dans leur site.
Supposons que vous déployiez DFS (pour une distribution
de logiciel par exemple) dans plusieurs agences qui font partie
d’un site AD plus grand. Les clients Windows recherchant
un serveur DFS pourraient se retrouver en train d’essayer de
se connecter à  un serveur à  l’autre bout d’un circuit WAN de
256 Kbps, alors même qu’il existe un serveur DFS dans
l’agence. La solution consiste à  créer un site pour chaque
agence. Tout serveur DFS local fera partie du nouveau site de
cette agence, les utilisateurs locaux sélectionneront d’abord
ce serveur pour l’accès à  DFS et la fonction de couverture du
site AD garantira que les DC hors site voisins authentifieront
les utilisateurs de l’agence. (Rappelons que cette fonction
vous oblige à  enregistrer vos subnets IP dans un site. Les
clients sur un subnet non enregistré se retrouvent dans le
site Default-First-Site-Name, qui probablement n’a aucun
DC. Les clients doivent alors effectuer une recherche d’emplacement DC sur l’ensemble du domaine et il est probable
qu’ils ne choisiront pas le DC le plus proche.)

Si vous installez un serveur de DC et de GC combinés localement,
il y a un autre service d’infrastructure qui doit être
actif : DNS intégré à  l’AD. Ce service est très efficace, alourdit
très peu le DC ou la réplication, et est constamment utilisé
par les clients.