Change all ProfileImagePath's to point to old profile folders
-
Wednesday, September 12, 2012 4:59 PM
Moving from old Domain win2k to new Domain CIDR and want to keep user ProfileImagePath pointed to old folder? I would like to script this but I not sure how.
All Replies
-
Wednesday, September 12, 2012 5:46 PM
Depends on the structure of yur target domin and how you are doing the migrating.
We do not script migrations. There are tools and the domain upgrade will keep all current profiles as defined. Any need to move them will be done automatically.
I highly recommend that you take some trining in how to use Windows 2008R2 Ad and AD administraion in general before attemting any but the smallest domain upgrades. If yo are not trained or up-to-date in AD then you can get into considerable and unresolvable trouble. The fact that youare asking the question says that you are not up to date in AD and WIndows admin and deployment.
Go to the Microsoft deployment web site and download the materials on prepping for a migration.
http://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
If you discover through analysis and teh guide that you have an issue thatis not addressed in the tools then post to teh ADMT forum or platform forum for assistance in how to resolve your issue. In most cases you do not ned to script anything., Just use the tools and, if needed, design the miration control files.
I have done a few small and medioum size upgrades and did not have to do anything after running th eanalysis streps and writing a couple of scritpss to check that all settings were actaully as required. These would be different for almost every case so the scripts were just one-off at a command prompt (Powershell).
¯\_(ツ)_/¯
- Edited by jrvMicrosoft Community Contributor Wednesday, September 12, 2012 5:48 PM
-
Wednesday, September 12, 2012 6:26 PM
The migration of the workstations will be done by hand. After I log in as the user on the workstation to created the new profile user.CIDR, I will log out an then back in as administrator to edit the registry by hand. If I can script the registry part of pointing the new user sid to the old profile folder that would be better. I would like to skip this process:
1 ) Log in to the PC as the user who’s profile you intend to migrate. Lets call the account TESTUSER.
2 ) Check the users profile path typically located in C:\Documents and Settings\TESTUSER\ and make note of the exact directory path.
3 ) Login as a user with administrative rights and join the new domain. Reboot the PC.
4 ) Log in after rebooting with the users (TESTUSER) new domain account to create a new profile, the log out.
5 ) Log in with a domain admin account.
6 ) Give the TESTUSER@newdomain account full NTFS permissions to the old account profile path you noted earlier. It’s best to Apply the changes before pressing Okay, as I’ve found that they don’t stick when you simply press Okay after adding the permissions.
7 ) Open Regedit and navigate to HKLM\software\microsoft\windows nt\current version\ProfileList
8 ) You will see a list of all the profiles on the machine. Be aware that these profile folders are named according to the user security IDs (SIDs) and not according to the user names. You should find a number of profiles including the old user profile (TESTUSER) and the new domain user profile (TESTUSER.domain). The easiest way to determine which profile belongs to which user is to compare the ProfileImagePath key data to see which account is referenced in the path.
9 ) Edit the domain user profile (TESTUSER.domain) ProfileImagePath key to point to the old user profile path. For example: “C:\documents and settings\TESTUSER.domain” <changes to> “C:\documents and settings\TESTUSER”
10 ) Once complete, login using the domain account and test it out. The desktop should change, the My Documents should contain all their documents, etc. Make sure to check Outlook to confirm the email profile was migrated correctly, I’ve seen a few instances where this did not happen and Outlook required reconfiguration.
I have tested this process and it works but a script to edit the ProfileImagePath by removing the .CIDR would be better.
-
Wednesday, September 12, 2012 6:51 PM
Well i f you insist on doing it by hand then you will likely have to track down the answer.
What is it that you are calling a CIDR? CIDR is a DNS or router concept. It has nothing to do with AD profiles.
If youare asling about eh domain tag added to teh end of a profiel then just ignore it. This is created whaen teh user profile colides with a name that is the same. It can happem when your dick is corrupted or, with troamed profiles, when the profile security is set wrio=ong.
It is also likely that by trying to manually do this youa re corrupting the profiles and causing the prfile to be recreated with the domain tag added.
I recommend studying how aaad manages all of this and using the AD migration tools to resolbve these issues.
There is no scripting magic bullet to solve your issue. You need to fix the cause of the problem and the security if it is set wrong.
Performing a pre-domain upgrade or migration analysis can ehlp you to find and resolve all of these issues before the upgrade.
¯\_(ツ)_/¯
-
Wednesday, September 12, 2012 7:53 PM
I tested the USMT tools
scanstate <USMTStorePath> /o /c /ui:"DomainName\User Name" /i:miguser.xml /i:migdocs.xml
loadstate <Storepath> /c /lac /lae /ui:"DomainName\User Name" /i:miguser /i:migdocs.xml
My test took 30 minutes without using the migdoxa.xml on one computer wasting time and resources and USMT does not migrate all program settings. USMT documentation talks a lot about migration to Windows 7 or a new computer neither of which apply. All the the files / settings exist in the current users profile on the machine that is migrating to the new Windows Domain but , after the users logon on to his/her workstation that now belongs to the new Domain they well recieve a brand new profile by design. Is there a different tool? Or our you just enjoying throwing the book at me by telling me to RTFM? The new domain is build and the users account and groups are migrated.
-
Wednesday, September 12, 2012 8:43 PM
I tested the USMT tools
scanstate <USMTStorePath> /o /c /ui:"DomainName\User Name" /i:miguser.xml /i:migdocs.xml
loadstate <Storepath> /c /lac /lae /ui:"DomainName\User Name" /i:miguser /i:migdocs.xml
My test took 30 minutes without using the migdoxa.xml on one computer wasting time and resources and USMT does not migrate all program settings. USMT documentation talks a lot about migration to Windows 7 or a new computer neither of which apply. All the the files / settings exist in the current users profile on the machine that is migrating to the new Windows Domain but , after the users logon on to his/her workstation that now belongs to the new Domain they well recieve a brand new profile by design. Is there a different tool? Or our you just enjoying throwing the book at me by telling me to RTFM? The new domain is build and the users account and groups are migrated.
Not USMT but ADMT.
To migrate from Pre-Vist to Vista you will need to use USMT 4.0 not 3.1 or earlier.
You can batch migrate a domain. You can control nearly all levels of migration.
The answer is that no - we don't have a script that can do exactly what you are asking.
What is it that you mean by the "old' user profile. A user has only one profile. When a user logs into WIndows 7 for teh first time the old profile is moved into teh new profile. Links are placed pointing to teh neew profile that only the system can use. Ther eis no OLD profile. It has been moved and does not exist anymore.
¯\_(ツ)_/¯
-
Thursday, September 13, 2012 3:34 AM
The old profile would be the one the user used on the previous domain or workgroup. For example, if there was a workgroup computer, and a user named John used it, the profile would be called "John". Now if you joined that computer to a domain, but used a domain user name of John aswell, there would be a new profile created called "John.mydomain".What is it that you mean by the "old' user profile. A user has only one profile. When a user logs into WIndows 7 for teh first time the old profile is moved into teh new profile. Links are placed pointing to teh neew profile that only the system can use. Ther eis no OLD profile. It has been moved and does not exist anymore.
¯\_(ツ)_/¯
Grant Ward, a.k.a. Bigteddy
-
Thursday, September 13, 2012 5:45 AM
Grant - I do not believe that is what the OP is asking. He is doing a domain migration which is something co9mpletely differnt.
In your case the way to move the profile is to just copy it over the new profile usign the COpyProfiel utility or an other copy utility that you choose.
Profiles do not need to be migrated between domains. Accounts need to be migrated.
This is another case where the OP is not foramlly trained in Windows n a domaina nad they are mixing apples and oranges. Becasue of this it is almost impossible to tell exactly what the problem is. The question has morphed more than once.
I once watched a desktop tech paindully extract all kinds of registry values and try to apply them to a new profile. I shoed him how to just let teh user log into teh new domain afyter we migrated the account and SIDS in AD. The profiles worked perfectly with teh exception of all cached or saved passwords. Passwords do not migrate. Passwords for shares and other items needed to be manually reset.
Ther eis nothing domin dependent in a profile. When upgraing a workstaion from Xp to Vista or later teh profuile may need to beexported by teh USMT and reimported although I hae never had to do that excpet when we did not have the profiles roamed. Later I found it was easier to just roam the profilem mover teh user to teh new machine and let WIndows 7 migrate teh profile from teh network share. Only Outlook would not reset and that is a known issue which can be fixed by settign up WS2008 GPPs correctly.
¯\_(ツ)_/¯
-
Thursday, September 13, 2012 5:53 AMThanks for that info. Just to add to this, I have found that with Win7, there is a utility called Windows Easy Transfer. This is much easier to use than the USMT, and it transfers EVERYTHING, including certificates.
Grant Ward, a.k.a. Bigteddy
- Edited by BigteddyMicrosoft Community Contributor Thursday, September 13, 2012 5:53 AM
-
Thursday, September 13, 2012 5:59 AM
Thanks for that info. Just to add to this, I have found that with Win7, there is a utility called Windows Easy Transfer. This is much easier to use than the USMT, and it transfers EVERYTHING, including certificates.
Grant Ward, a.k.a. Bigteddy
So does USMT 4.0.
¯\_(ツ)_/¯
-
Thursday, September 13, 2012 12:45 PM
The old profile would be the one the user used on the previous domain or workgroup. For example, if there was a workgroup computer, and a user named John used it, the profile would be called "John". Now if you joined that computer to a domain, but used a domain user name of John aswell, there would be a new profile created called "John.mydomain".What is it that you mean by the "old' user profile. A user has only one profile. When a user logs into WIndows 7 for teh first time the old profile is moved into teh new profile. Links are placed pointing to teh neew profile that only the system can use. Ther eis no OLD profile. It has been moved and does not exist anymore.
¯\_(ツ)_/¯
Grant Ward, a.k.a. Bigteddy
Bigteddy has it correct same workstation, OS and user after the domain (migration) switch. Most of the workstations that are migrating to the new domain have XP installed and will still be XP after joining the domain. We are not doing a operating system migration. We are moving from two forest with one domain in each too a single forest with a parent and child domain setup. In my testing moving a XP workstation and user editing the ProfileImagePath has worked. For example moving John and computer from domainA to domainB, I found that the John user account has full permissions to the John (domainA OLD profile folder) after migrating to domainB. So, I beleive that all I have to do is point the new SID for the migratied user account John on DomainB back to the John (DomainA Old profile folder). -
Thursday, September 13, 2012 12:50 PM
I tested the USMT tools
scanstate <USMTStorePath> /o /c /ui:"DomainName\User Name" /i:miguser.xml /i:migdocs.xml
loadstate <Storepath> /c /lac /lae /ui:"DomainName\User Name" /i:miguser /i:migdocs.xml
My test took 30 minutes without using the migdoxa.xml on one computer wasting time and resources and USMT does not migrate all program settings. USMT documentation talks a lot about migration to Windows 7 or a new computer neither of which apply. All the the files / settings exist in the current users profile on the machine that is migrating to the new Windows Domain but , after the users logon on to his/her workstation that now belongs to the new Domain they well recieve a brand new profile by design. Is there a different tool? Or our you just enjoying throwing the book at me by telling me to RTFM? The new domain is build and the users account and groups are migrated.
Not USMT but ADMT.
To migrate from Pre-Vist to Vista you will need to use USMT 4.0 not 3.1 or earlier.
You can batch migrate a domain. You can control nearly all levels of migration.
The answer is that no - we don't have a script that can do exactly what you are asking.
What is it that you mean by the "old' user profile. A user has only one profile. When a user logs into WIndows 7 for teh first time the old profile is moved into teh new profile. Links are placed pointing to teh neew profile that only the system can use. Ther eis no OLD profile. It has been moved and does not exist anymore.
¯\_(ツ)_/¯
ADMT does not migrate user profile between forest? "ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations." http://www.microsoft.com/en-us/download/details.aspx?id=8377
Now, I have your answer to my question will you help me script the ProfileImagePath change for all my XP work stations using VBS. "The answer is that no - we don't have a script that can do exactly what you are asking."
-
Thursday, September 13, 2012 1:18 PM
The old profile would be the one the user used on the previous domain or workgroup. For example, if there was a workgroup computer, and a user named John used it, the profile would be called "John". Now if you joined that computer to a domain, but used a domain user name of John aswell, there would be a new profile created called "John.mydomain".What is it that you mean by the "old' user profile. A user has only one profile. When a user logs into WIndows 7 for teh first time the old profile is moved into teh new profile. Links are placed pointing to teh neew profile that only the system can use. Ther eis no OLD profile. It has been moved and does not exist anymore.
¯\_(ツ)_/¯
Grant Ward, a.k.a. Bigteddy
Bigteddy has it correct same workstation, OS and user after the domain (migration) switch. Most of the workstations that are migrating to the new domain have XP installed and will still be XP after joining the domain. We are not doing a operating system migration. We are moving from two forest with one domain in each too a single forest with a parent and child domain setup. In my testing moving a XP workstation and user editing the ProfileImagePath has worked. For example moving John and computer from domainA to domainB, I found that the John user account has full permissions to the John (domainA OLD profile folder) after migrating to domainB. So, I beleive that all I have to do is point the new SID for the migratied user account John on DomainB back to the John (DomainA Old profile folder).Just copy the profile deom pone to the other. Tehy will move with no issue when going Xp to XP. Profiels are portable in that way. Th eonly issues will be cached credentials which cannot be ported anyway as they are encrypted into the registry. I have done this hundreds of times.
¯\_(ツ)_/¯
-
Thursday, September 13, 2012 1:33 PM
Now, I have your answer to my question will you help me script the ProfileImagePath change for all my XP work stations using VBS. "The answer is that no - we don't have a script that can do exactly what you are asking."
Just copy the profile with any copy utility.
xcopy "C:\Documents and Settings\JOHN\*" "C:\Documents and Settings\JOHN.MYDOMAIN" /E /H /R /Y
This should be done after the user logs in the for the forst time to create the folder or you can pre-create the folder an set the permissions but you will have to set up the registry for the new manually created folder.
¯\_(ツ)_/¯
-
Thursday, September 13, 2012 5:19 PM
Now, I have your answer to my question will you help me script the ProfileImagePath change for all my XP work stations using VBS. "The answer is that no - we don't have a script that can do exactly what you are asking."
Just copy the profile with any copy utility.
xcopy "C:\Documents and Settings\JOHN\*" "C:\Documents and Settings\JOHN.MYDOMAIN" /E /H /R /Y
This should be done after the user logs in the for the forst time to create the folder or you can pre-create the folder an set the permissions but you will have to set up the registry for the new manually created folder.
¯\_(ツ)_/¯
Do you have a good reason as to why it's better to Copy john to john.myDomain? -
Thursday, September 13, 2012 6:11 PM
Because there is nothing to be gained by doing it any other way. ALl user settings and history is in the profile. The only profile dependent values cannot be copied by an y means so they will have to be reset not matter what you do. The only things that usually need to be set up are Outlook if it is connected to Exchange. Ther might be acououple of third party applications that have to have passwords reset. DEpends on what techniqu is used to code teh password. Generally nothing has to be done.
Test it. DOn't just keep asking the same question - test the solution and find out what works.
¯\_(ツ)_/¯
- Marked As Answer by IamMredMicrosoft Employee, Owner Wednesday, October 10, 2012 4:16 AM
- Unmarked As Answer by CidrGuys Wednesday, October 17, 2012 2:21 PM
-
Wednesday, October 17, 2012 2:20 PM
We completed the migration of client computers and used this ReProfiler tool to point the user back to the original profile folder. This tool worked great!
- Marked As Answer by CidrGuys Wednesday, October 17, 2012 2:20 PM
.png)
