How does NTLite fake Setupcomplete.cmd with an OEM key?

[garlin]

Why bother with the hassle? Reg files imported by Registry are integrated into the image's hives. The reg values are present when Windows first reboots after WinPE exits, and are ready long before OOBE starts.

Doing it with RunSynchronous is a lot more work, when integration does it in one step.

 

[nuhi]

it's enough
the "enable built-in Administrator" is just an example to use PreOobe key

Thanks, this gives a solution to a long-term annoyance.
Will rename the setupcomplete to something ntlite specific, so it's not triggered twice for those without an OEM key.
Always use this method for machine tasks, so can remove the OEM SetupComplete option.

 

[garlin]

Before moving ahead, please carefully consider the long history of how NTLite has supported SetupComplete, and its OEM workaround. All changes must respect backwards compatibility, because we have too much historical weight.

Here's my proposed fix:
1. Continue providing OEM SetupComplete as a non-default option.

2. When selected, NTLite writes a Setup\FirstBoot\PostOobe runtime script, which looks for OA3xOriginalProductKey.

3. SetupComplete is only executed if an OEM key is present, otherwise the script exits.

This logic prevents SetupComplete from dual execution on other PC's without keys. Nothing needs to be renamed, users don't have to learn anything new. A few factors come into play, as both Wscript/Cscript and WMIC are deprecated, and will eventually become optional features. Maybe PS can be a lasting solution?

 

[nuhi]

Thanks garllin.
Agreed on keeping it as same as possible.

Let me explain what was done so far and why:

- keep filename as setupcomplete.cmd
to keep using NTLite as a convenient editor that automatically picks up those entries, if any, no actual benefit in renaming it.

- add PostOobe call to it for all Win10 and newer versions
SetupComplete.cmd generated by NTLite already auto-deletes itself, so those without the OEM key won't double-execute it as I feared.
Only angle where this might be bad is if someone replaces the setupcomplete.cmd with their own, or removes the self-delete line (invisible in the UI).
Will clean the entry if someone removes all post-setup machine tasks from the UI.

- remove OEM SetupComplete option
not actually needed any more, and was one of the most common questions why post-setup doesn't work, until they find that option.
Could be also exposed and automatically enabled instead, let me know what arguments you might have in that direction, when would someone want to disable it.
I am not a fan of adding scripts to the ISOs if it can be avoided, otherwise a great idea how it would work.

 

[muelltonne2011@rz-online.]

ashes on my head bc of Rufus / NTFS / and Secureboot.

i tried it on two PC with two USB sticks...

PC A had an old UEFI version ( and USB stick was FAT/NTFS)
PC B has an updated UEFI / BIOS,
i was wondering why it failed then on PC B as i updated the UEFI, USB stick two had FAT/exFAT partitioning (facepalm)
It works now as expected with Rufus signed NTFS driver and Windows 11 Pro / UEFI and Secureboot.