Avant de commencer à installer Win2K
sur DC1, nous avons vérifié que le système
et tous les fichiers étaient sauvegardés.
L'équipe de Delaware a ensuite
jonglé avec les options d'installation
nouvelles de Win2K.
L'équipe distante a installé Win2K
sur DC1, en spécifiant le système
comme un serveur membre. Une fois
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.
Téléchargez cette ressource
Microsoft 365 : 5 erreurs de sécurité
A l’heure où les données des solutions Microsoft 365 sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités ? Découvrez le Top 5 des erreurs à ne pas commettre et les meilleures pratiques recommandées par les Experts DIB France.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Tendances des budgets des DSI en 2025
- Révolutionner la gestion du stockage à l’ère de l’IA et de la transformation numérique : vers une infrastructure agile et automatisée
- Multicloud Computing : Êtes-vous prêt pour la prochaine nouvelle vague informatique ?
- IA : les PME devraient adopter des outils NoCode appropriés
- Guide des certifications Microsoft