Latest build .9916 SetupComplete.cmd not executing

cshirley101675

New Member
I am having trouble with testing the latest build v2024.4.9916 and running the SetupComplete.cmd for post-setup unattended installations. My same preset (unchanged) works fine on build v2024.4.9880.

Anything I can take a look at to help debug why this is not working as expected?
 
Attached is my scrubbed preset and SetupComplete.cmd file.

For awareness, I normally copy the $OEM$ folder (with all applicable files/installers) to the image that I am performing work on in the "sources" folder. I do recall, that I had some trouble when we when through the last major upgrade in March. I would like to avoid those same headaches again.

I have also attached the SetupComplete.cmd that is located in the sources\$OEM$\$$\Setup\Scripts folder. Maybe I am not doing things the correct way, but I found that this is easier for me rather than editing the preset .xml file every time I need a simple version change. Hence, the reason for my other post - Exiting Preset XMLs.

I also do realize that the preset I am working on is on a very new pre-release version of Win11 24H2, however when I revert back to build v2024.4.9880, the installation works as expected with no change to the preset or to the SetupComplete.cmd file.

Also, noteworthy - the preset .xml files are now using a different notation in the item types for post-setup execution

<Item type="17"/>
<Item type="18"/>
<Item type="19"/>
<Item type="20"/>

Can we get an explanation of what these Item types equate to? This used to be easier to read (Files, FilesU, etc.) The reason my asking is b/c we have some scripts that will help modify the preset.xml file based on new version of software we want to include in our images.

Sorry for the long winded post, help me if I am doing something wrong.

FWIW - NTLite is an awesome tool and saves me a great deal of time!
 

Attachments

  • Win11_scrubbed_preset.xml
    14.3 KB
  • SetupComplete_scrubbed.txt
    1.8 KB
Item Types are undocumented, but they're not to hard to infer if you have a lot of examples.

<Item type="17"/> Installer files like EXE, MSI
<Item type="18"/> Script file
<Item type="19"/> Single CMD command line
<Item type="20"/> Single PS command line

I will defer to nuhi's explanation of changes past .9880 since I've been using an older build and only upgraded to current as of yesterday.
 
I have no idea whether SetupComplete is blocked on one of your command lines. I'm assuming the ECHO's should actually be REM's but that's your hack to "comment out" different commands.

Anyway, manually test this SetupComplete.cmd:
Code:
@ECHO OFF
(msiexec /i "%WINDIR%\Setup\Files\agentransack_x64_3425.msi" ALLUSERS=1 /passive
msiexec /i "%WINDIR%\Setup\Files\coreftplite_setup64.msi" ALLUSERS=1 /passive /norestart
msiexec /i "%WINDIR%\Setup\Files\Firefox Setup 125.0.2.msi" ALLUSERS=1 /passive DESKTOP_SHORTCUT=false TASKBAR_SHORTCUT=false
msiexec /i "%WINDIR%\Setup\Files\GoogleChromeStandaloneEnterprise64.msi" ALLUSERS=1 /passive
netsh wlan add profile filename=%WINDIR%\Setup\Files\Wi-Fi-test.xml user=all
netsh wlan set profileparameter name=test connectionmode=auto
net accounts /maxpwage:unlimited
powercfg /hibernate off
powercfg /change monitor-timeout-dc 60
powercfg /change monitor-timeout-ac 0
powercfg /change standby-timeout-dc 60
powercfg /change standby-timeout-ac 0
reg import "C:\Program Files\Google\Chrome\Application\Reg_Adobe_ChromeExtension.reg"
wmic csproduct get vendor,name,identifyingnumber,version > %SystemDrive%\system_info.txt) > C:\log1.txt
start cmd /c powershell -NoProfile -ExecutionPolicy Bypass -file "%SystemDrive%\SetupWinget\winget-OEMSetup_part1.ps1" > C:\log2.txt
CALL "%WINDIR%\Setup\Files\RunOfficeSetup.bat > C:log3.txt"
rd /q /s "%WINDIR%\Setup\Files"
del /q /f "%0"

1. Wrap the first block of commands in a subshell, since we know those commands output in the same way. Redirect output to log1.txt
2. The PS script is a separate code block. Redirect to log2.txt
3. No output is really expected from the OfficeSetup script, but if an empty log gets created we know SetupComplete got here.
 
After a bit further investigation is seems that the SetupComplete.cmd file is not getting copied to the C:\Windows\Setup\Scripts directory during creation of the image.

