Sysprep error after changing the users folder location to another partition

Question

I'm running Windows 10 Pro (version 1607, released in July on MSDN) on a virtual machine, and got multiple partitions on that machine.

For deployement, I use this answer file. This answer file is validated by the Windows System Image Manager.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" 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>
            <DoNotCleanTaskBar>true</DoNotCleanTaskBar>
        </component>
    </settings>
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <FolderLocations>
                <ProfilesDirectory>U:\</ProfilesDirectory>
            </FolderLocations>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="wim:e:/sources/install.wim#Windows 10 Pro" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

This answer file works works whenever I remove the part for changing the users folder.

    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <FolderLocations>
                <ProfilesDirectory>U:\</ProfilesDirectory>
            </FolderLocations>
        </component>
    </settings>

I am 100% the U:\ directory is there, and tried changing the directory seperator and tried changing it to U:\Profiles.

Whenever I sysprep this machine with the following command:

sysprep.exe /generalize /oobe /unattend:unattend:xml

I get the following error messages on the Windows logo installing the devices.

I also tried updating my machine to the latest version. Note, my Windows isn't activated.

How can I fix this problem?

Is the U: drive a local hard drive? You can't set the user profile directory to a network mapped drive letter with an answer file, nor can you use a removable (USB or otherwise) drive. — Wes Sayeed, Aug 10 '16 at 19:37
@WesSayeed It's a local logical partition which is formatted as NTFS. There are currently no folders on there, the thing I tried was creating a "Profiles" folder there and re-setting the location to that folder. Btw, the machine is 64bit. — Bas, Aug 10 '16 at 19:38
How are you deploying this? Is it a custom USB installer you're making, or are you using WDS/MDT/SCCM to deploy it? — Wes Sayeed, Aug 10 '16 at 19:40
@WesSayeed I am just deploying it on the same machine. So just rebooting the machine to the OOBE mode. This is just for testing purposes, when I created the complete WIM file, i'm going to use WinPE to apply the image on PC's — Bas, Aug 10 '16 at 19:40
Yes I did, becuase I re-read your question and saw that you had tried a sub-folder (instead of just the root of U:), which is what my comment suggested. :) — Ƭᴇcʜιᴇ007, Aug 10 '16 at 20:03
Alright. Another update, I tried moving it to my C:/ drive, that worked, but didn't get me in to the actual account, it kept rebooting to the OOBE mode after i was done configuring it. — Bas, Aug 10 '16 at 20:04

score 2 · Accepted Answer · answered Aug 10 '16 at 22:02

I suspect this is likely happening because of the /generalize option.

Sysprep's job in life is to prepare Windows to be cloned. To that end, it removes all system-specific information from the registry -- including drive letter assignments -- and invokes Windows Setup after the reboot.

Windows Setup assumes nothing about the machine it "wakes up" on. The only reason it even knows which drive is C: is because the BCD store told it that. For example, it's possible to mess that up the BCD store and have Windows installed to E: instead of C:. Having no other information about the system, Setup will begin device detection, and will assign drive letters in the order in which partitions are found. If your U: drive is, say, the 4th partition on the 1st hard disk, it might get assigned letter F:, not U: (Haha I just said F: U:).

If you don't use the /generalize option, then Sysprep will not process either the <Generalize> or the <Specialize> sections of your answer file (which is where your CopyProfile setting is). So you see that you're in kind of a bind here.

Try this:
Put the ProfilesDirectory setting back into your answer file and rerun Sysprep with the /generalize option. Once it errors out, have a look at the \Windows\Panther\setuperr.log file (or some subdirectory within it -- you may see several so look for the one with today's date on it). Within that file, Windows Setup should give you an exact reason why the process failed (i.e. what specific pass and setting caused the error, and what problem it had with it).

NOTE that Microsoft highly discourages the use of this parameter. They warn that changing it from the default will prevent upgrades and will block Windows Store apps from working properly. It's basically unsupported per their own documentation of the feature

Alright, but how can I possibly get that drive to be the U:/ letter then? And my machine is sort-off bricked after I done that sysprep, the only thing I can do is to re-install windows. can i still get to that log file? — Bas, Aug 11 '16 at 09:47
Update, it doesn't show any specific errors inside the `setuperr.log` file after booting inside the windows installation disk and opening that file within notepad. I've discovered in notepad, the users partition has indeed change it's driver letter to an D:/ — Bas, Aug 11 '16 at 09:59
Another update, after re-installing windows and trying this whole process over again, it worked. — Bas, Aug 18 '16 at 10:30

Sysprep error after changing the users folder location to another partition

1 Answers1

Linked