Il est cinq heures du matin, j’émerge doucement du fond de mon lit de chambre d’hôtel. Je suis en mission.

La veille, j’ai préparé consciencieusement tout mon matériel d’intervention, j’ai relu mes fiches de procédures et bouclé ma trousse à outils.

Il est six heures. Je suis devant la porte… seul.

Je suis en déplacement au Maroc pour migrer le système informatique de notre école casablancaise (casaouia comme disent les jeunes). Il y a deux heures de décalage avec la France et mon équipe technique (restée en France) embauche à 8h.

J’entre dans l’école et je m’installe. Me voici devant mon ordinateur, branché sur Skype. Je serai les mains et les bras de mon équipe pendant les 5 prochains jours.

Voici le problème: il y a sur place 30 ordinateurs sous Windows XP, dont 20 en libre service, et un serveur sous GNU/linux faisant tourner Samba en contrôleur de domaine. J’ai pris la décision (relatée dans ce billet) de migrer tous les ordinateurs vers un contrôleur de domaine Windows 2008 R2. Cette décision valait pour les ordinateurs de mon école sur le campus français. Il est cohérent de l’appliquer également sur les autres sites distants gérés par mon service. Je m’attaque donc à une migration Samba vers un serveur Windows.

Toute la migration a été préparée à distance: le nouveau serveur est prêt (sous la forme d’une machine virtuelle WMware), les comptes Active Directory ont été créés, et les données des comptes Samba synchronisées par un Robocopy approprié. Il ne reste plus qu’à changer à la main le domaine de chaque ordinateur et à migrer les profils des utilisateurs.

Je commence donc par le plus simple: les ordinateurs en libre service. En effet, les étudiants n’ayant que des profils très simples, seules les machines sont à migrer. Un changement du mode domaine X vers le mode Workgroup TOTO, suivi d’un retour vers le mode domaine Y, suffit à faire basculer la machine d’un domaine à l’autre. J’en profite pour faire du nettoyage: CCleaner, défragmentation, Windows update, examen en profondeur par l’antivirus, etc.

Le passage sur les machines du personnel m’a posé plus de soucis. Notre procédure de migration de profils, réalisée lors de notre passage Novell Netware vers Windows Server, s’intéressait aux profils locaux créés à la volée sous Windows XP par le client Novell et faisait grand usage de la commande « moveuser.exe ».

Seulement voilà, cette commande ne fonctionne pas dans mon cas (migration entre deux domaines) et me retourne un message d’erreur mystérieux. Internet étant mon amis, j’y recherche la solution. Je n’ai pas le temps de trouver quelque chose d’exploitable car une solution telle que je les aime m’est fourni par un membre de mon équipe via Skype: « Et si on migrait chaque profil Samba vers un compte local (avec moveuser) et ensuite ce compte local vers AD (encore avec moveuser) ». Aussitôt proposé, aussitôt testé. Cette commande qui permet de migrer un profil local vers un compte de domaine permet également de faire l’inverse.

Voici donc l’astuce, seule raison d’être de ce billet:

– sur chaque poste, en tant qu’administrateur local, créer un compte local TOTO.

– exécuter: moveuser.exe « ANCIENDOMAINEnomutilisateur » TOTO /y /k

– puis: moveuser.exe TOTO « NOUVEAUDOMAINEnomutilisateur » /y /k

– supprimer le compte local TOTO

Cette astuce fonctionne pour une migration Samba <-> AD, ou Domaine1 <-> Domaine2 quelque soit le contrôleur de domaine (enfin je crois).

Elle sauvera peut-être la mise de quelques autres administrateurs windows débutants.

Pourquoi faire moins compliqué quand on peut faire plus simple.