Windows knows where the folders are at the moment of you running the sysprep command. Sysprep checks the current environment variables to find what it needs. The answer file only needs to tell sysprep where to move the folders, not where they are now.
Something in your post remained in my small brain, disturbing me all last night, until about midday today I realized what it was: your mention of in-place installation.
Hopefully I do not post this too late for you:
Warning
An upgraded Windows cannot be sysprepped. As this method is based in sysprepping, this tutorial is valid only for Windows setups which have not been upgraded.
This means that if you have for instance in-place upgraded Vista to Seven. The same applies if you have upgraded from a lesser edition to a better edition, for instance from Windows 7 Home Premium to Professional.
Notice that a repair install is also an upgrade install, so if you have ever done a repair install (= in-place upgrade to same edition), you cannot sysprep.
In other words, when sysprepping an existing Windows setup it only works if the Windows was installed clean and has never been upgraded or repaired using repair install, or if it is the original pre-installed Windows.
This post earlier in this thread is about upgrading to 8 or 8.1 from a sysprepped Seven with relocated Users and ProgramData, but the same procedures and principles apply also when upgrading to another edition of Seven or when repair installing (repair install = in-place upgrade to same edition).
Kari
Kari, thanks. I have not gone ahead, need to make sure everything is backed up in case of a meltdown. Likely in the next couple of weekends I will have a crack at it. I have a clean install of Win 7 Ultimate on the machine, my jargon was not correct above, it is not an upgrade from Vista or repair install etc. It was rebuilt using your approach a couple of months back.
Chris
Kari, have made the various backups before trying the approach for moving existing users from already separate D: drive to new separate K: drive (in your honour no less!). A couple of final sanity checks. In the script I have modified the location of the windows source from E: to a G: to use an ISO Win 7 SP1 Ultimate install, as my original Win 7 disk is pre SP1. I understood that for this to work the install disk has to have SP1. Never have tried this but will have a go.
Is there anything else in the script that needs to be modified as the Users are on D: and is not a clean install? From your post 22 it looks like everything in the Users files will be moved to the new location. Good news.
As is moving the Users from D: to separate new K: drive, I do not have to get into the users.old renaming aspects.
Finally I have IE11 installed on my machine. As per the note warning of IE10 users, I have checked the registry and all the entries reflect System32, not the SYSWOW64. At the end of that note a user asks for help when he is still getting the error but his registry has been corrected. Is this something that is now fixed via patch for IE11? If not what is the advice regarding correction -- uninstall IE 11 back to 9? Most of the forum commentary on it is fairly old so hoping it has been repaired now.
I have disabled the Windows Media Service...
Noob questions I know.
Chris
Kari, did the switch yesterday. Would call it a 90% success. The main steps went well. The profiles had about 480gb of information, at the reboot with the "checking video performance" message, it took about 3h to complete or so as it moved the info across.
A few quirks:
1. Got the Fatal Error message on each restart, had to disable the Media service with each restart.
2. USB drive worked well despite being a Student version of the software. Reactivivation went fine.
3. Several programs reacted to the move: HP software, Dropbox, Fences screen icon thing, Norton Security, Outlook was still looking for old psts. With uninstall and reinstall, most are working now, and in some cases setup again.
4. If only read the xml file from the D: drive, it would not read it when in the K: drive, got the Fatal Error message. I had two instances with identical files.
There are still a series of folders in the original location. I will check if there are any contents but assume is safe to delete them and remove the drive.
Chris
Kari, really big thanks for all your assistance. It is really appreciated. Seems to be running well now.
Chris
Good to hear.
Your Dropbox, Fences etc. issue is because of "almost good"coding: Installer checks the location of ProgramData and/or Users from environment variable, but still creates register and ini references to an absolute location.
An example: An application installer needs to create a folder in ProgramData to store settings. Installer reads the environment variable showing the location of ProgramData, Windows tells installer it is relocated on D:. Now the app would have no issues even when PrograData would be relocated again in another location if the installer would write registry entries and ini/settings files using a relative location %ProgramData%, but instead the installer writes these values using D:\ProgramData.
The process of relocating ProgramData and Users can be done multiple times, to a new location or returning them to a prior location, but each new relocation brings more of these small issues. It's not serious and the work needed is nothing compared to what you can gain.
Kari
So i attempted this method as per instructions. I made sure to stop the wmpnetworksvc so i got passed that error. I have installed windows 7 from the factory restore.(i had to factory restore my computer from recovery partition)That being said there is no disc in my E: drive. So I referred to post #22 for preinstalled steps. The strange part is when i run the command prompt for audit mode it does not actually cause me to have to create a new profile. It reboots, gives me the "setup is preparing" screen, and then returns me to the desktop in my same user account with screen from page 4 of your tutorial showing. I have the script file prepared but if i run it without closing this box, it states sysprep is already running. If I close the box and run the script, it will reboot do the exact same thing as before and return me to the page 4 screen.I copy and pasted the script to notepad for the .xml. All locations, architecture, and windows are exactly the same, down to the location of the relocate.xml file. Nothing broke, actually i don't think it did anything. Any ideas where I messed up first.
Your post is quite difficult to understand but I will try. What's clear is that you have misunderstood something.
First, let me just say that this method, relocating with sysprep, works every time if you follow the instructions to the letter, use original install media and your Windows 7 is not in-place upgraded.
You MUST edit the answer file as told in screenshot below. All four points MUST be checked and correct:
- Correct bit architecture
- Correct drive letter for Users and ProgramData (new location, where you want them to be moved)
- Correct Windows edition
- Correct location of valid Windows 7 install media (no factory recovery partition but either an original Windows 7 DVD, or self from original and valid Windows ISO file burned DVD or USB stick)
You MUST have valid Windows install media inserted, either a DVD or a USB stick. It DON'T HAVE TO BE on drive E: which is only used as an example in tutorial. Any drive will do; if you have created a Windows 7 USB stick from a valid Microsoft Windows 7 ISO file by yourself and have it attached as drive X:, then you replace the E: in the tutorial's answer file example to X:.
Have a shot of good single malt, take a deep breath and read the post #22 once again. Arriving to desktop as seen in screenshot in tutorial page 4 means you have booted to Audit Mode, not to your personal user account but to built-in administrative account.
It is not supposed to ask you to enter a new user name now but instead first after you have run sysprep with the answer file, exited Audit Mode and returned to normal Windows.
Quote