Bypass of online Microsoft account creation is ignored if none of SB/TPM or RAM/Disk bypasses are selected

[pbatard]

First of all: "Ah Microsoft, for crying out loud!!!"
Second: This is NOT a bug from Rufus (such as us forgetting to add a section in the unattend.xml), but a result from a stupid-ass decision from Microsoft not to run anything from the specialize pass of an unattend file during initial setup unless there exists a windowsPE pass.

This means that, if you have something like:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="windowsPE">
     (...)
  </settings>
  <settings pass="specialize">
    <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" language="neutral" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS">
      <RunSynchronous>
        <RunSynchronousCommand wcm:action="add">
          <Order>1</Order>
          <Path>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f</Path>
        </RunSynchronousCommand>
      </RunSynchronous>
    </component>
  </settings>
</unattend>

Then the reg command from the specialize pass to add the BypassNRO registry key will be applied.

But if you have:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
  <settings pass="specialize">
    <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" language="neutral" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS">
      <RunSynchronous>
        <RunSynchronousCommand wcm:action="add">
          <Order>1</Order>
          <Path>reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f</Path>
        </RunSynchronousCommand>
      </RunSynchronous>
    </component>
  </settings>
</unattend>

Then the reg command and everything inside your specialize pass is ignored.

As you may guess, in Rufus 3.19, the SB/TPM and RAM/Disk bypass are part of a windowsPE pass, and therefore that section does not get created if these options are unchecked which in turn, due to the issue above, prevents BypassNRO from being applied, which in turn means that the option to bypass the online account creation gets completely ignored...

This is not a new issue with Microsoft's unattend file, as other people have reported this exact problem some time ago. And the other problem is that if we decide to work around this issue by adding a bare minimum windowsPE section, then people will complain that the Setup screens are changed, and that the "Repair your PC" option is no longer offered to the user (#1971).

And we can't just inject an Autounattend.xml in \Windows\Panther\ for the image that Windows Setup will apply either (like we do for Windows To Go, where we did validate that the MSA bypass did work regardless of whether there was a windowsPE pass... since having a windowsPE pass is completely irrelevant then), because we'd then have to mount about a dozen install.wim images on account that, unlike what is the case for Windows To Go, we have no idea about the edition the user is going to select. There also doesn't appear to exist a way to have the windowsPE pass duplicate the Autounattend.xml we inject at the root of boot.wim to the newly applied image, as Microsoft does not offer a post apply Startnet.cmd equivalent...

The way it currently looks, there's a good chance that we'll have to revert the workaround we applied for #1971 and have a windowsPE pass always (whilst losing the Repair your PC option always) whenever the user selects the option to bypass MSA...

What a massive pain in the ass this inconsistent unattend.xml behaviour from Microsoft is turning out to be. And that's not even counting the other brain-dead changes they introduced in Windows 10 2004 where you are now forced a gunpoint to provide a ProductKey section in the windowsPE pass, even if it's just to provide a blank/invalid key...

[pbatard]

Yup, confirmed that if you don't have a windowsPE section, the installer "forgets" to copy the Autounattend.xml from the root of the PE image to the installation drive's \Windows\Panther\unattend.xml, and without unattend.xml there, you can forget about anything being applied.

This looks like a bug from the Microsoft installer, because as it parses Autounattend.xml to see if there's a windowsPE pass, it should look at whether later passes also exist in that file, and make sure to carry out these passes for the next step of the install. Microsoft however seem to allude that this is expected bahviour here when they state:

• Create an answer file that is named Autounattend.xml that includes settings in the windowsPE configuration pass.
• Because the answer file (...) includes valid settings for the current configuration pass (windowsPE), this answer file is used (and) is cached to the computer.

Thus the documentation seems to allude that if the unattend file has no windowsPE pass, it will not be cached (which is utterly illogical, but at least Microsoft are kind of documenting the idiotic behaviour of their software).

Now, if WinPE had something like being able to execute a command on shutdown/reboot or post apply image, we could still try to work around the present situation by duplicating our file to \Windows\Panther\ manually, but what can be accomplished in PE phase is seriously limited, and unlike what you could do in regular Windows, there doesn't appear to exist a possibility to even accomplish something as elementary as this...

[pbatard]

Finally, I think I have a workaround, but sheesh, the lengths one needs to go through just to get Windows Setup parse an answer file. And yes, this will be the 3rd (4th?) solution I implement for what should be a simple straightfroward task.

The trick is to use \sources\$OEM$\$$\ to add content that you want to get copied over to the target %WINDIR% directory by the installation process.

This means that if we copy our unattend file to \sources\$OEM$\$$\Panther\unattend.xml on the USB media, then it will be copied over to C:\Windows\Panther\unattend.xml at the end of the file copy phase and will be picked up for processing by the specialize pass.

And now off to adding more cumbersome logic to decided whether we need to create an $OEM$ directory, and validating that every scenario works as expected...

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.