Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur Installation ADMT - Migration des comptes usagers

ADMT - Migration des comptes usagers

9 réponses
Avatar
Glenn Gagné
Bonjour,

Suite à la migration et préparation des comptes ordinateurs dans mon nouveau
domaine
(NT4 vers 2003)

La migration des comptes au niveau serveur (transfert des comptes) ça va
plutot bien. Il n'y a que quelques points qui ne fonctionnent pas, mais sans
trop causer de problèmes dans mon cas. Je vais quand même les énumérer avec
ma procédure.

1- ... préallables décrits dans mon message précédent (ADMT - Migration des
comptes ordinateurs)

2- Outil de migration Active Directory

3- Action -> Assistant Migration des comptes d'utilisateurs

4- Sélection domaine source et cible

5- Sélectionner les utilisateurs dans le domaine (et non depuis un fichier
include)

6- Ajouter... (dans ce cas-ci un seul comme test, nommé: manonroy)

7- Sélection d'un OU, dans mon cas j'ai créé un qui s'appelle "Usagers de
mon entreprise".

8- Type de mot de passe, utilisation "Générer des mots de passe complexes"
car les mots de passe anciennement utilisés ne respectent pas un minimum de
sécurité... donc une pierre 2 coups !

9- Staut: Cible identique à la source ET aucun crochet pour (désactiver les
comptes sources, nb de jours avant désactivation et effectuer la migration
des SID.

10- Aucun crochet (pas sélectionné) pour Traduire les profils itinérants,
mettre à jour les droits, effectuer la migration des groupes associés ET
sélection de "Corriger les appartenances du groupe d'utilisateurs". Ce qui
devrait donner que tous les usagers importés seront dans le groupe
"utilisateurs du domaine" sans aucun groupe car je dois refaire la structure
des groupes de toutes manière car elle était pas terrible !

11- Ne pas migrer la source si un conflit existe

12- Terminer !

13- Résultat:

Examiné: 1
Copié: 1
Erreurs: 0

Les choses qui ne fonctionnaient pas étaient la migration des mots de passe,
j'ai donc opté pour la création de nouveau mots de passe avec meilleur
sécurité !

Je vais remettre une liste des mots de passe lors de la migration pour
qu'ils ensuite re-choississent un nouveau mot de passe.

------------------------

Mon problème est au niveau des données du compte sur les postes clients.
Tout ce qui se retrouvent sous C:\Documents & Settings\manonroy de l'ancien
domaine.

Lors de l'ouverture de la nouvelle session sous le nouveau domaine, le poste
client (Windows 2000) créé un nouveau dossier C:\Documents &
Settings\manonroy.NEW_DOMAIN... et mon usager n'a plus ses données.

J'ai alors tenté de copier les données de cette manière (en ouvrant une
session admin sur le poste local):

1- Profils utilisateurs
2- Sélection de l'ancien compte
3- Copier dans...
4- Copier le profile dans "C:\Documents & Settings\manonroy.NEW_DOMAIN" et
sélectionner NEW_DOMAIN\manonroy pour autorisation à utiliser !

Je redémarre la session manonroy du nouveau domaine, tous les fichiers
semblent là !!! Mais non... Outlook ne fonctionne plus et les mots de passe
pour divers programmes ne sont plus là non plus.

Pourquoi les fichiers PST ne sont pas copier ?
Pourquoi les mots de passe non plus ?

Est-ce que j'utilise la bonne méthode pour la migration de mes usagers, ou
bien est-ce possible de conserver l'ancien dossier "Documents and Setings" ?

Merci de votre aide
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Jonathan Bismuth
Hello Glenn,

A ce stade (clonage des utilisateurs), il te faut prendre 2 points en
considération :

1- tant que la translation de la sécurité n'a pas eu lieu, l'utilisateur
passe par l'historique Sid pour se connecter à son ancien profil, si tu ne
l'active pas, ça pose fatalement problème.
2- une fois que la translation a eu lieu, le repermissionnement des fichiers
et clés de registre permettra naturellement la récupération des fichiers
pour l'utilisateur du nouveau domaine, sans passer par l'historique (il
conviendra alors de purger celui-ci)

