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 & 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
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
Poser une question
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/Inf.../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$$
...
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$$
fichiers
ma
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é.
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
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$$
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$$
ADMT,
jusqu'au
remplaçant
nouveau
ADMT,
nouveau
l'utilisateur
fichiers
suivi
news:
mais
énumérer
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é" %