Environment: 64-bit Windows 10 Enterprise preview, build 10074 (the latest ISO onto a clean disk) on both bare metal and in a VMware VM.
Using an XML file based on one that worked well with Windows 7 and 8 (and deleting obsoleted nodes) everything works fine...until the setup program reaches the end of the specialize step. In both Windows 7 and 8 the setup logic moves from Pass 4 (specialize) to pass 7 (OOBE System), but then discovers that the XML file contains a RESEAL node showing MODE (under Microsoft-Windows-Deployment in the OOBESystem pass) to be set to AUDIT, as a result of which it ignores everything else in the OOBE section of the XML and sends control back to pass 5 (Audit System).
This behavior is documented in https://technet.microsoft.com/en-us/library/cc709627(v=ws.10).aspx . Note that the only other value valid in the RESEAL mode is "Force Shutdown Now", which has a default value of FALSE so it does not appear in the XML file. The page cited above states " If the configuration pass is oobeSystem, this means that all remaining oobeSystem settings, such as FirstLogonCommands, are ignored if the Mode value is Audit and ForceShutdownNow is set to false."
Problem: Windows 10 setup ignores this setting, and proceeds to process the OOBE settings (including running the "First Logon" commands), but the system remains in setup mode.
This breaks the build logic, since we need to build a master image for distribution to our staff but there's no obvious way to prevent the OOBE logic from running during the setup build.
The relevant XML text (heavily snipped to remove unnecessary lines) is:
<component name="Microsoft-Windows-Shell-Setup" [...]">
<FirstLogonCommands> [lines snipped for brevity]
<component name="Microsoft-Windows-Deployment" [...]">
The script (which should not have run at this point) dumps the sysprep status entries from the Registry to a log file:
SYSPREP stage (OOBESystem) entered
** ImageState: IMAGE_STATE_UNDEPLOYABLE
** GeneralizationState: 0x7
** CleanupState: 0x2
** specialize: 0x9
** oobeSystem: 0x9
** windowsPE: 0x0
** offlineServicing: 0x0
** generalize: 0x0
** auditSystem: 0x9
** auditUser: 0x5
Any ideas what's happening, and what can be done to fix it?