Etant un peu out aujourd'hui, mes souvenirs restent brumeux, as tu suivi ma
procédure de migration ?
(http://jonathan.bismuth.free.fr/Infrastructure/restruct/intro.htm)

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:
O9OYWT$$
Bonjour,

Suite à la migration et préparation des comptes ordinateurs dans mon
nouveau
domaine
(NT4 vers 2003)

La migration des comptes au niveau serveur (transfert des comptes) ça va
plutot bien. Il n'y a que quelques points qui ne fonctionnent pas, mais
sans
trop causer de problèmes dans mon cas. Je vais quand même les énumérer
avec
ma procédure.


...
Avatar
Glenn Gagné
Merci Jonathan,

Si je comprends bien le point #1: Lorsque j'importe les compte dans ADMT, si
je coche "effectuer la migration des SID". Les utilisateurs à la réouverture
sous le nouveau domaine utiliseront automatiquement le même dossier
Documents and Settings qu'avant ?

S'il y a un problème durant la migration... Est-ce que l'utilisateur pourra
toujours ré-ouvrir une session avec l'ancien domaine dans le même Documents
& Settings ?


Pour le point #2 j'ai pas trop compris ton explication... Tu dis que lorsque
la translation (importation du compte de l'ancien domaine vers le nouveau au
point de vue du serveur ?) le SID doit être purgé ? Purgé de quoi sur quel
ordi ?

Merci encore.

"Jonathan Bismuth" a écrit
dans le message de news:ejQTNY$$
Hello Glenn,

A ce stade (clonage des utilisateurs), il te faut prendre 2 points en
considération :

1- tant que la translation de la sécurité n'a pas eu lieu, l'utilisateur
passe par l'historique Sid pour se connecter à son ancien profil, si tu ne
l'active pas, ça pose fatalement problème.
2- une fois que la translation a eu lieu, le repermissionnement des


fichiers
et clés de registre permettra naturellement la récupération des fichiers
pour l'utilisateur du nouveau domaine, sans passer par l'historique (il
conviendra alors de purger celui-ci)

Etant un peu out aujourd'hui, mes souvenirs restent brumeux, as tu suivi


ma
procédure de migration ?
(http://jonathan.bismuth.free.fr/Infrastructure/restruct/intro.htm)

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:
O9OYWT$$
> Bonjour,
>
> Suite à la migration et préparation des comptes ordinateurs dans mon
> nouveau
> domaine
> (NT4 vers 2003)
>
> La migration des comptes au niveau serveur (transfert des comptes) ça va
> plutot bien. Il n'y a que quelques points qui ne fonctionnent pas, mais
> sans
> trop causer de problèmes dans mon cas. Je vais quand même les énumérer
> avec
> ma procédure.
...




Avatar
Jonathan Bismuth
Re Glenn,

Si je comprends bien le point #1: Lorsque j'importe les compte dans ADMT,
si
je coche "effectuer la migration des SID". Les utilisateurs à la
réouverture
sous le nouveau domaine utiliseront automatiquement le même dossier
Documents and Settings qu'avant ?



C'est exactement ça.
Toutefois, je t'engage, pour faire propre et ne pas tomber en conflit, à
supprimer le compte de test que tu as migré et de retester ensuite avec le
Sid history activé.

S'il y a un problème durant la migration... Est-ce que l'utilisateur
pourra
toujours ré-ouvrir une session avec l'ancien domaine dans le même
Documents
& Settings ?



Absolument. Une migration n'est pas, à proprement parler, un déplacement
mais plutôt un clonage puis repermissionnement.
Le compte de l'ancien domaine aura donc toujours accès à son compte jusqu'au
moment ou tu aura terminé la "translation de sécurité", celle-ci remplaçant
ancien_domaineuser par nouveau_domaineuser dans les ACLs

Pour le point #2 j'ai pas trop compris ton explication... Tu dis que
lorsque
la translation (importation du compte de l'ancien domaine vers le nouveau
au
point de vue du serveur ?) le SID doit être purgé ? Purgé de quoi sur
quel
ordi ?



Il s'agit de vider un attribut de l'utilisateur dans l'Active Directory
contenant l'ancien /les anciens Sid de l'utilisateur pré-migration. On en
reparle APRES ta migration ;)

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:
eknTJg$$
Merci Jonathan,

Si je comprends bien le point #1: Lorsque j'importe les compte dans ADMT,
si
je coche "effectuer la migration des SID". Les utilisateurs à la
réouverture
sous le nouveau domaine utiliseront automatiquement le même dossier
Documents and Settings qu'avant ?

S'il y a un problème durant la migration... Est-ce que l'utilisateur
pourra
toujours ré-ouvrir une session avec l'ancien domaine dans le même
Documents
& Settings ?


Pour le point #2 j'ai pas trop compris ton explication... Tu dis que
lorsque
la translation (importation du compte de l'ancien domaine vers le nouveau
au
point de vue du serveur ?) le SID doit être purgé ? Purgé de quoi sur
quel
ordi ?

Merci encore.

"Jonathan Bismuth" a écrit
dans le message de news:ejQTNY$$
Hello Glenn,

A ce stade (clonage des utilisateurs), il te faut prendre 2 points en
considération :

1- tant que la translation de la sécurité n'a pas eu lieu, l'utilisateur
passe par l'historique Sid pour se connecter à son ancien profil, si tu
ne
l'active pas, ça pose fatalement problème.
2- une fois que la translation a eu lieu, le repermissionnement des


fichiers
et clés de registre permettra naturellement la récupération des fichiers
pour l'utilisateur du nouveau domaine, sans passer par l'historique (il
conviendra alors de purger celui-ci)

Etant un peu out aujourd'hui, mes souvenirs restent brumeux, as tu suivi


ma
procédure de migration ?
(http://jonathan.bismuth.free.fr/Infrastructure/restruct/intro.htm)

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:
O9OYWT$$
> Bonjour,
>
> Suite à la migration et préparation des comptes ordinateurs dans mon
> nouveau
> domaine
> (NT4 vers 2003)
>
> La migration des comptes au niveau serveur (transfert des comptes) ça
> va
> plutot bien. Il n'y a que quelques points qui ne fonctionnent pas, mais
> sans
> trop causer de problèmes dans mon cas. Je vais quand même les énumérer
> avec
> ma procédure.
...








Avatar
Glenn Gagné
Merci pour les réponses... mais ça ne marche pas pour ce qui est de
ré-utiliser le même dossier "Documents and Settings" sur le poste client...

J'ai supprimé le compte de test migré sur 2003, j'ai recréé la migration de
celui-ci avec le SID inclus, tout s'est bien passé.

Je suis allé sur la station client Windows 2000, j'ai ouvert une "session
new_domainmanonroy" et je me suis retrouvé avec un nouveau dossier :
"Documents and Settingsmanonroy.NEW_DOMAIN" au-lieu de continuer à être
dans le même (ancien)

Par contre une chose est différente ! Vu que le SID a été copié... il a les
même "droits" que l'ancien usager je peux accéder à l'ancien dossier
"Documents and Settingsmanonroy" contrairement aux autres dossiers
utilisateurs qui se heurtent à "Accès Refusé".

Donc le SID fait suivre correctement la correspondance usager, mais ma
station client refuse l'utilisation de l'ancien dossier utilisateur.

NOTE: Tous mes profiles sont de type local (et non itinérants)

Est-ce que tu vois pourquoi ça passe pas ?




"Jonathan Bismuth" a écrit
dans le message de news:%23M2tOq$$
Re Glenn,

> Si je comprends bien le point #1: Lorsque j'importe les compte dans


ADMT,
> si
> je coche "effectuer la migration des SID". Les utilisateurs à la
> réouverture
> sous le nouveau domaine utiliseront automatiquement le même dossier
> Documents and Settings qu'avant ?

C'est exactement ça.
Toutefois, je t'engage, pour faire propre et ne pas tomber en conflit, à
supprimer le compte de test que tu as migré et de retester ensuite avec le
Sid history activé.

> S'il y a un problème durant la migration... Est-ce que l'utilisateur
> pourra
> toujours ré-ouvrir une session avec l'ancien domaine dans le même
> Documents
> & Settings ?

Absolument. Une migration n'est pas, à proprement parler, un déplacement
mais plutôt un clonage puis repermissionnement.
Le compte de l'ancien domaine aura donc toujours accès à son compte


jusqu'au
moment ou tu aura terminé la "translation de sécurité", celle-ci


remplaçant
ancien_domaineuser par nouveau_domaineuser dans les ACLs

> Pour le point #2 j'ai pas trop compris ton explication... Tu dis que
> lorsque
> la translation (importation du compte de l'ancien domaine vers le


nouveau
> au
> point de vue du serveur ?) le SID doit être purgé ? Purgé de quoi sur
> quel
> ordi ?

Il s'agit de vider un attribut de l'utilisateur dans l'Active Directory
contenant l'ancien /les anciens Sid de l'utilisateur pré-migration. On en
reparle APRES ta migration ;)

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:
eknTJg$$
> Merci Jonathan,
>
> Si je comprends bien le point #1: Lorsque j'importe les compte dans


ADMT,
> si
> je coche "effectuer la migration des SID". Les utilisateurs à la
> réouverture
> sous le nouveau domaine utiliseront automatiquement le même dossier
> Documents and Settings qu'avant ?
>
> S'il y a un problème durant la migration... Est-ce que l'utilisateur
> pourra
> toujours ré-ouvrir une session avec l'ancien domaine dans le même
> Documents
> & Settings ?
>
>
> Pour le point #2 j'ai pas trop compris ton explication... Tu dis que
> lorsque
> la translation (importation du compte de l'ancien domaine vers le


nouveau
> au
> point de vue du serveur ?) le SID doit être purgé ? Purgé de quoi sur
> quel
> ordi ?
>
> Merci encore.
>
> "Jonathan Bismuth" a écrit
> dans le message de news:ejQTNY$$
>> Hello Glenn,
>>
>> A ce stade (clonage des utilisateurs), il te faut prendre 2 points en
>> considération :
>>
>> 1- tant que la translation de la sécurité n'a pas eu lieu,


l'utilisateur
>> passe par l'historique Sid pour se connecter à son ancien profil, si tu
>> ne
>> l'active pas, ça pose fatalement problème.
>> 2- une fois que la translation a eu lieu, le repermissionnement des
> fichiers
>> et clés de registre permettra naturellement la récupération des


fichiers
>> pour l'utilisateur du nouveau domaine, sans passer par l'historique (il
>> conviendra alors de purger celui-ci)
>>
>> Etant un peu out aujourd'hui, mes souvenirs restent brumeux, as tu


suivi
> ma
>> procédure de migration ?
>> (http://jonathan.bismuth.free.fr/Infrastructure/restruct/intro.htm)
>>
>> --
>> Jonathan BISMUTH
>> MCSE 2000/ADSI-AutoIT Scripter
>> Transcript (ID: 691839, code: MCSE2000)
>> www.portail-mcse.net
>> pour me contacter http://cerbermail.com/?fCeVUi7Icd
>>
>>
>> "Glenn Gagné" a écrit dans le message de


news:
>> O9OYWT$$
>> > Bonjour,
>> >
>> > Suite à la migration et préparation des comptes ordinateurs dans mon
>> > nouveau
>> > domaine
>> > (NT4 vers 2003)
>> >
>> > La migration des comptes au niveau serveur (transfert des comptes) ça
>> > va
>> > plutot bien. Il n'y a que quelques points qui ne fonctionnent pas,


mais
>> > sans
>> > trop causer de problèmes dans mon cas. Je vais quand même les


énumérer
>> > avec
>> > ma procédure.
>> ...
>>
>>
>
>




Avatar
Jonathan BISMUTH
Hum...
de un : le truc c'est que tu as déjà ajouté ta machine dans le nouveau
domaine, donc l'admin de l'ancien domaine n'est pas administrateur d'un
poste du nouveau.

de deux : il voit que l'utilisateur manonroy a 2 profils du fait du Sid
history. Il est donc OK pour le fait que cet utilisateur est propriétaire...
de deux profils.
Comme tu as déjà tenté une authentification, je suppose que l'utilisateur
est existant dans la base de registre, avec un chemin de profil dans la clé
"profilepath" spécifié pour l'autre... il le recrée donc à chaque fois.

On va faire un test :
lance le registre et rend toi dans
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList
tu a une tonne de sous clés sous la forme S-1-[...], parcours la liste
jusqu'à tomber sur la clé ou le profile indiqué est celui qui est recréé à
chaque fois.
change le chemin par celui de profil à remapper.

Logue toi ensuite avec le nouvel utilisateur migré, est ce que ceci corrige
le problème?

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Glenn Gagné" a écrit dans le message de news:
%
Bon j'ai fait d'autres tests.

Je me suis assuré que la migration du profil se faisait bien avec ADMT
(migration ordinateurs).

Là je trouve ça bizarre....

Sur la station client, j'ouvre une session avec mon admin réseau pour voir
les profils présents.

J'observe qu'il y a 2 profils existants au même nom:

NEW_DOMAINmanonroy

et que l'ancien profil

OLD_DOMAINmanonroy n'existe plus !!!!

Je supprime donc l'un des 2 profils en double (celui avec le moins gros
qui
correspond à une taille de profil "vierge").

Je ré-essai d'ouvrir une session avec manonroy du nouveau domaine, mais il
re-créé toujours un nouveau profil...

Alors, je ré-ouvre une session avec manonroy de l'ancien domaine,
bizarrement je retrouve mon ancien profile tout ok.... et si je retourne
dans la liste des profils, le nom du profils en double est redevenu avec
le
nom de l'ancien profil.

VOIR IMAGE EN ATTACHEMENT POUR LES DOUBLONS

NEW_DOMAIN = CDBSTCOME
OLD_DOMAIN = CONFECT

Et là... je veux recommencer le test. Encore plus étrange, avec mon admin
de
mon ancien domaine que j'ai utilisé tantôt, je ne peux plus effacer le
profil NEW_DOMAINmanonroy, ni OLD_DOMAINmanonroy ....

À l'aide

P.S. J'ai suivi ta procédure pour les profils.





Avatar
Glenn Gagné
Salut Jonathan,

Et oui ça fonctionne en changeant le PATH dans la clé du profile ! Mais ça
comme pas le choix en lui forçant la main comme ça ;o)

