none
Migration DC avec changement de domaine RRS feed

  • Question

  • Bonjour,

    JE dois remplacer un vieux DC sous Windows Server 2008 R2 avec renommage du domaine AD. Cette opération me paraît intrusive et un peu risquée. J'envisagerais plutôt de refaire un DC avec nouveau domaine et faire une migration via ADMT (non encore testé). Quels sont vos avis plus éclairés quant à ce choix ? Y'a t'il des précautions à prendre pour la migration via ADMT (j'ai déjà une procédure sur l'utilisation de l'outil) ?

    Voici les rôles du serveur actuel :

    Active Directory
    DHCP
    DNS
    IIS
    RDP
    Autorité de certification AD
    Serveur d'impression
    Serveur de fichiers
    GPO

    vendredi 3 avril 2020 10:13

Réponses

  • Ça fait beaucoup de choses pour un seul serveur.
    D'ailleurs certains rôles cohabitent sans que ça ne soit supporté par Microsoft (AD+RDS, AD+IIS...).

    La méthode de migration des services va surtout dépendre du nombres de postes qu'il y a dans le domaine.

    Il y a fort à parier que la migration de l'AD se fera avec des erreurs de réplication Sysvol.
    Obligé de réparer derrière avec la technique du burflag.

    Mais pourquoi pas, si ça évite d'avoir à migrer tous les profils des utilisateurs du domaine.


    Bonjour,

    ce type de configuration est supporté par Microsoft, mais n'est pas du tout recommandé !

    Installer un nouveau domaine sans reproduire les inconvénients de la configuration actuelle devrait être un objectif.

    => Je conseillerai d'utiliser HyperV sur le serveur principal et d'installer au moins 2 serveurs virtuels (voire 3), pour séparer le DC des autres fonctionnalités (Autorité CA, IIS et RDP).

    Le renommage de domaine n'est pas recommandé en "production", et de nombreux logiciels ne le supporteront pas bien. Et l'on peut difficilement tester à l'avance ! (un seul essai...)

    A bientôt,


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    samedi 4 avril 2020 12:12

