Certains points sont améliorables, mais devraient convenir à la majorité pour une v1 :
- le script considère que le répertoire des profils est "documents and settings"
- le login et pass du compte utilisable pour joindre le domaine est en dur dans le script. car moins lisible que dans un fichier ini car c'est moins "lisible". Par la suite, on pourra, soit le coder dans un fichier, soit le passer en paramètre du script mais utiliser CPAU.exe pour crypter les arguments du .bat qui appelle le programme. (c.f CPAU pour de plus amples informations)
- Il y a un mode debug qui affiche dans le fichier log toutes les commandes qui sont exécutées [visiblement, ça l'a bien aidé
] - Il est possible d'inclure le nouvel utilisateur migré sur la machine dans les administrateurs locaux de celle ci
- Il est possible de de redémarrer la machine automatiquement après l'opération
- Le script gère le fait que les 2 utilisateurs (cible et destination) aient le même nom (dans ce cas le répertoire de l'utilisateur destination est suffixé par le nom du domaine, c'est bien sur un mécanisme standard windows)
- Le script remplace le nom de l'utilisateur dans le .reg exporté, en tout cas pour le chemin vers "documents and settings". Note :tugs s'interroge sur d'autres possibles emplacements dans le cas de GPO appliqués au compte et intestable ssur du SAMBA, celle-ci devraient s'appliquer correctement dans tous les cas puisque réappliquées à l'authentification utilisateur
- récupération du SID utilisateur pour le loggué
- "join domain" dans le nouveau domaine en utilisant l'API Win32
- Création d'un profil vide avec dummy
- Robocopy pour copier d'un profil à l'autre en excluant les Hives
- Changement des droits avec subinacl
- Export de la clé HKCU vers un fichier reg
- Remplacments des chemins dans le fichier reg
- Importation du Hive (ruche) du profil vide créé avec dummy (utilisateur de destination)
- Fusion du .reg modifé avec le Hive chargé
- déchargement du Hive
- Insertion du nouvel utilisateur dans les admins locaux et redémarrage si activé.



