NTLCompName.vbs and ComputerName property in Specialize pass

Emerica243

New Member
I cannot for the life of me understand why if I enter a value or * or leave the "ComputerName" field unconfigured within the specialize\shell pass that it breaks the entire process of OOBE. Meaning instead of OOBE coming up as expected, you get a long black screen of "Please Wait" until it ultimately dumps you at the ctrl+alt+del screen where you cannot login to the device with the only present account which is the built-in administrator because of a bogus error being thrown. Its like the entire OOBE never happened so Windows isnt fully setup correctly.

Also what is this NTLCompName.vbs script that looks custom to NTLite? I understand if you use the [PROMPT] value there it spawns this VBS to rename the computer at that point. But why would you want to do that and why not leverage the ComputerName value how it natively is within the unattend\unattended process? I've been able to achieve what i want by using %SERIAL% in this field but i want to use * so its just a random generated value that shouldnt be reliant on this vbs script. Ive ever configured the Owner\Full name fields becuse i thought its supposed to prefix off of that. But it still just breaks the entire process if i use anything other then %SERIAL% or [PROMPT]. And again, how is this custom NTLCompName.vbs script injected to have the OOBE process to leverage off of a [PROMPT] value to even spawn it?
 
Normal users don't need any of the ComputerName special fields. Either you pick a specific Name, or Windows randomly generates one.

The real reason for creating a random Name is to prevent any two PC's booting up, and claiming the same hostname. That can cause huge problems in an Active Directory domain. For Active Directory, a new PC may have a temporary Name which gets replaced after it joins the domain.

https://learn.microsoft.com/en-us/w...osoft-windows-shell-setup-computername#values
If ComputerName is not specified, a random computer name is generated.

If ComputerName set to an asterisk (*) or is included but empty (""), Windows creates a random 15-character name using up to 7 characters from FullName and Organization, then a dash, then more random characters.

ComputerName is a string with a maximum length of 15 bytes of content:
  • ComputerName can use ASCII characters (1 byte each) and/or multi-byte characters such as Kanji, so long as you do not exceed 15 bytes of content.
  • ComputerName cannot use spaces or any of the following characters: { | } ~ [ \ ] ^ ' : ; < = > ? @ ! " # $ % ` ( ) + / . , * &, or contain any spaces.
  • ComputerName cannot use some non-standard characters, such as emoji.
Computer names that cannot be validated through the DnsValidateName function cannot be used, for example, computer names that only contain numbers (0-9). For more information, see the DnsValidateName function.

"*" can only be used when FullName and Organization are provided.

When you're using NTLite tags like %SERIAL% or [PROMPT], it copies NTLCompName.vbs script to C:\Windows\Setup\Scripts and the install sequence runs it during the appropriate pass. Normally this is done ahead of a pre-scheduled reboot, so the rename takes effect.

The order of execution (not too early, not too late) can be very important for things to work as expected. What you're really asking about is how Windows install performs each of the setup steps in sequence. That takes a lot of studying MS docs, and reading other online references.

Custom commands or scripts be executed via:
- Unattended file SynchronousCommands (or Async)​
- SetupComplete.cmd script if it exists​
- RunOnce or RunOnceEx reg keys​
- Created scheduled tasks​
 
Normal users don't need any of the ComputerName special fields. Either you pick a specific Name, or Windows randomly generates one.

The real reason for creating a random Name is to prevent any two PC's booting up, and claiming the same hostname. That can cause huge problems in an Active Directory domain. For Active Directory, a new PC may have a temporary Name which gets replaced after it joins the domain.

https://learn.microsoft.com/en-us/w...osoft-windows-shell-setup-computername#values


"*" can only be used when FullName and Organization are provided.

When you're using NTLite tags like %SERIAL% or [PROMPT], it copies NTLCompName.vbs script to C:\Windows\Setup\Scripts and the install sequence runs it during the appropriate pass. Normally this is done ahead of a pre-scheduled reboot, so the rename takes effect.

The order of execution (not too early, not too late) can be very important for things to work as expected. What you're really asking about is how Windows install performs each of the setup steps in sequence. That takes a lot of studying MS docs, and reading other online references.

Custom commands or scripts be executed via:
- Unattended file SynchronousCommands (or Async)​
- SetupComplete.cmd script if it exists​
- RunOnce or RunOnceEx reg keys​
- Created scheduled tasks​
Thanks for the reply. You've answered some of my unknowns. Given the fact I dont want to use %SERIAL% or [PROMPT], since I have no need to have a custom renamed machine like that at that point. Why when i do NOT configure the ComputerName value in this specialize pass or provide a * value while also providing FullName and Organization values are provided, the problematic outcome is observed? Ive tried every combination of providing values while having * or nothing for ComputerName in this case and it always provides an outcome of OOBE never being executed. But instead like i said, a Please Wait black screen for 5 minutes or so then ultimately ctrl+alt+del being showing with Administrator and Guest both being unable to be logged into.
 