Une chose que j'ai remarqué de différent entre les profiles que j'avais avec
NT4 et ceux de 2003. Un nouvel enregistrement de plus dans cette clé pour le
GUID !

Aucun GUID existant dans la clé profile avant, est-ce que tu sais un peu son
utilité ?

Bon maintenant je vais réessayer le tout depuis un autre poste test... pour
voir si ça va passer sans avoir besoin de changer la clé ! Je te redonne des
nouvelles.

Glenn Gagné
Technicien MCP/TI


"Jonathan BISMUTH" a écrit dans le message de
news:OTV$
Hum...
de un : le truc c'est que tu as déjà ajouté ta machine dans le nouveau
domaine, donc l'admin de l'ancien domaine n'est pas administrateur d'un
poste du nouveau.

de deux : il voit que l'utilisateur manonroy a 2 profils du fait du Sid
history. Il est donc OK pour le fait que cet utilisateur est


propriétaire...
de deux profils.
Comme tu as déjà tenté une authentification, je suppose que l'utilisateur
est existant dans la base de registre, avec un chemin de profil dans la


clé
"profilepath" spécifié pour l'autre... il le recrée donc à chaque fois.

On va faire un test :
lance le registre et rend toi dans
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows


NTCurrentVersionProfileList
tu a une tonne de sous clés sous la forme S-1-[...], parcours la liste
jusqu'à tomber sur la clé ou le profile indiqué est celui qui est recréé à
chaque fois.
change le chemin par celui de profil à remapper.

