Windows – Sysprep error after changing the users folder location to another partition

partitioningsysprepwindows

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.

enter image description here

enter image description here

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

How can I fix this problem?

Best Answer

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

Related Question