none
Migration : Changer le nom du contrôleur de domaine par celui de l'ancien serveur. RRS feed

  • Question

  • Bonjour,

    je travail toujours sur une procédure de migration d'un serveur 2008 DC vers un 2019 DC.

    Je vais monter 2ème serveur 2019 en // pour transférer les rôles etc et ensuite supprimer l'ancien serveur 2008. Donc pendant la migration le serveur 2019 aura un nom et une ip différente de l'ancien vu qu'ils seront sur le même réseau.

    J'ai une question concernant le changement de nom de serveur après migration.

    Situation : les postes clients ont des lecteurs réseaux mappés par des scripts à l'ouverture de sessions sur AD

    du genre net use V: ...\\SRV\robert$...

    et ils ont des logiciels client où le chemin de la base de donnée est \\SRV\bdd$.

    Question :

                    1)J'aimerais savoir si une fois le nouveau Serveur DC 2019 en place et l'ancien serveur arrêté je peux redonner le nom de l'ancien serveur ainsi que son adresse IP ? comme cela j'aurai juste à remettre les mêmes partages et je n'aurai pas à intervenir sur les postes clients pour changer le DNS ou les chemins de base de données ou même les scripts du serveur dans SYSVOL.

    2)Est ce possible ? et est ce que les partages vont refonctionner ? sont ils juste liés à un nom UNC ou bien il y a un genre d'ID lié à chaque partage et que de remettre le même nom ne suffit pas.(j'ai vu qu'il y a d'autres système DFS mais cela ne m'intéresse pas...)

    3)Le fait que le DC récupère le nom et l'ip ne pose t'il pas de problème quand les postes client rouvriront leur sessions pour la première fois sur le nouveau DC ?

    Merci d'avance




    jeudi 30 janvier 2020 09:45

