Ryo-Ohki a écrit :
Je vois vraiment pas le risque, sinon évidemment celui qu'il arrive un pépin à DC1 pendant que l'AD tourne sur une patte pendant la phase de remplacement de DC2, mais bon ça serait quand même un gros coup de pas de bol. Un p'tit BMR de DC1 juste avant de dépromouvoir DC2 original peut aider.
Faut balancer ça contre toutes les adhérences invisibles qu'il peut y avoir quand tu changes l'IP d'un DC
- les applis configurées avec les pieds qui attaquent l'AD par un seul DC et pas le nom de domaine
- les flux ouverts sur l'IP d'origine du DC et qui tombent mystérieusement parce que le DC est parti sans laisser d'adresse
- les délégations de zone depuis un DNS parent qui référencent ce DC
etc, etc, etc
|
Le risque, c'est que ton rollback est moins facile, voir carrément compliqué (dans un environnement multi-domaines par exemple).
Et pour les adhérences que tu décris, ce sont des bombes à retardement qu'il faut absolument identifier/corriger, ce que tu peux faire petit à petit avec un scnéario de coexistence. Avec un remplacement, tu en mets une partie sous le tapis (et tu n'es pas à l'abri d'une dépendance sournoise mais rare intégrée dans la machine, genre un script, des clés de registre, une tâche planifiée, des références en dur sur une MAC...).
Ca permet aussi de rejouer et mettre à jour les procédures d'exploitation les docs d'archi, etc. et de maintenir les niveau de connaissance des équipes AD.
Bref, le remplacement, c'est le côté obscur. Ce qui ne veut pas dire que ça ne fonctionne pas, ni que ce soit bien adapté dans certains cas.