Logue toi ensuite avec le nouvel utilisateur migré, est ce que ceci


corrige
le problème?

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Glenn Gagné" a écrit dans le message de news:
%
> Bon j'ai fait d'autres tests.
>
> Je me suis assuré que la migration du profil se faisait bien avec ADMT
> (migration ordinateurs).
>
> Là je trouve ça bizarre....
>
> Sur la station client, j'ouvre une session avec mon admin réseau pour


voir
> les profils présents.
>
> J'observe qu'il y a 2 profils existants au même nom:
>
> NEW_DOMAINmanonroy
>
> et que l'ancien profil
>
> OLD_DOMAINmanonroy n'existe plus !!!!
>
> Je supprime donc l'un des 2 profils en double (celui avec le moins gros
> qui
> correspond à une taille de profil "vierge").
>
> Je ré-essai d'ouvrir une session avec manonroy du nouveau domaine, mais


il
> re-créé toujours un nouveau profil...
>
> Alors, je ré-ouvre une session avec manonroy de l'ancien domaine,
> bizarrement je retrouve mon ancien profile tout ok.... et si je retourne
> dans la liste des profils, le nom du profils en double est redevenu avec
> le
> nom de l'ancien profil.
>
> VOIR IMAGE EN ATTACHEMENT POUR LES DOUBLONS
>
> NEW_DOMAIN = CDBSTCOME
> OLD_DOMAIN = CONFECT
>
> Et là... je veux recommencer le test. Encore plus étrange, avec mon


