Invalid Specialize Pass When Using Custom Scripts

[SuperJC710e]

First of all, thanks for this awesome resource! It's been very useful! :)

I'm testing out the new addition of the Custom Script options. However, as soon as I add in one or more scripts, it breaks the answer file. The initial setup phases complete, but then it errors out complaining about an invalid specialize pass. Here's a screenshot:

I've now tested this one without any scripts, and the answer file still works fine as usual. However in testing once in a Windows 11 23H2 with 2 script sections (both powershell), and then with Windows 10 22H2 with a single powershell script section it fails with the above error. I'm including a URL to that most recent answer file.

URL: autounattend.xml

I had to look up what was going on with the <nul set /p= section of the redirection. I see it's useful to prevent newlines and the <nul prevents it from asking for input. However, I wonder if it's then setting the errorlevel to 1 as in these answers and that is causing the setup to think there is an error? (Totally not my area of knowledge, so I could be way out in left field...)

Anyway, hopefully we can find a fix for this. Thanks in advance! :)

[SuperJC710e]

An update, I recreated the script section with shortened lines which avoided any of the <nul set /p = redirection, however, the error still occurred, so it must be something else that is causing it.

URL: autounattend.xml

Here's the script I included in the "Run these commands whenever a user logs on for the first time" section (I reduced a couple more spaces in this one...):

$RegPath1 = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize'
$RegItem1a = 'SystemUsesLightTheme'
$RegItem1b = 'AppsUseLightTheme'
if (-NOT(Test-Path $RegPath1)){New-Item -Path $RegPath1 -Force|Out-Null}
New-ItemProperty -Path $RegPath1 -Name $RegItem1a -Value 0 -PropertyType DWORD -Force
if (-NOT(Test-Path $RegPath1)){New-Item -Path $RegPath1 -Force|Out-Null}
New-ItemProperty -Path $RegPath1 -Name $RegItem1b -Value 0 -PropertyType DWORD -Force
$RegPath2 = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Search'
$RegItem2a = 'SearchboxTaskbarMode'
if (-NOT(Test-Path -Path $RegPath2)){New-Item $RegPath2 -Force}
New-ItemProperty -Path $RegPath2 -Name $RegItem2a -Value 0 -PropertyType DWord -Force
$RegPath3 = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\MultiTaskingView\AllUpView'
$RegItem3a = 'Enabled'
if (Test-Path -Path $RegPath3){Remove-ItemProperty -Path $RegPath3 -Name $RegItem3a -Force}
$RegPath4 = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced'
$RegItem4a = 'ShowTaskViewButton'
if (-NOT(Test-Path -Path $RegPath4)) {New-Item $RegPath4 -Force}
New-ItemProperty -Path $RegPath4 -Name $RegItem4a -Value 0 -PropertyType DWord -Force

[cschneegans]

The problem was that the command reg.exe add "HKU\mount\Software\Microsoft\Windows\CurrentVersion\Runonce" /v "C:\Windows\Setup\Scripts\unattend-01" /t REG_SZ /d "powershell.exe … became longer than 256 characters, and this happened because the registry value name was erroneously set to C:\Windows\Setup\Scripts\unattend-01, while the intended value name is simply unattend-01.

This has now been corrected via https://github.com/cschneegans/unattend-generator/commit/5fb224bfc56d74a7b6a7de373189377bbfc9279b. Thanks for your report!

[SuperJC710e]

Thanks Christoph, I'll test it out. Also, good to know about the 256 character limitation, I think I knew that somewhere in the deep recesses of my mind, but good to have that memory refreshed! 👍

Update: So I did test it out. The answer file works fine, however, the script itself is not created. Do we perhaps need to create the Scripts directory first? I think C:\Windows\Setup exists by default, but not the Scripts sub-directory.

[cschneegans]

The answer file works fine, however, the script itself is not created. Do we perhaps need to create the Scripts directory first? I think C:\Windows\Setup exists by default, but not the Scripts sub-directory.

You are exactly correct. I didn't notice because I had previously added the …\Scripts\Setup\SetupComplete.cmd file to all my Windows images. Fixed via https://github.com/cschneegans/unattend-generator/commit/4d546f1df0c53fbf3dcbdd06aeffd2517e083d09.

[SuperJC710e]

Yay! It's working now! (Some of my customizations aren't working, but that's not a fault of this!) Many thanks! Great work! :)

PS: I noticed one small thing with the URL in the comments....it doesn't seem to preserve the setting for the Keyboard Layout selected. For instance I usually select "English (Canada)" which sets the Keyboard Layout to "Canadian French" by default. I generally change that to "United States - English". However, when I use the URL from the answer file, the keyboard layout reverts to the default (Canadian French). Just a small niggle...I'm fine with it, but if you want to look at it, let me know if you want a new issue opened for it...

[cschneegans]

PS: I noticed one small thing with the URL in the comments....it doesn't seem to preserve the setting for the Keyboard Layout selected. For instance I usually select "English (Canada)" which sets the Keyboard Layout to "Canadian French" by default. I generally change that to "United States - English". However, when I use the URL from the answer file, the keyboard layout reverts to the default (Canadian French).

Correct again. If a user locale has an associated keyboard layout, that layout was selected unconditionally. The new behavior is to keep the keyboard layout when one is present in the KeyboardLayout query string parameter.

[SuperJC710e]

PS: I noticed one small thing with the URL in the comments....it doesn't seem to preserve the setting for the Keyboard Layout selected. For instance I usually select "English (Canada)" which sets the Keyboard Layout to "Canadian French" by default. I generally change that to "United States - English". However, when I use the URL from the answer file, the keyboard layout reverts to the default (Canadian French).

Correct again. If a user locale has an associated keyboard layout, that layout was selected unconditionally. The new behavior is to keep the keyboard layout when one is present in the KeyboardLayout query string parameter.

Excellent! Once again, thanks so much for your excellent work! I'll close this issue now! 👍