I tried this on both build .9916 & .9919, then reverted back to build .9880 and everything is working as expected.
 
Last edited:
For some reason with builds after .9880, the SetupComplete.cmd file is not getting generated/copied to the C:\Windows\Setup\Scripts directory of the mounted image. I also tested the latest build .9925 and still missing the SetupComplete.cmd file.

What has changed with these builds that would cause this to happen? Or is there a different process we need to start following for unattended installations?
 
I've recently seen that happen, too. It churns away and ends up with an empty Scripts folder. After I switched to a different loaded image, and adding Post-Setup commands to that one -- NTLite created a perfectly good SetupComplete.cmd.

To me, it looks like there's some odd caching behavior.
 
I've recently seen that happen, too. It churns away and ends up with an empty Scripts folder. After I switched to a different loaded image, and adding Post-Setup commands to that one -- NTLite created a perfectly good SetupComplete.cmd.

To me, it looks like there's some odd caching behavior.
I understand what you are suggesting, however, when I revert back to build .9880 everything works as I would expect. If there is some odd caching behavior, I would also expect to see that show up in build .9880 as well.

I have been monitoring a couple of other posts and it seems like there is some is some interesting behavior happening with these later builds.

https://www.ntlite.com/community/in...tegration-not-working-with-9910-or-9916.4412/
https://www.ntlite.com/community/in...te-integration-issue-in-ntlite-versions.4436/
 
Hey garlin, nuhi - Any idea why the "Scripts" folder is not being generated in these newer builds after .9880. I have tried rebuilding again (with clean Win10 iso and still having the same problem with build .9931. I am not getting a Scripts folder created in the generated image.
 
I'm on .9916 and haven't seen a repeat of earlier problems with SetupComplete not writing anything to the ISO folder. I do know if you're manually going to drop things into $OEM$ folder, you should always do this last after NTLite is done processing the image.

The reason is NTLite tries to check what's already in the folders, to figure out some of the work it needs for SetupComplete. Doing it "behind NTLite's back" will sometimes confuse it, and it can't merge the two sets of changes (preset vs. manually copied files).
 
Hey garlin, nuhi - Any idea why the "Scripts" folder is not being generated in these newer builds after .9880. I have tried rebuilding again (with clean Win10 iso and still having the same problem with build .9931. I am not getting a Scripts folder created in the generated image.
Hi,

first time seeing this topic for some reason, so let me sync up.

Tested your preset using the latest version, and indeed the script is not where one would expect it.
However, it's in the image.

Check inside of the image (right-click loaded image and choose Explore mount dir).
There go to Windows\Setup\Scripts

End effect is the same, I'll see why the tool chose the internal location in this case, maybe using only commands had something to do with it.
It's not a bug per say, I even like it like this as there are no files to increase the size of the image to be kept outside of the main WIM\ESD, more portable like this.

This internal switch usually is meant only for when editing an isolated (outside of ISO dir structure) WIM image.

Let me know if you see any issues with this, to increase the importance of the task, for me this is fine.
 
Hi,

first time seeing this topic for some reason, so let me sync up.

Tested your preset using the latest version, and indeed the script is not where one would expect it.
However, it's in the image.

Check inside of the image (right-click loaded image and choose Explore mount dir).
There go to Windows\Setup\Scripts

End effect is the same, I'll see why the tool chose the internal location in this case, maybe using only commands had something to do with it.
It's not a bug per say, I even like it like this as there are no files to increase the size of the image to be kept outside of the main WIM\ESD, more portable like this.

This internal switch usually is meant only for when editing an isolated (outside of ISO dir structure) WIM image.

Let me know if you see any issues with this, to increase the importance of the task, for me this is fine.
nuhi - Thanks for getting back with me on this. I tested build .9931 on a clean Win10 image. I only added one file to Post-Setup (Before Logon) to make things quick. I can see the files and scrips being added to the ISO image in the \sources\$OEM$\$$\Setup folder, however, when I load the image right-click and explore the mount directory, I do not see a scripts directory created in Windows\Setup\Scripts which is where I would expect the SetupComplete.cmd to reside.

On an older build .9880, everything is working as I would expect using the same process as I have always been using.

Attached is the preset that I have used and the corresponding directory of the mounted image.

1715780945668.png
 

Attachments

  • Test.xml
    5.5 KB
Back
Top