admin
> de
> mon ancien domaine que j'ai utilisé tantôt, je ne peux plus effacer le
> profil NEW_DOMAINmanonroy, ni OLD_DOMAINmanonroy ....
>
> À l'aide
>
> P.S. J'ai suivi ta procédure pour les profils.
>
>
>




Avatar
Jonathan Bismuth
Re Glenn,

pour faire bien, commence par migrer le compte user et fait un test (pour
Sid History) puis translate sa sécurité (pour le repermissionnement). Si
tout est bon, il n'y a plus qu'à migrer son poste avant de passer au "gros"
: migration des serveurs.
Il n'y a avec cet ordre là aucune raison de toucher à quoi que ce soit dans
le registre

PS : avec tout ça, n'oublie quand même pas les groupes :)

Cordialement,

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:

Salut Jonathan,

Et oui ça fonctionne en changeant le PATH dans la clé du profile ! Mais ça
comme pas le choix en lui forçant la main comme ça ;o)

Une chose que j'ai remarqué de différent entre les profiles que j'avais
avec
NT4 et ceux de 2003. Un nouvel enregistrement de plus dans cette clé pour
le
GUID !

Aucun GUID existant dans la clé profile avant, est-ce que tu sais un peu
son
utilité ?

Bon maintenant je vais réessayer le tout depuis un autre poste test...
pour
voir si ça va passer sans avoir besoin de changer la clé ! Je te redonne
des
nouvelles.

Glenn Gagné
Technicien MCP/TI


"Jonathan BISMUTH" a écrit dans le message de
news:OTV$
Hum...
de un : le truc c'est que tu as déjà ajouté ta machine dans le nouveau
domaine, donc l'admin de l'ancien domaine n'est pas administrateur d'un
poste du nouveau.

de deux : il voit que l'utilisateur manonroy a 2 profils du fait du Sid
history. Il est donc OK pour le fait que cet utilisateur est


