ADMT - Migration des comptes usagers

Le
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 & Settingsmanonroy 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 &
Settingsmanonroy.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 & Settingsmanonroy.NEW_DOMAIN" et
sélectionner NEW_DOMAINmanonroy 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
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jonathan Bismuth
Le #11276561
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é" 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.


...
Glenn Gagné
Le #11276551
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" 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é" 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.
...




Jonathan Bismuth
Le #11276541
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é" 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" 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é" 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.
...








Glenn Gagné
Le #11276531
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" 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é" 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" > 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é"

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.
>> ...
>>
>>
>
>




Jonathan BISMUTH
Le #11276521
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é" %
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.





Glenn Gagné
Le #11276511
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" 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é" %
> 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.
>
>
>




Jonathan Bismuth
Le #11276501
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é"
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" 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é" %
> 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.
>
>
>








Glenn Gagné
Le #11229751
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" 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é"
> 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" > 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é"

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.
>> >
>> >
>> >
>>
>>
>
>




Jonathan BISMUTH
Le #11229741
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é"
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" 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é"
> 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" > 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é"

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.
>> >
>> >
>> >
>>
>>
>
>








Publicité
Poster une réponse
Anonyme