Réponses

  • Est il possible de l'éteindre simplement au lieu de le rétrograder et que voulez vous dire par nettoyer les DNS ?

    Non, s'il n'a pas été rétrogradé il faut nettoyer manuellement les métadonnées. Sinon il reste enregistré comme un partenaire de réplication pour  le DC restant. Tôt ou tard il faudra le gérer, et plus tu le fais tard et plus ca peut être casse gueule.

    Un DC doit être supprimé proprement en fin de vie et pas juste éteint.

    Après avoir été rétrogradé il peut resté des enregistrements dans les zones DNS, c'est recommandé de faire le ménage.

    http://www.pbarth.fr/node/35

    https://social.technet.microsoft.com/wiki/contents/articles/7608.srv-records-registered-by-net-logon.aspx

    Est ce que je peux au moins reprendre IP de l'ancien serveur une fois l'autre éteint ?

    Oui si c'est bien fait et si on maîtrise le changement,(comme pour le nom) car les postes clients se réfèrent à ces informations pour localiser le DC. Il est préférable de ne pas changer le nom et l'IP en même temps ... 

    Comme cela pas besoin de changer l'ip DNS sur poste client déjà et même sur le routeur etc.

    Tu n'as pas de DHCP ? Sinon il suffit de changer les options du serveur DHCP. 

    Et sinon tu peux mettre à jour l'ensemble de tes postes par un scripts. 

    Tu peux t'inspirer du script ci dessous pour modifier DNS primaire et secondaires sur tous les postes : 

    $computers = Get-ADComputer -filter * | select DNSHostName $dnsservers = "192.168.1.1","192.168.1.2" foreach ($comp in $computers) { #lecture de l'ancienne valeur $adapters = gwmi -q "select * from win32_networkadapterconfiguration where ipenabled='true'" -ComputerName $comp.DNSHostName foreach ($adapter in $adapters) { #modification $adapter.setDNSServerSearchOrder($dnsservers) #Controle de la nouvelle valeur $adapters = gwmi -q "select * from win32_networkadapterconfiguration where ipenabled='true'" -ComputerName $comp #.DNSHostName $listeNew += New-Object -TypeName PSCustomObject -Property @{ 'Name' = $comp #.DNSHostName 'Address' = $adapter.DNSServerSearchOrder } } }

    $listeNew

    J'ai utilisé un script de ce genre pour mettre à jour plus de 150 serveurs virtuel.


    vendredi 31 janvier 2020 18:02

Toutes les réponses

  • Je vais monter 2ème serveur 2019 en // pour transférer les rôles etc et ensuite supprimer l'ancien serveur 2008. Donc pendant la migration le serveur 2019 aura un nom et une ip différente de l'ancien vu qu'ils seront sur le même réseau.

    Ce genre de scénario pousse l'admin à la précipitation et peut être source de problème. Une migration AD se fait dans le calme en toute transparence pour l'utilisateur.

    Si tu utilises des espaces de nom DFS tu n'as plus besoin de te préoccuper du nom réél de ton serveur lors de la migration et donc il n'est pas utile de renommer le serveur après.

    Un contrôleur de domaine ne devrait pas être un serveur de fichiers, même si on n'a pas toujours le choix.

    Le renommage d'un DC peut créer des problèmes s'il est mal fait. Lors du renommage l'important est de garantir le bon fonctionnement de DNS et de la résolution de nom et de bien nettoyer les DNS des serveurs qui ont été supprimés.

     1)J'aimerais savoir si une fois le nouveau Serveur DC 2019 en place et l'ancien serveur arrêté je peux redonner le nom de l'ancien serveur ainsi que son adresse IP ? comme cela j'aurai juste à remettre les mêmes partages et je n'aurai pas à intervenir sur les postes clients pour changer le DNS ou les chemins de base de données ou même les scripts du serveur dans SYSVOL.

    C'est possible pas forcément recommandé, c'est également possible de mettre le bordel si c'est pas maîtrisé.

    Pour récupérer les partages sur un serveur et remettre la même chose sur un autre, il faut que les dossiers destinations existent, puis exporter le registre en .reg sur l'ancien :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

    Il suffit de cliquer sur le point reg pour créer les partages sur le nouveau.

    Pour créer la structure de dossier sur le nouveau serveur il suffit d'utiliser robocopy.

    3)Le fait que le DC récupère le nom et l'ip ne pose t'il pas de problème quand les postes client rouvriront leur sessions pour la première fois sur le nouveau DC ?

    Les postes clients utilisent les DNS pour localiser les contrôleurs de domaines, il est important que les postes client ont toujours un DNS valide dans les paramètres réseaux. Si DHCP voir dans les options DHCP.

    jeudi 30 janvier 2020 10:21
  • Merci déjà pour ces éléments je prend le temps je fait des tests actuellement avec des VMs (VM2008 et VM2019) en suivant plusieurs tutos dont un des vôtres notamment pour établir la procédure précise et avoir le moins de surprise possible ;) effectivement j'aimerais que ce soit transparent. Je progresse :)

    Opérations tests effectuées sur le serveur 2019 dans environnement test :

    Insertion dans le domaine OK, Robocopy OK, installation AD OK, gestion de l'erreur SYSVOL_DFSR du 2008 réglé en ligne de commande avec votre tutos -> Création DC domaine existant OK, transfert de rôles FSMO OK.

    Pour récupérer les partages sur un serveur et remettre la même chose sur un autre, il faut que les dossiers destinations existent, puis exporter le registre en .reg sur l'ancien :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares

    Merci pour cette info j'ai constaté que robocopy fait les droits et hiérarchie fichiers mais pas les partages.

    J'ai une question du coup comment cela fonctionne vous dîtes que cela remet les partages mais il faut donc que le serveur est le même nom que l'ancien car sinon quel nom donne t'il au partage ? il mettrais quand même \\SRVancien\robert$  si le nouveau serveur à un nom différent ?

    Merci


    jeudi 30 janvier 2020 10:57
  • Merci pour cette info j'ai constaté que robocopy fait les droits et hiérarchie fichiers mais pas les partages

    Les partages sont des informations stockés dans le registre et non sur le système de fichiers

    mais il faut donc que le serveur est le même nom que l'ancien car sinon quel nom donne t'il au partage ? 

    dans \\monserveur\monpartage,  monpartage est dans le registre, monserveur c'est de la résolution de nom.

    Avec DFS et un espace de nom dans un domaine, tu utilises un nom relatif qui ne reprend pas le nom du serveur, qui est un lien vers le partage réél. Il est donc simple de migrer vers un nouveau serveur. DFS c'est 10 minutes de config.

    Renommer un DC est pas forcément complexe si on maitrise toute la partie DNS et les enregistrements liés à AD, si l'on est pas expérimenté cela peut vite devenir une catastrophe.

    Renommer un domaine c'est encore plus compliqué.


    jeudi 30 janvier 2020 12:44
  • bonjour Jessie-oignons

    Tu as récupérer un .reg qui pointe sur SRV1 (disons que ton nouveau serveur s'appelle SRV2)

    Edite le fichier .reg avec un notepad ou n'importe quel éditeur de texte et change SRV1 par SRV2.

    Profites en pour bien checker ce qu'il y a dedans afin de ne pas importer des choses qui ne devraient pas. Ce que tu veux, ce sont les partages rien d'autre.

    Claque le fichier .reg. Une petite vérif avec un net Share ... finito pour ça,

    Concernant Robocpy : Normal ça copie les fichiers/répertoires et ce qui en fait partie : les Acls (permissions NTFS).

    Les droits sur un share n'ont rien à voir avec des fichiers ou répertoires.

    Maintenant à cette étape, tu as 2 DCs/FileServer. OK

    Petit check dans l'AD. ==> Sur les Users accounts, HomeDir  pointent sur un share de SRV1 + LoginScript qui fait des maps sur SRV1  : PENSER A CHANGER CELA (pas maintenant)

    On va se planifier le boulot :

    Comment modifier les 2 paramètres ? Script ou via le GUI tu peux changer une sélection de comptes massivement comme ceci :

    Tu sélectionnes les comptes (tu sera limité à ce que tu verras à un OU, mais tu tu recommence pour chaque OU users), Click-droit propriétés et là tu n'auras que 2 onglets de mémoire ... avec seulement les propriétés communes qui peuvent être modifiées ... et surtout il y a les 2 qui t'intéressent.

    ex. : HomeDir \\SRV2\Users$\%UserName% (à validation %UserName% sera remplacé automatiquement pour le logon name de chaque compte

    Seconde solution en PS.

    Maintenant Il faut ordonnancer et planifier tout ça. Ne Pas oublier que les fichiers copiés sur SRV2 sont actuellement modifiés par les users sur ... SRV1. On prévoit cela le (soir) quand les users ne seront pas là

    Petite check list

    • Sync des fichiers copiés de SRV1 vers SRV2. Attention à la manière dont tu as fait ton Robocopy. Durée : dépend nombre de fichiers (la volumétrie conditionne le temps pour la première copie, là c'est juste le Delta).
    • Modification des HomeDir et PathLogonScript et contenu LogonScript : qq minutes
    • Edit du LogonScript (peu importe sur SRV1 ou SRV2, ça se réplique entre DC)  et modifications des liens vers serveur de fichier SRV1 vers SRV2.

    Terminé pour l'instant. prévoir pour la suite :

    Arrêt temporaire SRV1. Juste pour vérifier si un applicatif quelquonque ne ferait pas appel en dur à SRV1. Moindre pb : on rallume. On identifie le pb, on lui fait la peau. Quand tout est OK, On sort proprement SRV1 du rôle DC, puis sortie du domaine. et extinction finale. Pas besoin de changer le nom  de SRV2.

    ... et si ... il peu toujours en avoir : régler cela via création ou mise à jour d'un alias dans le DNS.

    cordialement

    Olivier


    jeudi 30 janvier 2020 13:49
  • Si tu fais un export depuis regedit par la :

    Tu copies le fichier sur le nouveau serveur, tu double clic dessus, tu reboot le serveur, si les dossiers des partages existent les partages existeront sur le nouveau. Il suffira d'y copier le contenu des dossiers partagés. Il n'y a rien à modifier dans le reg.

    Enfin si tu mets en place DFS avant de migrer, tu change les noms vers les nom DFS, ensuite tu basculer plus facilement sans modifier les chemins sur les postes et les scripts de connexion.

    ... et si ... il peu toujours en avoir : régler cela via création ou mise à jour d'un alias dans le DNS.

    Il est préférable de ne pas créer d'alias surtout pour un contrôleur de domaine, cela peut perturber certains éléments comme l'authentification KErberos qui nécessite de mettre les noms (y compris les alias) dans les SPN :

    http://www.pbarth.fr/node/336


    jeudi 30 janvier 2020 15:37
  • Merci encore pour ces infos.

    Renommer un DC est pas forcément complexe si on maitrise toute la partie DNS et les enregistrements liés à AD, si l'on est pas expérimenté cela peut vite devenir une catastrophe.

    Que voulez vous dire si on est pas expérimenté ? Si on suit les étapes :

    Insertion dans le domaine, Robocopy OK, installation AD, gestion de l'erreur SYSVOL_DFSR, Création DC dans le domaine existant, un DNS est crée et repliqué automatiquement c'est bien ça ?, transfert des rôles FSMO.

    Normalement arrivé là je peux éteindre l'autre serveur changer l'ip et le nom du serveur et c'est OK non ?

    vendredi 31 janvier 2020 07:32
  • Normalement arrivé là je peux éteindre l'autre serveur changer l'ip et le nom du serveur et c'est OK non ?

    Avant de l'arrêter et de modifier le nouveau, il faut mettre à jour DNS primaire sur les interfaces réseaux de tous les postes.

    Il faut d'abord rétrograder l'ancien DC et nettoyer proprement les DNS. 

    DNS se réplique automatiquement mais le contenu de DNS doit être vérifié et au besoin nettoyé manuellement. 

    En général on ne fait pas ce type d'opération car cela représente un risque pour pas gros chose... Surtout si c'est juste pour du partage de fichier. Souvent ce qui le font se créé des problèmes plus importants que ceux qu'ils essaient d'éviter. 

    vendredi 31 janvier 2020 07:43
  • Merci beaucoup pour votre aide.

    1) J'ai regardé par contre comme dit Philippe Barth on ne peut pas editer le .reg c'est de l"hexadecimal.

    2) Pas de souci de ce côté là il n'y a pas de HomeDir ou dossier de base (rien de renseigné dans cette case) ils se connectent sur le lecteur mappé uniquement par le petit script.

    3) Les script pas long à changer effectivement y'en a 10 suffit de changer nom du serveur sur le chemin UNC après net use...

    4) Ok oui pour le timing faut être prudent ce sera carrément pendant une période de fermeture que je ferai cela sans personne sur le réseau.

    Par contre je vois que tu dis comme P.Barth de ne pas changer le nom du serveur par celui de l'ancien.

    Je vais refaire le point et prendre en compte le fait de ne pas changer le nom mais par contre ce ne sera pas invisible pour l'utilisateur puisque je devrais aller sur chaque poste client modifier IP nouveau DNS et chemin UNC sur les logiciels clients. Mais bon cela peut être rapide faut que je liste tout.

    Il faut d'abord rétrograder l'ancien DC et nettoyer proprement les DNS. 

    Est il possible de l'éteindre simplement au lieu de le rétrograder et que voulez vous dire par nettoyer les DNS ?

    Est ce que je peux au moins reprendre IP de l'ancien serveur une fois l'autre éteint ?

    Comme cela pas besoin de changer l'ip DNS sur poste client déjà et même sur le routeur etc.

    Merci encore



    vendredi 31 janvier 2020 08:35
  • Est il possible de l'éteindre simplement au lieu de le rétrograder et que voulez vous dire par nettoyer les DNS ?

    Non, s'il n'a pas été rétrogradé il faut nettoyer manuellement les métadonnées. Sinon il reste enregistré comme un partenaire de réplication pour  le DC restant. Tôt ou tard il faudra le gérer, et plus tu le fais tard et plus ca peut être casse gueule.

    Un DC doit être supprimé proprement en fin de vie et pas juste éteint.

    Après avoir été rétrogradé il peut resté des enregistrements dans les zones DNS, c'est recommandé de faire le ménage.

    http://www.pbarth.fr/node/35

    https://social.technet.microsoft.com/wiki/contents/articles/7608.srv-records-registered-by-net-logon.aspx

    Est ce que je peux au moins reprendre IP de l'ancien serveur une fois l'autre éteint ?

    Oui si c'est bien fait et si on maîtrise le changement,(comme pour le nom) car les postes clients se réfèrent à ces informations pour localiser le DC. Il est préférable de ne pas changer le nom et l'IP en même temps ... 

    Comme cela pas besoin de changer l'ip DNS sur poste client déjà et même sur le routeur etc.

    Tu n'as pas de DHCP ? Sinon il suffit de changer les options du serveur DHCP. 

    Et sinon tu peux mettre à jour l'ensemble de tes postes par un scripts. 

    Tu peux t'inspirer du script ci dessous pour modifier DNS primaire et secondaires sur tous les postes : 

    $computers = Get-ADComputer -filter * | select DNSHostName $dnsservers = "192.168.1.1","192.168.1.2" foreach ($comp in $computers) { #lecture de l'ancienne valeur $adapters = gwmi -q "select * from win32_networkadapterconfiguration where ipenabled='true'" -ComputerName $comp.DNSHostName foreach ($adapter in $adapters) { #modification $adapter.setDNSServerSearchOrder($dnsservers) #Controle de la nouvelle valeur $adapters = gwmi -q "select * from win32_networkadapterconfiguration where ipenabled='true'" -ComputerName $comp #.DNSHostName $listeNew += New-Object -TypeName PSCustomObject -Property @{ 'Name' = $comp #.DNSHostName 'Address' = $adapter.DNSServerSearchOrder } } }

    $listeNew

    J'ai utilisé un script de ce genre pour mettre à jour plus de 150 serveurs virtuel.


    vendredi 31 janvier 2020 18:02
  • Bonjour,

    Est il possible de l'éteindre simplement au lieu de le rétrograder et que voulez vous dire par nettoyer les DNS ?

    Eteindre un DC poura génerer des incidents même s'il y a d'autre DC sur le site Active directory en cas ou par exemple vous avez une application qui tappe en dur sur un DC ou son IP est encore utiliser par les machines membres du domaine pour interroger la zone DNS du domaine en question.

    Avant d'arrêter un DC dans un environnement de production , il faut s'assurer que tout est bien basculé sur un autre DC.

    Est ce que je peux au moins reprendre IP de l'ancien serveur une fois l'autre éteint ?

    Reprendre l'IP est une bonne idée dans le cas ou l'ancien DC a été bien rétrogradé pour garder le même niveau d'ouverture du flux que l'ancien. Par contre il faut s'assurer de changer l'IP sur l'ancienne machine pour éviter le problème de conflit d'IP.


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    samedi 1 février 2020 18:38
    Modérateur
  • Merci à tous pour votre aide je prends note de tous vos conseils et mise en garde.

    Du coup de vais refaire ma procédure étape par étape en partant du principe  :

    1)De ne pas changer le nom du nouveau DC (trop de prise de risque pour pas grand chose).

    2) Et pour assurer une meilleure efficacité de transition au niveau routeur, poste client etc... je vais réattribuer l'ip de l'ancien DC vers le nouveau une fois que j'aurai bien transféré les rôles etc et rétrogradé l'ancien.

    J'ai ma petite idée pour tester avant de laisser tomber l'ancien DC.

    Je vais créer le nouveau DC et une machine cliente test qui va être déjà dans le domaine et liée au DC ancien par le DNS puis je vais changer son DNS et indiquer uniquement le nouveau DC en DNS primaire et voir si l'identification se fait comme cela avant de rétrograder l'ancien je verrai bien si l'identification se fait sur le nouveau DC. Qu'en pensez vous ?    (après votre réaction sur ce test je vais clôturer le sujet en marquant une réponse)

    Merci encore

    lundi 3 février 2020 08:20
  • Bonjour jessie-oignons,

    Pouvons-nous considérer que vous avez résolu votre problème avec le scénario proposé? 
    Si la réponse précédente vous a aidé, merci de marquer comme réponse.

    Cordialement,

    Biliana

    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votreproblème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    lundi 3 février 2020 09:49
  • Ok Biliana c'est fait.

    lundi 3 février 2020 09:56