propriétaire...
de deux profils.
Comme tu as déjà tenté une authentification, je suppose que l'utilisateur
est existant dans la base de registre, avec un chemin de profil dans la


clé
"profilepath" spécifié pour l'autre... il le recrée donc à chaque fois.

On va faire un test :
lance le registre et rend toi dans
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows


NTCurrentVersionProfileList
tu a une tonne de sous clés sous la forme S-1-[...], parcours la liste
jusqu'à tomber sur la clé ou le profile indiqué est celui qui est recréé
à
chaque fois.
change le chemin par celui de profil à remapper.

Logue toi ensuite avec le nouvel utilisateur migré, est ce que ceci


corrige
le problème?

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Glenn Gagné" a écrit dans le message de news:
%
> Bon j'ai fait d'autres tests.
>
> Je me suis assuré que la migration du profil se faisait bien avec ADMT
> (migration ordinateurs).
>
> Là je trouve ça bizarre....
>
> Sur la station client, j'ouvre une session avec mon admin réseau pour


voir
> les profils présents.
>
> J'observe qu'il y a 2 profils existants au même nom:
>
> NEW_DOMAINmanonroy
>
> et que l'ancien profil
>
> OLD_DOMAINmanonroy n'existe plus !!!!
>
> Je supprime donc l'un des 2 profils en double (celui avec le moins gros
> qui
> correspond à une taille de profil "vierge").
>
> Je ré-essai d'ouvrir une session avec manonroy du nouveau domaine, mais


il
> re-créé toujours un nouveau profil...
>
> Alors, je ré-ouvre une session avec manonroy de l'ancien domaine,
> bizarrement je retrouve mon ancien profile tout ok.... et si je
> retourne
> dans la liste des profils, le nom du profils en double est redevenu
> avec
> le
> nom de l'ancien profil.
>
> VOIR IMAGE EN ATTACHEMENT POUR LES DOUBLONS
>
> NEW_DOMAIN = CDBSTCOME
> OLD_DOMAIN = CONFECT
>
> Et là... je veux recommencer le test. Encore plus étrange, avec mon


admin
> de
> mon ancien domaine que j'ai utilisé tantôt, je ne peux plus effacer le
> profil NEW_DOMAINmanonroy, ni OLD_DOMAINmanonroy ....
>
> À l'aide
>
> P.S. J'ai suivi ta procédure pour les profils.
>
>
>








Avatar
Glenn Gagné
Merci Jonathan,

Je crois que c'est ça l'erreur... j'ai migré les comptes ordinateurs avant
les comptes usagers !

Je vais refaire le test.

---------------------------------

J'ai une autre chose de bizarre... dans la documentation que tu as fait pour
migrer NT4 vers 2003, dans la section 2.2 pour la migration des groupes à la
fin tu as ajouté un printscreen de la fenêtre de l'assistant de migration,
dans le fenêtre on voit bien que dans le bas de cette fenêtre il y a 3 choix
"Ne pas renommer les comptes, Renommer avec le préfixe et renommer avec le
suffixe.

Moi dans sur mon serveur je n'ai pas ces choix dans cette fenêtre, je n'ai
que les 4 choix à cocher ???? Peut être une différence de version de ADMT ?

-----------------------------------

"Jonathan Bismuth" a écrit
dans le message de news:
Re Glenn,

pour faire bien, commence par migrer le compte user et fait un test (pour
Sid History) puis translate sa sécurité (pour le repermissionnement). Si
tout est bon, il n'y a plus qu'à migrer son poste avant de passer au


"gros"
: migration des serveurs.
Il n'y a avec cet ordre là aucune raison de toucher à quoi que ce soit


dans
le registre

PS : avec tout ça, n'oublie quand même pas les groupes :)

Cordialement,

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:

> Salut Jonathan,
>
> Et oui ça fonctionne en changeant le PATH dans la clé du profile ! Mais


ça
> comme pas le choix en lui forçant la main comme ça ;o)
>
> Une chose que j'ai remarqué de différent entre les profiles que j'avais
> avec
> NT4 et ceux de 2003. Un nouvel enregistrement de plus dans cette clé


pour
> le
> GUID !
>
> Aucun GUID existant dans la clé profile avant, est-ce que tu sais un peu
> son
> utilité ?
>
> Bon maintenant je vais réessayer le tout depuis un autre poste test...
> pour
> voir si ça va passer sans avoir besoin de changer la clé ! Je te redonne
> des
> nouvelles.
>
> Glenn Gagné
> Technicien MCP/TI
>
>
> "Jonathan BISMUTH" a écrit dans le message de
> news:OTV$
>> Hum...
>> de un : le truc c'est que tu as déjà ajouté ta machine dans le nouveau
>> domaine, donc l'admin de l'ancien domaine n'est pas administrateur d'un
>> poste du nouveau.
>>
>> de deux : il voit que l'utilisateur manonroy a 2 profils du fait du Sid
>> history. Il est donc OK pour le fait que cet utilisateur est
> propriétaire...
>> de deux profils.
>> Comme tu as déjà tenté une authentification, je suppose que


