Pana la Vista si Windows 7 se putea folosi utilitarul Moveuser.exe sau workaround-ul de aici: http://www.winadmin.ro/2009/11/27/unde-este-stocata-calea-catre-profil-in-registry/

Nota: bineinteles ca daca folosesti ADMT nu mai e nevoie de asa ceva, dar ADMT merge doar de la domeniu la domeniu.

In Windows 7 si Vista lucurile s-au schimbat si operatiunea asta se poate face doar folosind clasa WMI Win32_UserProfile.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;930955

Cum cei de pe AskDS aveau un exemplu de script functional, nu m-am mai chinuit sa fac eu unul ci o sa exemplific pe scriptul lor: http://blogs.technet.com/b/askds/archive/2008/09/09/vista-s-moveuser-exe-replacement.aspx

Sunt logat pe o statie cu Windows 7 in workgroup si puteti vedea cum arata o portiune de desktop-ul meu. Bineinteles ca dupa joinarea la domeniu as vrea sa-l pastrez.

Joinez statia la domeniu.

Dau restart si ma loghez cu userul de domeniu.

Noul profil arata diferit. Normal, ca doar e un profil nou ce nu are treaba cu ce aveam eu inainte.

Modificam scriptul de pe AskDS exact cum ni se spune (cu numele sistemului sursa, user sursa, domeniu destinatie, user destinatie).

Daca incercam sa rulam scriptul de pe userul destinatie, o sa primim urmatoarea eroare. E de bun simt pana la urma.

Normal ar fi sa il rulam de pe un alt cont cu drept de administrator local, dar nu admin-ul local. De ce? Pentru ca adminul local nu poate sa se conecteze la AD sa execute search-ul pentru aflarea SID-ului corespunzator cu userul destinatie.

Eu personal pentru exemplul asta m-am logat cu admin-ul local si de acolo am mai deschis un CMD in contextul adminului de domeniu. Puteti sa va logati direct cu adminul de domeniu.

Cam asta e output-ul scriptului in cazul in care totul merge ok, iar mai jos puteti vedea cum arata desktop-ul dupa ce ma loghez din nou pe userul de domeniu.

Nu este ceva care sa mearga din prima in orice scenariu. Trebuie sa intelegi putin scripting si sa fii in stare sa-ti adaptezi scriptul nevoilor proprii. Merge rulat si remote fara a fi nevoie sa vizitezi fiecare statie in parte. Pe baza lui se poate construi ceva care sa rezolve o mare parte din problemele asociate migrarii statiilor standalone la domeniu.

LE: o copie a scriptlui gasiti si aici.

Postul acesta l-am replicat de pe ITBoard, pentru ca intentionez sa public o serie de articole unde va fi nevoie de aceasta informatie.

In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>

http://support.microsoft.com/kb/324734

Cheia din registry ProfileImagePath se refera la locatia profilului pe disk. E foarte utila in cazul migrarilor, cand user account-ul isi schimba sid-ul si agentul de migrare nu reuseste sa translateze profilul. Sau cand joinezi statia in domeniu si vrei sa pastrezi vechiul profil. Si cazuri mai sunt multe.

Poti chiar sa folosesti acelasi profil pentru 2 conturi – de domeniu si local.

Pe scurt: Modifici calea catre profil. Dai permisiuni pe folderul cu profilul pentru userul care se logheaza.

Nu numai in 7 ci si in Vista si 2008. Totul a pornit de la acest KB unde este specificat procesul.

Nota: Pentru cei ce nu stiu, toate profilele noi facute pe un sistem pornesc de la default user profile (e un template).

Pana acum in 2K si XP pur si simplu copiam profilul userului in care faceam modificarile peste default user profile (cred ca si in examenele de certificare aveam astfel de intrebari). Incepand cu Windows Vista lucrurile s-au schimbat si copierea profilului trebuie facuta in procesul de SYSPREP.

KB-ul mentionat mai sus spune ceva, insa exact cum se face, cum arata fisierul ala unattended sau ce mai mai trebuie sa contina, nu exista in articol. Cautarile pe net sunt si ele nefolositoare. Atunci hai sa vedem cum se face.

Procedura e urmatoarea: rulezi sysprep cu fisier de unattend in care ii specifici sa copieze profilul userului administrator peste default user profile. Doar ca acel fisier unattend are un format anume, nu merge sa pui doar parametrul, iar exemple clare pe net nu sunt. De ce? Pentru ca trebuie sa-l faci cu WAIK (Windows Automated Installation Kit). E micut, 1.7Gb Asta doar ca sa generezi un fisier de raspuns XML. Mai simplu de atat nu cred ca puteau sa faca

Din WAIK folosim Windows System Image Manager pentru a creea fisierul de raspuns. O sa aveam nevoie de discul cu Windows pentru a putea construi fisierul de raspuns, unde va trebui sa adaugam un pachet in sectiunea Specialize. Asta pentru a creea rubrica Specialize in fisier. Optiunea de CopyProfile nu e disponibila in GUI (de ce nu ma mira). O vom adauga de mana dupa ce avem fisierul facut si o sa arate cam asa:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
             <CopyProfile>true</CopyProfile>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="catalog:d:/sources/install_windows 7 ultimate.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

Dupa ce avem fisierul va trebui sa customizam profilul de la care pornim. Eu am folosit userul Administrator (nu stiu daca merge si cu alt user). Pentru a folosi userul administrator e nevoie sa-l activati din Local Security Policy (gpedit.msc).

Odata logati pe userul Administrator, incepem sa customizam profilul, si ne pregatim sa rulam SYSPREP:

Se poate vedea ca tema e alta decat cea default si am pus si cateva ceva pe desktop. Systemul va rula sysprep, va reboota, si va trece prin etapa de Specialize. La final, dupa minisetup, desktopul o sa arate asa cum am vrut:

Si cam toate astea doar ca sa inlocuiesti CopyProfile din XP. Ouch!