locked
Migration des profiles itinérant avec ADMT 3.2 => ouverture de session sous profile temporaire RRS feed

  • Question

  • Bonjour,

    je suis en train d'effectuer une migration inter-forêts.

    domaine.source.fr           vers          domaine.target.local

    (Windows 2008r2)            ->           (Windows 2008r2)

    poste client Windows7       ->           poste client Windows7

    j'utilise ADMT 3.2

    1/ relation d'approbation mise en place.

    2/ (admt) migration des groupes de sécurité effectué (source vers target).

    3/ (admt) migration des comptes utilisateur (avec les SID) et de leurs mots de passe effectué (source vers target)..

    4-a/ mise en place d'un serveur de fichier (bis) dans le domaine.source.fr.

    4-b/ robocopy des profiles itinérant du serveur de fichier d'origine vers le serveur de fichier "bis".

    5-c/ (admt) migration du serveur de fichier "bis" (stockant les profiles itinérant des comptes utilisateurs du domaine.source.fr) vers domaine.target.local effectué.

    5/ relation d'approbation supprimé.

    6/ (admt) translation des sécurité effectué. (deux fois comme préconiser)

    7/ (powershell) modification du "profile path" effectuer (pour correspondre au nouveau chemin de stockage).

    résultats :

    -ACL des dossiers sur le serveur de fichiers semble OK (les comptes utilisateurs apparaissent avec l'UPN de la nouvelle forêt).

    -ouverture de session dans le nouveau domaine (domaine.target.local) OK avec le mot de passe d'origine (domaine.source.fr).

    !!! - la session s'ouvre avec un profile temporaire. - !!!

    !!! - à l'ouverture de session, le lecteur réseau mappé (défini dans les paramètres du compte => "dossier de base") vers l'emplacement du profile itinérant est accessible. - !!!

    !!! -dans l'observateur d'évènements :

       -> winlogon, erreur numéro : 6001(nombre d'erreurs : 2) et 6004(nombre d'erreurs : 2)

       -> user profile service, erreur numéro : 1500(nombre d'erreurs : 2), 1511(nombre d'erreurs : 1),1526(nombre d'erreurs : 3)

       -> Kernel-event tracing, erreur numéro : 2(nombre d'erreurs : 20)

    quelqu'un pourrait me dire si je n'ai pas raté/oublié une manipulation ?

    Cordialement,

    Daniel.


    lundi 28 avril 2014 16:24

Réponses

  • Rebonjour :)

    je vais mettre cela sur le compte de la fatigue. Il fallait lire (sur mon test de la veille) :

    commandes lancés :

    $objUser = New-Object System.Security.Principal.NTAccount("target", "user_name")
    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
    $strSID.Value

    $objUser = New-Object System.Security.Principal.NTAccount("source", "user_name")
    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
    $strSID.Value

    sur :

    controleur.domaine.source.fr

    +      serveurfichier.domaine.source.fr

    +      serveurfichier.domaine.target.local

    +      controleur.domaine.target.local

    résultats :

    (SID1)

    (SID2)

    en allant voir dans l'adsi :

    user_name.domaine.source.fr => SID2 (sIDHistory : {vide})

    user_name.domaine.target.local => SID1 (sIDHistory : {SID2})

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

    sur le poste utilisateur dans la clé de registre "HKLM\software\Microsoft\Windows NT\currentversion\profilelist" je vois apparaitre :
    SID2 (=> profileimagepath reg_expand_sz   c:\users\user_name) + sous-répertoire "preference" et "fdeploy".
    et
    SID1 (=> profileimagepath reg_expand_sz   c:\users\temp.target) (pas de sous-répertoire).

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

    lorsque je supprime le répertoire "profile.V2" (profile itinérant de l'utilisateur). Celui-ci est recréé lors de la reconnexion. et je ne retrouve plus du tout les souci de chargement de profile temporaire. (les droits ne sont aucunement différents).

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

    la suppression seule des "ntuser.dat" n'apporte aucune amélioration.

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

    suppression d'un SID (non résolu) => correspondant à l'administrateur du serveur de fichier source.

    aucun changement.

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

    les "profilepath" :

    \\serveurfichier.domaine.target.local\partage1\groupe1\%username%\profile      (machine virtuel) => contrôle total par SID1

    \\serveurfichier.domaine.source.fr\partage1\groupe1\%username%\profile      (machine physique) => contrôle total par SID2

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

    en m'appropriant le répertoire profile (groupe administrateurs.serveurfichier.domaine.target.local). et en supprimant NTUSER.DAT, ntuser.ini et ntuser.pol. (l'une ou l'autre des opérations prise individuellement, n'apporte pas la solution) A l'application des deux manipulation, Plus de problème.

    la solution serait que je m'approprie l'ensemble des répertoires ?

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

    en quoi l'administrateur à un impact sur l'ouverture de session d'un utilisateur ?

    DM.


    mercredi 30 avril 2014 10:43
  • Normalement aucun impact mais d'après ce que vous dites, c bien un problème de droit, parce que quand vous vous vous appropriez le dossier + delete NTUSER.DAT ...etc le problème disparu.

    Si vous auriez que des VMs (source & target file server), j'ai découvert une méthode magique :

    détacchez le VMDK de la VMSource contenant les users profils => rattachez le VMDK sur la VMTarget, les droits sont repositionnés automatiquement et après les migrations, les users ayant des profils itinérant arrivent à ouvrir leur session sans problème.

    Donc adoptez plutôt cette solution : 

    S'approprier le repertoire profile ADM + suppression de NTUSER.DAT, NTUSER.INI et NTUSER.POL

    Goodluck

    A+

    HK.


    Hicham KADIRI | Just Another IT Guy

    • Marqué comme réponse daniel081270 vendredi 2 mai 2014 11:38
    mercredi 30 avril 2014 19:28

Toutes les réponses

  • Bonjour,

    vous dites :

    5-c/ (admt) migration du serveur de fichier "bis" (stockant les profiles itinérant des comptes utilisateurs du domaine.source.fr) vers domaine.target.local effectué.

    comment avez-vous effectué la migration ?

    j'ai l'impression que c'est un problème de lecture du profil utilisateur itinérant

    Toutes les étapes me semblent OK.

    A+

    HK.


    Hicham KADIRI | Just Another IT Guy

    lundi 28 avril 2014 16:38
  • Bonjour Hicham,

    la migration "5-c" à été faite à l'aide d'ADMT (Computer migration wizard).

    qu'entendez vous par "j'ai l'impression que c'est un problème de lecture du profil utilisateur itinérant" ?

    DM

    mardi 29 avril 2014 08:13
  • Salut Daniel,

    Le message d'erreur que vous avez au démarrage est souvent lié soit à un problème de lecture du profil utilisateur (que soit local ou itinérant) soit un problème niveau base de registre.

    Donc, je demandais comment ça s'est deroulé la migration de profils itinérant du serveur de fichiers bis vers le domaine target. et est ce que y aurait pas un problème d'accès aux profils itinérant migrés du serveur de fichier source au serveur bis.

    De plus, pourriez-vous accéder à l'éditeur de registre et naviguez jusqu'au :

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

    Dites moi ce qui apparaît sur le volet droit

    A+

    HK.



    Hicham KADIRI | Just Another IT Guy

    mardi 29 avril 2014 09:07
  • Bonsoir Hicham,

    j'ai effectuer quelques testes de mon côté. Et mis en œuvre votre réponse.

    dans la base de registre :
    a l'emplacement HKLM\software\Microsoft\Windows NT\currentversion\profilelist j'ai :
    - (par defaut)        reg_sz            (valeur non définie)
    - default             reg_expand_sz     %systemdrive%\users\default
    - profilesdirectory   reg_expand_sz     %systemdrive%\users
    - programdata         reg_expand_sz     %systemdrive%\programdata
    - public              reg_expand_sz     %systemdrive%\users\public


    j'ai réactivé les relations d'approbation. Et l'ouverture des comptes utilisateurs sur l'ancienne forêt s'effectue sans aucun message d'erreur (c.-à-d.. sans ouverture d'un profile temporaire). -> ce qui me fait dire qu'il n'y à aucun problème sur le profile de l'utilisateur en question.
    Il est à préciser que j'effectue mes manipulation sur un compte utilisateur de teste (présent dans les deux forêts grâce à la migration). Et que les fichiers du profile itinérant diverge d'une forêt sur l'autre que par les modifications apportés par ADMT et/ou Robocopy.

    je viens de constater une chose :

    en powershell j'ai lancé cette instruction sur les deux contrôleurs de domaine, ainsi que sur le serveur de fichiers hébergeant les profiles:


    $objUser = New-Object System.Security.Principal.NTAccount("target", "user_name")
    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
    $strSID.Value


    $objUser = New-Object System.Security.Principal.NTAccount("source", "user_name")
    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
    $strSID.Value


    controleur.domaine.source.fr      +      serveurfichier.domaine.target.local
    (SID1) + (SID2)

    controleur.domaine.target.local
    (SID3) + (SID4) SID différent des deux précédents


    sur le poste utilisateur dans la clé de registre "HKLM\software\Microsoft\Windows NT\currentversion\profilelist" je vois apparaitre :
    SID1 (=> profileimagepath reg_expand_sz   c:\users\user_name) + sous-répertoire "preference".
    et
    SID3 (=> profileimagepath reg_expand_sz   c:\users\temp.target.001) (pas de sous-répertoire).


    je vais creuser et voir si y'a pas un rapport avec l'historique SID.

    mardi 29 avril 2014 18:00
  • Bonjour Daniel,

    je suis quasi sûr que c'est lié aux SIDs positionné sur le share contenant les profils de vos utilisateurs ainsi qu'aux droits positionnés dessus.

    ça se trouve ça été mal migré. la migration des SIDs est souvent une tâche assez complexe, il s'agit de l'userpation d'un user ou d'un groupe de users et donc doit être faites minutieusement.

    je recommande la mise en place d'un POC (Proof Of Concept) dans ce genre de projet, duplication de l'environ e production, faire les tests avant migration de la prod.

    les outils standard de migration de Microsoft ne donnent pas souvent des bons résultats, en fait ça dépend de l'infra, des équipements réseaux, de la config réseau ...etc.

    Dites moi, vous serez pas dans un environnement virtuel ? je veux dire, le serveur de fichier source est un Guest OS ? ou un OS déployé un serveur de fichier physique ? si c'est virtuel, je peux vous montrer une astuce qui permettra de garantir la migration des services de fichiers avec l'ensemble des droits positionnés dessus.

    A+

    HK.


    Hicham KADIRI | Just Another IT Guy

    mardi 29 avril 2014 19:20
  • Bonjour Hicham,

    L'infrastructure d'origine est de type "physique". L'architecture de destination est quand à elle virtuel, nous somme sur du vsphere/vcenter5 (VMware).

    PS : je n'ai pas encore eu le temps de vérifier l'historique des SIDs. J'ai tout de même un doute, je pense que les nouveau SIDs sont survenu suite à la remise en place des délégations.

    DM.

    mercredi 30 avril 2014 07:37
  • Rebonjour :)

    je vais mettre cela sur le compte de la fatigue. Il fallait lire (sur mon test de la veille) :

    commandes lancés :

    $objUser = New-Object System.Security.Principal.NTAccount("target", "user_name")
    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
    $strSID.Value

    $objUser = New-Object System.Security.Principal.NTAccount("source", "user_name")
    $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
    $strSID.Value

    sur :

    controleur.domaine.source.fr

    +      serveurfichier.domaine.source.fr

    +      serveurfichier.domaine.target.local

    +      controleur.domaine.target.local

    résultats :

    (SID1)

    (SID2)

    en allant voir dans l'adsi :

    user_name.domaine.source.fr => SID2 (sIDHistory : {vide})

    user_name.domaine.target.local => SID1 (sIDHistory : {SID2})

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

    sur le poste utilisateur dans la clé de registre "HKLM\software\Microsoft\Windows NT\currentversion\profilelist" je vois apparaitre :
    SID2 (=> profileimagepath reg_expand_sz   c:\users\user_name) + sous-répertoire "preference" et "fdeploy".
    et
    SID1 (=> profileimagepath reg_expand_sz   c:\users\temp.target) (pas de sous-répertoire).

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

    lorsque je supprime le répertoire "profile.V2" (profile itinérant de l'utilisateur). Celui-ci est recréé lors de la reconnexion. et je ne retrouve plus du tout les souci de chargement de profile temporaire. (les droits ne sont aucunement différents).

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

    la suppression seule des "ntuser.dat" n'apporte aucune amélioration.

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

    suppression d'un SID (non résolu) => correspondant à l'administrateur du serveur de fichier source.

    aucun changement.

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

    les "profilepath" :

    \\serveurfichier.domaine.target.local\partage1\groupe1\%username%\profile      (machine virtuel) => contrôle total par SID1

    \\serveurfichier.domaine.source.fr\partage1\groupe1\%username%\profile      (machine physique) => contrôle total par SID2

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

    en m'appropriant le répertoire profile (groupe administrateurs.serveurfichier.domaine.target.local). et en supprimant NTUSER.DAT, ntuser.ini et ntuser.pol. (l'une ou l'autre des opérations prise individuellement, n'apporte pas la solution) A l'application des deux manipulation, Plus de problème.

    la solution serait que je m'approprie l'ensemble des répertoires ?

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

    en quoi l'administrateur à un impact sur l'ouverture de session d'un utilisateur ?

    DM.


    mercredi 30 avril 2014 10:43
  • Normalement aucun impact mais d'après ce que vous dites, c bien un problème de droit, parce que quand vous vous vous appropriez le dossier + delete NTUSER.DAT ...etc le problème disparu.

    Si vous auriez que des VMs (source & target file server), j'ai découvert une méthode magique :

    détacchez le VMDK de la VMSource contenant les users profils => rattachez le VMDK sur la VMTarget, les droits sont repositionnés automatiquement et après les migrations, les users ayant des profils itinérant arrivent à ouvrir leur session sans problème.

    Donc adoptez plutôt cette solution : 

    S'approprier le repertoire profile ADM + suppression de NTUSER.DAT, NTUSER.INI et NTUSER.POL

    Goodluck

    A+

    HK.


    Hicham KADIRI | Just Another IT Guy

    • Marqué comme réponse daniel081270 vendredi 2 mai 2014 11:38
    mercredi 30 avril 2014 19:28
  • merci beaucoup Hicham.

    Cordialement,

    DM.

    vendredi 2 mai 2014 09:10