l'utilisateur
>> est existant dans la base de registre, avec un chemin de profil dans la
> clé
>> "profilepath" spécifié pour l'autre... il le recrée donc à chaque fois.
>>
>> On va faire un test :
>> lance le registre et rend toi dans
>> HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows
> NTCurrentVersionProfileList
>> tu a une tonne de sous clés sous la forme S-1-[...], parcours la liste
>> jusqu'à tomber sur la clé ou le profile indiqué est celui qui est


recréé
>> à
>> chaque fois.
>> change le chemin par celui de profil à remapper.
>>
>> Logue toi ensuite avec le nouvel utilisateur migré, est ce que ceci
> corrige
>> le problème?
>>
>> --
>> Jonathan BISMUTH
>> MCSE 2000/ADSI-AutoIT Scripter
>> Transcript (ID: 691839, code: MCSE2000)
>> www.portail-mcse.net
>> pour me contacter http://cerbermail.com/?z5pCI2OyS6
>> "Glenn Gagné" a écrit dans le message de


news:
>> %
>> > Bon j'ai fait d'autres tests.
>> >
>> > Je me suis assuré que la migration du profil se faisait bien avec


ADMT
>> > (migration ordinateurs).
>> >
>> > Là je trouve ça bizarre....
>> >
>> > Sur la station client, j'ouvre une session avec mon admin réseau pour
> voir
>> > les profils présents.
>> >
>> > J'observe qu'il y a 2 profils existants au même nom:
>> >
>> > NEW_DOMAINmanonroy
>> >
>> > et que l'ancien profil
>> >
>> > OLD_DOMAINmanonroy n'existe plus !!!!
>> >
>> > Je supprime donc l'un des 2 profils en double (celui avec le moins


gros
>> > qui
>> > correspond à une taille de profil "vierge").
>> >
>> > Je ré-essai d'ouvrir une session avec manonroy du nouveau domaine,


mais
> il
>> > re-créé toujours un nouveau profil...
>> >
>> > Alors, je ré-ouvre une session avec manonroy de l'ancien domaine,
>> > bizarrement je retrouve mon ancien profile tout ok.... et si je
>> > retourne
>> > dans la liste des profils, le nom du profils en double est redevenu
>> > avec
>> > le
>> > nom de l'ancien profil.
>> >
>> > VOIR IMAGE EN ATTACHEMENT POUR LES DOUBLONS
>> >
>> > NEW_DOMAIN = CDBSTCOME
>> > OLD_DOMAIN = CONFECT
>> >
>> > Et là... je veux recommencer le test. Encore plus étrange, avec mon
> admin
>> > de
>> > mon ancien domaine que j'ai utilisé tantôt, je ne peux plus effacer


le
>> > profil NEW_DOMAINmanonroy, ni OLD_DOMAINmanonroy ....
>> >
>> > À l'aide
>> >
>> > P.S. J'ai suivi ta procédure pour les profils.
>> >
>> >
>> >
>>
>>
>
>




Avatar
Jonathan BISMUTH
Absoluement,

la doc dâte un peu maintenant. La version d'ADMT était encore la 2.
Je te rassure, il n'y a quasiement pas de différence avec la 3,
particulièrement au niveau de l'ordre de la procédure.

Cordialement,

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?z5pCI2OyS6
"Glenn Gagné" a écrit dans le message de news:

Merci Jonathan,

Je crois que c'est ça l'erreur... j'ai migré les comptes ordinateurs avant
les comptes usagers !

Je vais refaire le test.

---------------------------------

J'ai une autre chose de bizarre... dans la documentation que tu as fait
pour
migrer NT4 vers 2003, dans la section 2.2 pour la migration des groupes à
la
fin tu as ajouté un printscreen de la fenêtre de l'assistant de migration,
dans le fenêtre on voit bien que dans le bas de cette fenêtre il y a 3
choix
"Ne pas renommer les comptes, Renommer avec le préfixe et renommer avec le
suffixe.

Moi dans sur mon serveur je n'ai pas ces choix dans cette fenêtre, je n'ai
que les 4 choix à cocher ???? Peut être une différence de version de ADMT
?

-----------------------------------

"Jonathan Bismuth" a écrit
dans le message de news:
Re Glenn,

pour faire bien, commence par migrer le compte user et fait un test (pour
Sid History) puis translate sa sécurité (pour le repermissionnement). Si
tout est bon, il n'y a plus qu'à migrer son poste avant de passer au


