Błąd Sysprep po zmianie lokalizacji folderu użytkowników na inną partycję

Używam Windows 10 Pro (wersja 1607, wydana w lipcu w MSDN) na maszynie wirtualnej i mam wiele partycji na tym komputerze.

Do wdrożenia używam tego pliku odpowiedzi. Ten plik odpowiedzi jest sprawdzany przez program 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>

Ten plik odpowiedzi działa, gdy usuwam część do zmiany folderu użytkowników.

    <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>

Jestem w 100% U:\ katalog jest i próbował zmienić separator katalogu i próbował go zmienić U:\Profiles.

Ilekroć sysprep ten komputer za pomocą następującej komendy:

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

Pojawiają się następujące komunikaty o błędach na logo Windows instalującym urządzenia.

Próbowałem również zaktualizować komputer do najnowszej wersji. Uwaga, mój Windows nie jest aktywowany.

Jak mogę rozwiązać ten problem?

Podejrzewam, że dzieje się tak prawdopodobnie z powodu /generalize opcja.

Zadaniem Sysprep w życiu jest przygotowanie systemu Windows do klonowania. W tym celu usuwa wszystkie informacje specyficzne dla systemu z rejestru - w tym przypisania liter dysku - i wywołuje Instalatora systemu Windows po ponownym uruchomieniu komputera.

Instalator systemu Windows nie przyjmuje niczego o komputerze, na którym „budzi się”. Jedynym powodem, dla którego nawet wie, który dysk jest C: jest to, że sklep BCD to powiedział. Na przykład można zepsuć sklep BCD i zainstalować system Windows na E: zamiast C :. Nie mając żadnych innych informacji o systemie, Instalator rozpocznie wykrywanie urządzeń i przypisze litery dysków w kolejności, w jakiej znajdują się partycje. Jeśli twój napęd U: to np. Czwarta partycja na pierwszym dysku twardym, może zostać przypisana litera F :, a nie U: (Haha Właśnie powiedziałem F: U :).

Jeśli nie używasz /generalize opcja, wtedy Sysprep nie przetworzy ani <Generalize> albo <Specialize> sekcje pliku odpowiedzi (gdzie jest twój CopyProfile ustawienie to). Widzicie więc, że jesteście tu jakby związani.

Spróbuj tego:
Połóż ProfilesDirectory powrót do pliku odpowiedzi i ponowne uruchomienie Sysprep za pomocą /generalize opcja. Gdy się nie powiedzie, spójrz na \Windows\Panther\setuperr.log plik (lub jakiś znajdujący się w nim podkatalog - możesz zobaczyć kilka, więc poszukaj tego z dzisiejszą datą). W tym pliku Instalator systemu Windows powinien podać dokładny powód niepowodzenia procesu (tj. Jaki konkretny przebieg i ustawienie spowodowało błąd oraz jaki miał z nim problem).

UWAGA Microsoft bardzo odradza korzystanie z tego parametru. Ostrzegają, że zmiana z domyślnego uniemożliwi aktualizacje i zablokuje prawidłowe działanie aplikacji Windows Store. W zasadzie nie jest obsługiwany za własną dokumentację funkcji