Installation

le système réinitialisé, l’équipe distante
a exécuté Dcpromo et a sélectionné
DC1 comme un DC réplique
pour le domaine. La synchronisation
d’AD a commencé et tout semblait
merveilleux. Le système s’est réinitialisé
après la réplication. Nous avons attendu
que le DC apparaisse dans la console Active Directory Users and
Computers de MMC (Microsoft
Management Console), la console
MMC Active Directory Sites and
Services et DNS. Ce qu’il a fait, comme
prévu. Il restait un problème : DC1 se
trouvait dans le mauvais site. Nous
(l’équipe de Phoenix) avons utilisé la
console Active Directory Sites and
Services pour transférer DC1 sur le site
correct – et la situation a commencé à 
se gâter. La relation AD entre DC2 et
DC1 a échoué, et DC1 a semblé disparaître
de la surface de la terre.
Après avoir essayé quelques réinitialisations
infructueuses, nous avons
analysé notre situation : celle d’un
serveur Win2K qui ne communiquait
pas avec le domaine comme un DC
Win2K. Nous avons exécuté Dcpromo
sur DC1 pour essayer de dégrader le
DC en tant que serveur membre et nettoyer
la base de données, mais la rétrogradation
a échoué. DC1 n’avait pas de
connexions avec le domaine et partait
seul à  la dérive.
Pendant la recherche d’une solution,
nous ne pouvions nous empêcher
de penser à  l’heure. Il était
presque 11 heures du soir à  Phoenix et
nous étions tous épuisés après une
dure journée de travail. Pis encore,
pensant que cette étape serait simple,
nous avions prévu un vol à  6 heures le
matin suivant – et l’aéroport était à 
deux heures de voiture. Il nous fallait
une solution applicable rapidement
mais qui ne cause pas davantage de travail
ou de problèmes en route. Les possibilités
suivantes s’offraient à  nous :

• Réinstaller DC1 avec un nom
  NetBIOS différent. Mais comme DC1
  était un serveur CAP SMS, tous les
  clients de Delaware comptaient sur
  le nom existant. Bien que cette option
  fût celle qui demandait le moins
  de temps à  effectuer, elle supposait
  un important travail de nettoyage.

• Supprimer DC1 d’AD, puis réinstaller
  DC1 avec son nom original.
  C’était rapide mais risqué : si les connexions du site DC existantes
  étaient laissées à  l’abandon dans la
  base de données AD, le nouveau DC
  aurait des problèmes à  cause de
  noms en double.

• Supprimer DC1 d’AD, nettoyer la
  base de données AD, puis réinstaller
  DC1 avec son nom original. C’était
  l’option qui demandait le plus de travail
  mais qui semblait offrir le plus de
  stabilité.

Nous avons opté pour le plan d’attaque
le plus robuste. Il nous fallait
donc enlever DC1 de l’entreprise, nettoyer
la base de données AD et réinstaller
DC1 avec son nom d’origine.