"gros"
: migration des serveurs.
Il n'y a avec cet ordre là aucune raison de toucher à quoi que ce soit


dans
le registre

PS : avec tout ça, n'oublie quand même pas les groupes :)

Cordialement,

--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd


"Glenn Gagné" a écrit dans le message de news:

> Salut Jonathan,
>
> Et oui ça fonctionne en changeant le PATH dans la clé du profile ! Mais


ça
> comme pas le choix en lui forçant la main comme ça ;o)
>
> Une chose que j'ai remarqué de différent entre les profiles que j'avais
> avec
> NT4 et ceux de 2003. Un nouvel enregistrement de plus dans cette clé


pour
> le
> GUID !
>
> Aucun GUID existant dans la clé profile avant, est-ce que tu sais un
> peu
> son
> utilité ?
>
> Bon maintenant je vais réessayer le tout depuis un autre poste test...
> pour
> voir si ça va passer sans avoir besoin de changer la clé ! Je te
> redonne
> des
> nouvelles.
>
> Glenn Gagné
> Technicien MCP/TI
>
>
> "Jonathan BISMUTH" a écrit dans le message de
> news:OTV$
>> Hum...
>> de un : le truc c'est que tu as déjà ajouté ta machine dans le nouveau
>> domaine, donc l'admin de l'ancien domaine n'est pas administrateur
>> d'un
>> poste du nouveau.
>>
>> de deux : il voit que l'utilisateur manonroy a 2 profils du fait du
>> Sid
>> history. Il est donc OK pour le fait que cet utilisateur est
> propriétaire...
>> de deux profils.
>> Comme tu as déjà tenté une authentification, je suppose que


l'utilisateur
>> est existant dans la base de registre, avec un chemin de profil dans
>> la
> clé
>> "profilepath" spécifié pour l'autre... il le recrée donc à chaque
>> fois.
>>
>> On va faire un test :
>> lance le registre et rend toi dans
>> HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows
> NTCurrentVersionProfileList
>> tu a une tonne de sous clés sous la forme S-1-[...], parcours la liste
>> jusqu'à tomber sur la clé ou le profile indiqué est celui qui est


recréé
>> à
>> chaque fois.
>> change le chemin par celui de profil à remapper.
>>
>> Logue toi ensuite avec le nouvel utilisateur migré, est ce que ceci
> corrige
>> le problème?
>>
>> --
>> Jonathan BISMUTH
>> MCSE 2000/ADSI-AutoIT Scripter
>> Transcript (ID: 691839, code: MCSE2000)
>> www.portail-mcse.net
>> pour me contacter http://cerbermail.com/?z5pCI2OyS6
>> "Glenn Gagné" a écrit dans le message de


news:
>> %
>> > Bon j'ai fait d'autres tests.
>> >
>> > Je me suis assuré que la migration du profil se faisait bien avec


ADMT
>> > (migration ordinateurs).
>> >
>> > Là je trouve ça bizarre....
>> >
>> > Sur la station client, j'ouvre une session avec mon admin réseau
>> > pour
> voir
>> > les profils présents.
>> >
>> > J'observe qu'il y a 2 profils existants au même nom:
>> >
>> > NEW_DOMAINmanonroy
>> >
>> > et que l'ancien profil
>> >
>> > OLD_DOMAINmanonroy n'existe plus !!!!
>> >
>> > Je supprime donc l'un des 2 profils en double (celui avec le moins


gros
>> > qui
>> > correspond à une taille de profil "vierge").
>> >
>> > Je ré-essai d'ouvrir une session avec manonroy du nouveau domaine,


mais
> il
>> > re-créé toujours un nouveau profil...
>> >
>> > Alors, je ré-ouvre une session avec manonroy de l'ancien domaine,
>> > bizarrement je retrouve mon ancien profile tout ok.... et si je
>> > retourne
>> > dans la liste des profils, le nom du profils en double est redevenu
>> > avec
>> > le
>> > nom de l'ancien profil.
>> >
>> > VOIR IMAGE EN ATTACHEMENT POUR LES DOUBLONS
>> >
>> > NEW_DOMAIN = CDBSTCOME
>> > OLD_DOMAIN = CONFECT
>> >
>> > Et là... je veux recommencer le test. Encore plus étrange, avec mon
> admin
>> > de
>> > mon ancien domaine que j'ai utilisé tantôt, je ne peux plus effacer


le
>> > profil NEW_DOMAINmanonroy, ni OLD_DOMAINmanonroy ....
>> >
>> > À l'aide
>> >
>> > P.S. J'ai suivi ta procédure pour les profils.
>> >
>> >
>> >
>>
>>
>
>