New
#720
Good news, thanks for sharing.
Yep, all true. What happens though is that there are 2 phases:
- sysprep
- goes through a whole bunch of 'oobe cleaning rituals', because of the /oobe swtich
- it copies the file you specify with the /unattend:file.xml switch as C:\Windows\Panther\unattend.xml
- it fiddles a few registry values to tell setup that, on the next reboot, it should do something
- it reboots because of the /reboot switch
- setup
- checks the registry key to see if it should do anything, and which 'pass' it should perform
- for certain passes, it locates the unattend.xml file, looking in about 10 spots until it finds one
- for certain passes, it copies that unattend.xml file to C:\System\Panther\unattend.xml and clobbers anything which was there previously
- it then proceeds to process C:\System\Panther\unattend.xml, storing information about the success of each pass (for example, mine now has <settings pass="oobeSystem" wasPassProcessed="true">)
It is only in the 'setup' stage when the <FolderLocation/> element is processed. And only if it managed to get itself into C:\System\Panther\unattend.xml. The problem I had was that C:\System\Panther\Unattend\unattend.xml has precedence over the file that sysprep wrote to C:\System\Panther\unattend.xml, and because Lenovo put one there, it's not so much that your directions didn't work, it's that they were thwarted!
Thanks for writing them though.
I just solved a similar problem that was very related to the fact that my OEM had put a file C:\Windows\Panther\Unattend\Unattend.xml and it was taking precedence over the file you supply to sysprep, which it copies to C:\Windows\Panther\unattend.xml. It can also be a file pointed at by a registry key, which takes precedence. All the info here.
Well, I've had success, mostly, with this new information! I chose to rename the C:\Windows\Panther\Unattended\Unattend.xml file to Unattend.backup, and then followed Kari's instructions for at least the sixth time. I also renamed the C:\Windows\Panther\Unattend.xml the same way. I created the false account, activated my "good" user name, and signed out. Interestingly, when I went to log in this time, it wanted a password on my "good" user name - but I never created one!?! Fortunately, as I said before, I'm working with a brand new computer so I can scrap that account and create a new one, but that was disappointing. I'm also a little puzzled why one of my previous attempt's fake accounts still shows in the Users directory but it doesn't show up in the list of users in the Settings menu. Still tinkering with this a bit, but a huge thanks to dtbullock for this break through! And of course a huge thanks to Kari for the overall solution!
I'm a new Windows 10 Pro user who, thanks to the TenForums tutorials, managed a clean install from ISO and also moving the Users folder from the system C: drive to the D: drive in another partition.
Everything is good, except KB3172985 has repeatedly failed to install. Each time, after a restart the installation begins but then gives the Fatal Error C00000D4, restarts, and rolls back the update. After searching the TenForums and Microsoft support, I've tried to troubleshoot by using the Windows Update troubleshooter, sfc scans, and DISM RestoreHealth, but none have identified problems. I've also tried offline updates, resetting Windows Updates, and installing KB3172988. My System reserved partition appears healthy and is not full (63 MB free).
Looking in the local Event Viewer, I see these errors associated with the failed updates:
Source: WindowsUpdateClient, Event ID 20
General Description: Installation Failure: Windows failed to install the following update with error 0x80070011: Update for Windows (KB3172985).
Source: Service Control Manager, Event ID 7023
General Description: The Windows Modules Installer service terminated with the following error:
The system cannot move the file to a different disk drive.
Looking in C:\Windows\WinSxS folder, the poqexec.log gives the error:
1d1e8f591790fda: 0, 0, 0, 0, StartTime ;
1d1e8f591790fda: 8bd, c00000d4, 1489, 0, MoveFile ;\SystemRoot\WinSxS\Temp\PendingRenames\d5882d85f5e8d10136190000b417a815.desktop.ini, \??\D:\Users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility\desktop.ini
1d1e8f594f00630: 0, 0, 0, 0, EndTime ;
So, my admittedly rudimentary interpretation is that the Windows Installer terminates when it fails to write the desktop.ini file to the Users folder on the D: drive.
I'd appreciate any comments or suggestions from more knowledgeable users about whether this could be the cause of the update failures and how to troubleshoot the issue.
Thanks.
Try to download the offline installer for that update from Microsoft and install the update manually: Microsoft Update Catalog
Notice that MS Update Catalog site does not work with Edge. You need IE or a third party browser.
Be sure to select correct bit version. See screenshot, yellow highlight is 32 bit, green 64 bit:
At this point, Anniversary Update coming on Tuesday I would just wait and install that upgrade. It will fix the issue.
For the record, I too have this exact same failure. I've had two Microsoft tech support reps spend a few hours trying to fix this to no avail. This includes the manual install method. It seems to be directly related to the Users Profile location being moved. I'm also seeing more side effects in that after some (or maybe all) resumes from sleep, various things don't work right, such as can't start metro apps, or the explorer start menu fails to launch, as does the Notifications window, while all other task bar functions work correctly. Reboots always cure these problems.
I'm waiting on the Anniversary update, but I'm not confident in it working. Right now, I'm a bit unimpressed with Windows 10.![]()
Hi Kari,
I followed your Method 2 on my MSi Windows 10 laptop which has two drives SSD and HDD. Initially the OS was installed on HDD with recovery partition on HDD C:/ drive. I used the second method and successfully moved the Users folder to SSD D:/ drive but since that drive isn't big enough. I now re-installed the OS on SSD drive which is C:/ drive now with recovery partition on HHD drive which is now drive D:/ The recovery partition actually appears as G:/ in Windows Explorer but in Disc Management it doesn't have a name. I tried to rename it but Windows doesn't let me. So I tried to run the same procedure as in Method 2 but it failed. I attached screenshot with error massage and Disc Management window and command prompt. Can the User folder be moved in this configuration or shall I go back to keeping Recovery partition on the C: drive?
Thanks a lot!