Suivre une réplication d’A.D.

  Les administrateurs dans un domaine AD Windows NT 4.0 ou en mode mixte doivent se connecter au PDC avant de modifier un compte utilisateur ou une autre donnée du domaine. Mais, les administrateurs dans un environnement Windows 2000 mode natif (c’est-à -dire,AD) peuvent mettre à  jour l’AD à  partir de n’importe quel DC (domain controller). Par conséquent, le mode natif est plus souple que le mode NT mixte, mais la réplication d’AD en mode natif est plus complexe et fait appel à  quelques nouveaux concepts, dont deux sont les USN (update sequence numbers) et une table des marques hautes (high-watermarks). Chaque DN enregistre le nombre de mises à  jour AD qui se sont produites dans son existence et donne à  chaque mise à  jour un USN séquentiel unique.

  Supposons que nous créions un nouvel AD vide sur un DC nommé dc1.acme.com, suivi d’un compte nommé Mary sur le DC. Ce compte est la première mise à  jour de l’AD, donc celui-ci donne à  celle-ci un USN de 1. (Bien entendu, je simplifie à  l’extrême le mécanisme de numérotation des USN.) Si nous créons ensuite un compte nommé John, l’AD attribue l’USN 2 à  cette mise à  jour. Après quoi, Mary met à  jour l’AD en modifiant son mot de passe, qui devient alors USN 3, et John modifie son mot de passe, créant USN 4 – l’USN le plus haut sur cette copie de l’AD. A présent, amenons en ligne un deuxième DC, dc2.acme.com. Dans le cadre du processus lui permettant de devenir un DC, DC2 copie la base de données AD du DC1. Mais, DC2 ne copie pas tout l’historique de l’AD, il ne copie que les dernières informations. Par conséquent, DC2 copie les deux comptes utilisateur et les considère chacun comme une mise à  jour, donc l’USN de DC2 est 2. Les DC utilisent leurs propres USN et ceux des autres DC pour déterminer si les DC sont à  jour entre eux. Ainsi, quand DC2 demande à  DC1 des mises à  jour, DC2 ne veut pas une longue litanie de tout ce que DC1 a appris ; DC2 veut simplement savoir ce qui a changé depuis la dernière réplication. En fait, DC2 dit à  DC1 : « Dites-moi tout ce qui s’est passé depuis votre USN 4 ». Comme on le voit, DC2 doit se souvenir du dernier USN qu’il a obtenu de DC1 ; cet USN est appelé la marque haute du DC1.

  Chaque DC maintient une table des marques hautes pour chacun de ses partenaires de réplication. On peut utiliser la commande Repadmin /showreps pour visualiser cette table :

Repadmin /showreps
<namingcontext> <dcname>
/verbose

Par exemple, pour voir la table des marques hautes de DC2, on tapera :

Repadmin /showreps

dc=acme,dc=com

dc2.acme.com /verbose

En extrait, la sortie pourrait se présenter ainsi :

=== INBOUND NEIGHBORS ===

Site1\DC1 via RPC

USNs : 59228/OU,

59228/PU

  Il y a une ligne pour chaque partenaire de réplication. La valeur de la marque haute est le nombre qui suit les USN : 59228 dans l'exemple. Comment utiliser cette information ? Dans un AD fonctionnant correctement, vous ne devriez jamais avoir à  le faire. Mais supposons que vous ayez octroyé à  un utilisateur une nouvelle autorisation ou un nouveau droit, et que celuici, parfois, ne puisse pas l'exercer. Quel pourrait donc être le problème ? Il est probable que l'un des DC du réseau n'a pas reçu les mises à  jour donnant le détail d'un nouveau droit ou autorisation. Pour savoir si le problème est bien là , ouvrez une ligne de commande sur le bureau de l'utilisateur et utilisez la commande Set pour déterminer à  quel DC l'utilisateur est connecté. Ensuite, extrayez la table des marques hautes pour ce DC. Vous verrez alors si le DC auquel s'est connecté l'utilisateur est en retard par rapport aux autres DC. Si oui, déclenchez une réplication en suivant les instructions de " Forcing AD Replication ", et le problème devrait disparaître.