[unattended - specialize] Product Key causing setup failure

T

TT9tWhD$q

Member
  • host W10 Pro x_64 1909 b18363.657
  • target same as host
  • NTL 1.9.0.7304 Home portable
This happens when having set a product key in unattended -> specialize.

IMG_20200220_122944.jpg

Removing the key and the issue does not exhibit. With the same key set in unattended -> user settings -> product key -> product key (setup) the issue does not exhibit either.
 
I even had that error with keys are empty... i solved it by placing autoattend.xml file in the root folder of iso.. (it was in panther folder)
so i assumed that it was problem about reading xml file at panther folder...

also this error is happening if setupcomplete.cmd is empty

idk why, it was working perfectly before. those 2 things started after a ntlite update, i think it was a update about unattend setups because after that update the xml files were always generated differantly than before with same presets

i kept those old xml files, now i'm deleting what ntlite generated and using old ones. i wrote about this to nuhi but he didn't solve it because i couldn't explain it to him good or he didn't believe me and didn't want to understand me
 
you will get that error if there is another autounattend.xml(for another os or edition) lurking on the system somewhere, a storage drive or usb key for example, the setup gets confused. if you have 2 for the same os/edition it might be ok.
 
NTl seems to placing the autoattend.xml file in the root folder by default and thus does not seem to be the cause. I suspect rather some
ege914 said:
i solved it by placing autoattend.xml file in the root folder of iso
Click to expand...

NTL is placing that file in the root anyway, least on my node it does.
______
Clanger said:
you will get that error if there is another autounattend.xml(for another os or edition) lurking on the system somewhere
Click to expand...

there is no other such file present on the ISO produced by NTL but there are a bunch of Auto-saved session{}.xml files and at least one of those contains the product key present in autounattend.xml.

Do you mean that as potential source of confusion albeit the files names not bein related? Else I am not understanding what you are trying to say with

Clanger said:
lurking on the system somewhere
Click to expand...

system = host or target?
 
on the target during install. if you are install pro edition and have another xml for home setup gets confused because the data in them is conflicting. if you keep multiple os on the usb install key and you need to have a different autounattend.xml for it then just rename it to Xautounattend.xml.txt, setup will only look for autounattend.xml :)
 
Clanger said:
you will get that error if there is another autounattend.xml(for another os or edition) lurking on the system somewhere, a storage drive or usb key for example, the setup gets confused. if you have 2 for the same os/edition it might be ok.
Click to expand...

there was not. actually its fixed when i placed seccond one on root of the usb. its not my fault mate sry...
 
In the ISO created by NTL the autounattend.xml is present only once, in the root, not sure whether it gets moved/copied during setup to %windir%\Panther or remains in %systemdrive%.

Since the target (testing) is physically on the same machine (same hard drive, different partition) and thus presenting a dual boot scenario I am wondering whether this might be the cause eventually, i.e. that setup is somehow reading the host file structure and though it does not contain another autounattend.xml but perhaps a product key gets confused. Plus a search on the host turned out shortcuts for autounattend.xml on the target (recent items) which may or may not compound the issue.
Guess will have to see whether it works out on a clean target.
 
With an install on a clean (non-dual boot) target the issue still exhibits (meantime NTL updated to version 1.9.0.7330). This seems some sort of bug.
 
The product key can be set in two places, as you noticed, Setup and Activation.
Setup one accepts generic keys, while Activation one doesn't, and errors out if one is used.

So, since Windows 10 is relying on hardware ID for activation anyway, if it was already activated, leave it empty, if setting up a new machine never before activated, put a real activation key in the Activation product key, not the generic ones.
 
The issue only happens when the key is present in the Activation section, independent of whether the same key is present in the Setup section. The key is not generic but a real W8.1 retail key (that also works for W10) from my MS Technet subscription (back in the day).

What is baffling is that there is no issue with the key in the Setup section.
 
You must log in or register to reply here.
Back
Top