Are you using any special characters for FullName or Organization? It sounds like OOBE is waiting to timeout on a network call, like it wants to join a domain or something. Also, check if you've removed any components that OOBE requires (make sure you didn't uncheck OOBE compatibility).
 
Are you using any special characters for FullName or Organization? It sounds like OOBE is waiting to timeout on a network call, like it wants to join a domain or something. Also, check if you've removed any components that OOBE requires (make sure you didn't uncheck OOBE compatibility).
Nope I did not remove any components. Actually the customizations in its entirety is pretty simple, its just unattend configs being made. All thats being set is the following. Again if i use %SERIAL% as shown all works as expected. If i not configure it, or choose * i get into the problematic state.
 

Attachments

  • Untitled.png
    Untitled.png
    44.5 KB
I don't think it's a NTLite bug.

When I try "*" with EMPoC/EMPoC, OOBE times out to a logon screen listing Administrator & Guest -- a definite sign that OOBE didn't complete the provisioning process.

Code:
                <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                        <ComputerName>*</ComputerName>
                        <RegisteredOrganization>EMPoC</RegisteredOrganization>
                        <RegisteredOwner>EMPoC</RegisteredOwner>
                </component>

Windows 10 x64-2023-06-14-13-02-20.png

To find out what's wrong, I employed the Ease of Use hack to bypass the broken logon screen. Boot off a normal ISO, open a CMD window with shift-F10 and proceed to replace \Windows\System32\Utilman.exe with cmd.exe.

Now click on the Ease of Use button. The PC has a default name of MINWINPC, but it's ignored the Registered Owner and Org:

Windows 10 x64-2023-06-14-13-26-03.png

If I had to guess, probably you can't do "*" with Owner = Organization. Obviously more testing required.
 
I don't think it's a NTLite bug.

When I try "*" with EMPoC/EMPoC, OOBE times out to a logon screen listing Administrator & Guest -- a definite sign that OOBE didn't complete the provisioning process.

Code:
                <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                        <ComputerName>*</ComputerName>
                        <RegisteredOrganization>EMPoC</RegisteredOrganization>
                        <RegisteredOwner>EMPoC</RegisteredOwner>
                </component>

View attachment 9869

To find out what's wrong, I employed the Ease of Use hack to bypass the broken logon screen. Boot off a normal ISO, open a CMD window with shift-F10 and proceed to replace \Windows\System32\Utilman.exe with cmd.exe.

Now click on the Ease of Use button. The PC has a default name of MINWINPC, but it's ignored the Registered Owner and Org:

View attachment 9870

If I had to guess, probably you can't do "*" with Owner = Organization. Obviously more testing required.
nice tricks. I usually leverage the sticky keys sethc.exe replace method, all the same. Anyway, if youre thinking its because of both of those values being identical i would say no. Ive tried unique values, no difference.

Ive done so many iterations so id have to retest, but to be honest i want to say even when i reset the entire unattend sheet to defaults(ntlite defaults of nothing configured) i think i recall it doing the same thing. Which is bizarre to me no one else has experienced this?
 
This is weird, now I can't repeat my previous results and it's worked twice on a clean image. For the record, all I'm doing is stripping it down to one edition (Pro) and just adding Unattended settings. Not sure why it failed at least once, which tells me this problem is entirely possible but I don't know what the controlling factor was.

More testing to follow...
 
This is weird, now I can't repeat my previous results and it's worked twice on a clean image. For the record, all I'm doing is stripping it down to one edition (Pro) and just adding Unattended settings. Not sure why it failed at least once, which tells me this problem is entirely possible but I don't know what the controlling factor was.

More testing to follow...
Nothing useful nor sticks out in any of the Panther logs to me either.
 
This is weird, now I can't repeat my previous results and it's worked twice on a clean image. For the record, all I'm doing is stripping it down to one edition (Pro) and just adding Unattended settings. Not sure why it failed at least once, which tells me this problem is entirely possible but I don't know what the controlling factor was.

More testing to follow...
Any remaining thoughts or testing here?
 
Unless you have a test case which recreates the bug, it's hard to isolate the starting conditions.

I haven't been able to make it fail on a clean install image, using the Unattended settings. * is a built-in directive for Windows setup, so we're left with only a small possibility NTLite gets tricked into running NTLCompName.vbs when it actually doesn't need to.
 
Unless you have a test case which recreates the bug, it's hard to isolate the starting conditions.

I haven't been able to make it fail on a clean install image, using the Unattended settings. * is a built-in directive for Windows setup, so we're left with only a small possibility NTLite gets tricked into running NTLCompName.vbs when it actually doesn't need to.
I dont want to speak too early. But i deleted all my presents\source files\everything and started fresh with new ISOS and everything. So far im going small changes by changes and everything seems to be acting as expected as far as Unattend config changes are made. So hoping something was just in a very odd state somehow and i dont have to ever think of it again. Will update my post here after im finished with all Unattend changes + update integrations + post setup adds, etc to ensure its all finally in a expected working state.
 
Back
Top