Récupérer après l’échec d’une promotion DC

L’environnement dans lequel nous
évoluions incluait 30 DC (domain
controllers) dans un domaine NT 4.0
qui recouvrait de multiples emplacements.
Nous avions couvert toutes les
étapes importantes de préparation de
la mise à  niveau : réunions de conception,
test de la mise à  niveau, création
d’un plan de sauvegarde, mise offline
d’un DC NT 4.0, et tout ce que demande
une bonne mise à  niveau sur
Win2K et AD.
Au moment où le buffet est arrivé,
nous avions installé deux DC Win2K –
DC2 et DC3 – dans le bureau central de
Phoenix et il restait 28 BDC NT 4.0 à 
mettre à  niveau dans divers lieux. Pour
la prochaine phase de la mise à  niveau,
nous envisagions de migrer un BDC de
Delaware – DC1 – sur Win2K, afin de
pouvoir bénéficier des possibilités du
site d’AD quand nous réinstallerions
les clients Windows 95 à  Delaware avec
Windows XP Professional Edition.
Deux personnes s’occupaient du DC1
à  Delaware ; un autre technicien et
moi-même nous trouvions au centre
de contrôle de Phoenix.
Comme chaque DC est différent, il
faut les considérer individuellement en
vue d’une migration. Notre équipe
avait examiné rigoureusement la manière
de migrer DC1 dans les
meilleures conditions. Nos options
étaient les suivantes : effectuer une
mise à  niveau commune, effectuer une
mise à  niveau façon terre brûlée (c’està –
dire, en utilisant Fdisk ou la fonction
GDisk de Symantec Ghost pour nettoyer
le disque dur et recommencer),
ou installer une nouvelle instance de
Win2K par dessus le répertoire \winnt
existant. Nous voulions l’installation
Win2K la plus propre possible et donc
nous avons immédiatement écarté le
scénario de mise à  niveau. Nous ne
voulions pas endommager tout le système
parce que DC1 était un CAP
(Client Access Point) Microsoft SMS
(Systems Management Server) et donc
contenait plus de données que nous
n’en voulions supprimer et restaurer.
C’est pourquoi nous avons choisi la
troisième option.