> Tech > Installation

Installation

Tech - Par iTPro - Publié le 24 juin 2010
email

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

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 gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010