Toutes les réponses

  • Bonjour Eric,

    Avant même de commencer la migration, surtout ton nouveau serveur, tu vas remettre tous les rôles en mode isopérimètre ou revoir l'infra ?

    Perso, j'opterai pour l'ajout du DC et renommage, sans connaitre l'ensemble de l'infra et tes contraintes c'est compliqué de donner une réponse pertinente

    Romain

    vendredi 3 avril 2020 12:40
  • Ça fait beaucoup de choses pour un seul serveur.
    D'ailleurs certains rôles cohabitent sans que ça ne soit supporté par Microsoft (AD+RDS, AD+IIS...).

    La méthode de migration des services va surtout dépendre du nombres de postes qu'il y a dans le domaine.

    Il y a fort à parier que la migration de l'AD se fera avec des erreurs de réplication Sysvol.
    Obligé de réparer derrière avec la technique du burflag.

    Mais pourquoi pas, si ça évite d'avoir à migrer tous les profils des utilisateurs du domaine.


    • Modifié SoftPE vendredi 3 avril 2020 12:44
    vendredi 3 avril 2020 12:43
  • Bonjour,

    Il y a une dizaine d'utilisateurs, peut être un peu plus. Un seul serveur, peu de GPO.Serveur installé il y a 12 ans environ, que je reprends. Je m'attends pour ma part à des soucis de migration.

    vendredi 3 avril 2020 13:14
  • Quitte à tout refaire sur une nouvelle infra toute propre, est-ce vraiment judicieux de s'embarquer sur ADMT ?

    Même si on maitrise déjà l'outil parfaitement, le gain de temps que cela apporte reste tout de même négligeable.

    vendredi 3 avril 2020 15:51
  • JE dois remplacer un vieux DC sous Windows Server 2008 R2 avec renommage du domaine AD. Cette opération me paraît intrusive et un peu risquée. 

    Ca risque de perturber un peu(enfin beaucoup) les certificats, si les noms sur les certificats ne correspondent pas au nouveau nom ... Quels est l'usage des certificats ?

    Quel est le but du renommage du domaine ? Ce n'est pas une opération simple, elle demande une bonne maitrise.

    Et tu as prévu quoi en remplacement ? Des VM? 

    Il y a fort à parier que la migration de l'AD se fera avec des erreurs de réplication Sysvol.
    Obligé de réparer derrière avec la technique du burflag.

    Burflags concerne l'ancienne réplication sysvol avec NTFRS, si c'est DFS-R qui est utilisé (par défaut depuis 2008). Le problème de réplication n'est pas un problème grave et ce résout généralement facilement.

    http://pbarth.fr/node/135

    Perso je referai un truc propre avec aussi peu d'utilisateurs.

    Sinon pour ADMT :

    http://pbarth.fr/node/106

    Des outils comme USMT peuvent faciliter la reprise des profils utilisateurs ( voir scanstate + loadstate /MU => scriptable).

    vendredi 3 avril 2020 19:19
  • Salut,

    J'ajoute a ce qui a été dit, ADMT et une telle opération demande une bonne maîtrise, mais vu le contexte et dans ton cas un seul serveur + quelques utilisateur te laisse le choix libre et te mets moins de pression.

    Tu peux repartir sur une nouvelle infra, au moins c'est propre.

    Donnes nous plus de détails sur ce que tu comptes faire, car j'ai lu tu veux garder plusieurs roles dans le meme serveur (Ad,RDS,IIS...) !!!! 

    Et surtout lis bien les liens de Philippe  ils sont très utiles et tu trouveras tout

    vendredi 3 avril 2020 23:26
  • Des outils comme USMT peuvent faciliter la reprise des profils utilisateurs ( voir scanstate + loadstate /MU => scriptable).

    La méthode USMT n'est pas la plus directe dans la mesure où les utilisateurs ne changent pas de machines.
    En effet, on perd le temps de calcul et de copie des données utilisateurs alors qu'elles restent "InPlace", sans parler des risques en cas d'espace disque insuffisant.

    Pour les migrations de profils vers un nouveau domaine sans changer les machines, un outil tiers et gratuit comme "Profile Wizard" permet de gagner un temps considérable.

    https://www.forensit.com/fr/




    • Modifié SoftPE vendredi 3 avril 2020 23:40
    vendredi 3 avril 2020 23:38
  • La méthode USMT n'est pas la plus directe dans la mesure où les utilisateurs ne changent pas de machines.
    En effet, on perd le temps de calcul et de copie des données utilisateurs alors qu'elles restent "InPlace", sans parler des risques en cas d'espace disque insuffisant.

    Oui USMT n'est pas la méthode la plus direct et il faut un stockage temporaire, mais il est possible d'utiliser des scriptsEn copiant tu peux également géré les éléments que tu récupères donc si tu as des profils "pas très propre". USMT peut s'utiliser même si entre les deux tu veux réinstaller proprement ton poste.

    Profil Wizard n'est gratuit que dans la version personal, à la base c'est un produit payant. 

    ProfilWizard ne fait que remplacer les ACL  (un peu comme ADMT). Ca reste une alternative à ADMT pour cette situation.

    ADMT n'a pas un grand intérêt dans son scénario, il est surtout intéressant si tu veux migrer tes serveurs de ressources (qui ne sont pas installé sur le contrôleur de domaine) et permet de migrer progressivement  sans interrompre l'intégralité des services. Il nécessite un travail préparatoire qui n'est pas rentable dans ce cas à première vue. 

    Les questions qui restent :

    - comment sera organisé la nouvelle infra ?

    - A quoi sert le serveur de certificat ? La migration du service de certificat peut représenter un problème, surtout si on part avec un nouveau nom.

    samedi 4 avril 2020 06:35
  • Ça fait beaucoup de choses pour un seul serveur.
    D'ailleurs certains rôles cohabitent sans que ça ne soit supporté par Microsoft (AD+RDS, AD+IIS...).

    La méthode de migration des services va surtout dépendre du nombres de postes qu'il y a dans le domaine.

    Il y a fort à parier que la migration de l'AD se fera avec des erreurs de réplication Sysvol.
    Obligé de réparer derrière avec la technique du burflag.

    Mais pourquoi pas, si ça évite d'avoir à migrer tous les profils des utilisateurs du domaine.


    Bonjour,

    ce type de configuration est supporté par Microsoft, mais n'est pas du tout recommandé !

    Installer un nouveau domaine sans reproduire les inconvénients de la configuration actuelle devrait être un objectif.

    => Je conseillerai d'utiliser HyperV sur le serveur principal et d'installer au moins 2 serveurs virtuels (voire 3), pour séparer le DC des autres fonctionnalités (Autorité CA, IIS et RDP).

    Le renommage de domaine n'est pas recommandé en "production", et de nombreux logiciels ne le supporteront pas bien. Et l'on peut difficilement tester à l'avance ! (un seul essai...)

    A bientôt,


    Thierry DEMAN-BARCELO. Office Apps&Services MVP. MCSE:Enterprise admin, Messaging, Server Infrastructure 2016(89 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate, Security Admin https://base.faqexchange.info

    samedi 4 avril 2020 12:12
  • Microsoft l'écrit noir sur blanc sur la kb 2799605 :

    "Remote Desktop Services role cannot co-exist with AD DS role on Windows Server 2012".

    Alors OK, c'est la version 2012 qui est mentionnée et non la 2008 qui n'est maintenant plus supportée et plus documentée non plus.

    samedi 4 avril 2020 21:03
  • Bonjour,

    Merci pour vos retours et informations. Le nouveau serveur sera sur Hyper V. Je verrai pour séparer les rôles dans la mesure du possible.

    L'avantage d'ADMT est de ne pas avoir à reconfigurer les profils utilisateurs sur les postes clients par rapport à nouveau domaine sans migration. Vu les circonstances et les contraintes imposées, il vaut mieux limiter les interventions sur les postes clients.

    lundi 6 avril 2020 07:43