Commentaires
Salutations et merci d'avance de vos retours.
J'ai testé le script en environnement réel (client) la semaine dernière. Migration impeccable pour la plupart des postes Windows XP / Windows 2000.
Migration impossible par contre pour vista. Je ferais la modification dans la 1.1, rien de compliqué (il suffit de tenir compte du répertoire des profils utilisateurs en usant de la variable d'environnement qui va bien plutôt que de mettre ça en dur) mais les postes Vista étaient hors scope.
Autre modification à passée, il faut ajouter le switch à Robocopy pour qu'il évite de tenter un million de fois une copie en cas de fichier verrouiller. Étant donné que le script est fait pour fonctionner pour un compte loggué, certains fichiers peuvent être verrouiller (j'ai eu le cas avec un .db verrouiller par un soft chargé en systray au démarrage).
voila pour l'instant . (membre de PM ? faut passer un entretien ? :p)
Tugs"Quels sont vos prétentions salariales M Tugs?"
Bénévole? Enrôlé ! Je penses pas que le racisme anti-samba ait court chez moi
Blague à part, je suis sur que les gentils lecteurs nous feront un feedback rapide de l'outil, afin de pouvoir canoniser ta proc
JonathanCet outil m'a l'air particulièrement utile :D
Je suis en pleins dans une telle migration a quelques détails près. J'ai besoin d'une petite précision :
J'ai un serveur sous 2000 avec des utilisateurs en TSE qui n'est pas dans l'AD.
J'ai un serveur sous 2008 en preparation qui sera dans l'AD pour remplacer le 2000
Est-ce que l'outil est adapté pour migrer les profils d'un serveur vers un autre.
D'après ce que j'ai cru comprendre : non. Mais au cas ou je préfère me renseigner :D
Dans tous les cas merci
pour les postes en local c'est deja un grand grand pas en avant...
MathieuBonjour Mathieu,
Gourmand! On migre déjà le profil, et en plus tu veux le déplacer de serveur !
Malheureusement, aucun outil ne le fait (et à ma connaissance, aucne suite intégrée non plus) mais je ne penses pas que ça soit sorcier...
D'autant plus que je penses que l'on peut séparer l'opération en deux.
Je suppose que si :
- Tu exporte la clé profileList vers l'autre serveur
- Tu robocopy le profil en conservant les ACL
- Tu migre le profil avec Tugs ou W2D301 (puisque tu utilise AD et non SAMBA, c'est faisable)
tu devrais retomber sur tes pattes
++
JonathanBonjour Jonathan,
Merci pour les infos :D
J'ai encore quelques question concernant les différentes opérations :
1: Dans la clé profileList, est-ce que je peux modifier l'emplacement du dossier (dans 2008 on n'utilise plus Documents and Settings) ?
2: Quand j'utilise Tugs pour migrer mes profils, a la fin de la manip je les ai en double (1 pour le local et 1 pour le domaine ?)
3: Le fait de copier directement des profils de Windows 2000 ne posera pas de problèmes lorsqu'ils vont etre chargés par le 2008 ?
A mon avis pour répondre a toutes ces questions je vais monter un serveur virtuel dès demain et faire quelques tests.
Merci
Mathieu++
re Mathieu,
1- oui, c'est juste un chemin à changer, donc je ne penses pas qu'il y ait un soucis
Effectivement, la meilleure idée est de monter un serveur virtuel pour tout ça 
2- ça vaut le coup de poser la question à Tugs mais je suppose que le 2e profil (comme pour mes w2dX) est le profil temporaire,créé pour que le nouvel utilisateur (du domaine, pas local ou ancien dom) retrouve ses enregistrements dynamiques créés dans le registre. En théorie l'outil change la valeur vers le chemin de l'ancien profil après donc il doit correctement récupérer ses billes
3- Aucune idée
++
JonathanBonjour à tous,
Je suis en train de migrer le domaine de mon entreprise et l'outil D2D tombe à pic.
Malheureusement, D2D ne gère pas les postes en vista.
Comme la 1.1 n'est pas sortie, existe-t-il une techinique de contournement avec la 1.0a ?
Merci d'avance, Steph
stephHello Steph :
si tu fais du Samba to AD, tu peux :
- soit attendre que Tugs prépare une nouvelle version
- soit récupérer les sources de l'actuelle ainsi que ceux de W2D 3.021 et adapter les portions de la section vista/2008 pour les intégrer. En plus ça fera une contribution supplémentaire à PM.Net
Bien sur, si tu fais du Workgroup to AD, tu as d'autres outils de disponibles sur le blog.
A bientôt!
JonathanSalut par ici,
J'ai réussi à le faire fonctionner sous vista, il suffit de désactiver la console de contrôle d'accès, car il bloque le script du robocopy.
Il arrive aussi par moment que l'application reste bloqué sur les 10%, ce qui veut dire qu'il reste bloqué sur le robocopy, et que celui-ci fait en boucle des tentatives de copies de fichiers corrompus ou dont les droits d'accès l'empêchent de copier.
La solution est de tuer le process du robocopy, laisser finir d2dmigrate, puis passer en mode sans échecs, faire la copy via robocopy manuellement avec les arguments /mir /e /r:0
Sinon, j'aimerai pour un projet de développement, coder cette application en windows form en C# (.net). J'aimerai savoir si le seul fichier disponible dont le code est visible est le d2migrate.au3 ? Est-ce que dedans (je ne connais pas le langage utilisé pour le faire, mais je le comprends à peu près), il y a tous les processus du fonctionnement de l'application ?
ddangelSi vous pouviez me fournir de la documentation pour que je puisse coder ça en C#, et si en plus vous connaissiez C#, m'indiquer les bibliothèques sur lesquels je puissent m'appuyer pour avancer dans mon projet de développement
En effet, je débute seulement dans ce langage objet :p
@ddangel : Bonjour à toi et merci pour le retour! Je suppose en revanche qu'il faut aussi modifier les paths de profil puisque ceux-ci tappent sur %SystemDrive%\Documents and Settings\.
d2dmigrate est effectivement le seul source intéressant et exploitable. Il est fait en AutoIT avec quelques appels com pour l'ajout au domaine cible etc... (Tugs, arrête moi si je dis une bêtise). Par contre pour le reste... c'est un projet ouvert, donc à moins que Tugs n'est documenté son code je ne saurais quoi te dire.
Bon courage en C#, donne des nouvelles de tes avancées
A bientôt
JonathanSalut,
Non, pas besoin de changer les paths, ce qui est bien avec vista et 7, c'est qu'ils reconnaîssent les anciens chemins de win xp, ils les mettent automatiquement dans le path adéquats des utilisateurs.
Ok pour le reste, M. Tug a commenté son code, j'arrive à le comprendre à peu près, le problème était de savoir s'il y avait autre source que le fichier d2dmigrate.au3
++
ddangelBonjour,
Clémentvotre application m'intéresse grandement, mais je rencontre un problème d'utilisation.
Peut être que je ne suis pas bien les étapes.
J'ai procédé comme ceci:
Sur une session du domaine je lance "d2dmigrate.exe domainefutur loginfutur passwordfutur".
Je met le poste sur le nouveau domaine, je me log avec le login password utilisé précédemment. mais windows créé et utilise le dossier "C:\Documents and Settings\login.domaine.000" alors que le dossier a bien "C:\Documents and Settings\login.domaine" été crée par le script.
Merci de votre aide.