Multi-OEM/Retail Project {MRP} - Mk3

thats on VMWare itself, vmplayer not have that option (unless they added it now)

 

ooh i not seen the uefi.secureboot.enabled bit before

 

im still on vmware 12 so it must be new to v14

 

[AMHDC] Controller Mode : NVMe/PCIe {SCSI Controller} usually it is SAS/Scsi.... it must alter something else..

 

Shows i not play about with the options in VMWare Workstation lol

Damn wish i checked the options in VMware i could of sped up the testing of the QT lol

 

I know Vbox could emulate a SSD via the options. Interesting about VMware.... Think it might get some more hammer now

 

There will be a update to the Query tool shortly...

Main code is the same just a tweak to the License check area.

It is a rare thing that a nul result is returned, it seems if the token store is corrupted it can throw a spanner into the works and no text will be shown where the part that says:

#14 License Status - Nothing would appear here!

Now if something is screwed up with the activation or token store:

#14 License Status - Undefined/Corrupted Token Store

Will be shown.

Thanks to @Enthousiast for bringing that to my attention.

Usually the result would be a numeric value 0 to 6 returned which is converted into a human understandable result.

The next MRP will have this 'fix' added although i doubt it will really need it, as on a fresh install as it will be a normal 0 - 6 result - unless someone has modified the OS WIM prior to installation. Or used a Gen2 ISO that is known to screw up a few things with MRP.

 

Query Tool v51.1 has been uploaded and 2nd post updated with link and password.

Quick Summary

+ Fixed a small glitch if the License Status returns a nul or out of range result which indicates a possible Token Store corruption or other problem with the activation status. Thanks @Enthousiast for bringing that to my attention.

+ Also fixed a small bug that at times would show errors when checking the Drive Controller section under some OS's (7 usually) if the controller is not present.

+ Added {I} or {S} after the Controller Mode text to indicate if it was SCSI or IDE that returned the result.

No other changes to code.

 

During install some of the later tweaks are not effective until the reboot/log-out cycle is done once the desktop appears. I think i have already mentioned that.

Driver blocking i will add a note about it in the next Creator and in the readme's.

On next Creator the tool-tip shows the note about being connected etc and the .ini has this:

Code:

# Windows 10 Kernels Only
# :DisableDriverSearching - This Enables or Disables the Driver Searching within Windows.
# This option turns off or on the Driver Searching used in Windows Update.
# Note as this option tweaks a policy setting you will see a message about 'Some settings are managed by your organization' this is normal.
# This does not work for Windows 10 Home/Core Editions, MRP will ignore this option on those Editions.
# Also note that during installation of the OS to prevent drivers from being downloaded make sure the device is NOT connected to the internet.
# Default No.

Not everyone uses a Local account, some use online accounts, so the note will be now present for the user to decide.

Spoiler: Additional

The driver blocking tweak is ran in the early stages of oobe/MRP, there is a reboot cycle that happens before the user name entry etc, the driver tweak should in theory then have been set at this point.

It is not reverted as once that cycle been done as it is then locked in place. -- unless m$ are aware of that tweak now during Setup and totally ignore it. If so nothing i or MRP can do to fix that, only to say disconnect from net during installation of the OS but you will loose the ability to use your online M$ account during user setup stage as only Local Account is available, you can switch to online account later if required.

If you notice the project.log has a gap between the first section and the addon manager:
[BSHCS] Branding script has completed.
<the gap here>
[ADMAN] Add-On Manager: Started.

This gap indicates the reboot cycle setup does and it is within this cycle that the tweaks that have 'applied' at the end of their lines have been completed.

Plus during that cycle on the next boot Setupcomplete.cmd, (possibly FirstLogon.cmd), is ran if either is present, after those have completed the add-on manager section is then executed and the tweaks with 'enabled' at the end of their lines are then 'applied' and shown in the log.

This is why i made a note that if you use the setupcomplete.cmd/FirstLogon.cmd not to have a reboot cycle such as Shutdown /r (/l or /s), or remove the Scripts folder with a line of:

RD /S /Q "%windir%\Setup\Scripts"

- within those scripts, as then MRP's files would be deleted and the log will stop at the branding part!

When MRP completes fully, (or there is a fatal error within the branding script that aborts the project), it will automatically remove the Scripts folder and contents to tidy things up.

*For the next MRP release*
I have now added a simple detection routine at the end of the branding script that if either SetupComplete and/or Firstlogxx .cmd's are present that a note is made in the log that they are there.

So if the Project.log stops at this point then it is known that something in those scripts caused MRP to fail completion, either due to a reboot/log-out cycle or premature deletion of the Scripts folder.

Same applies to UserTweaks and Wintel .cmd's if they are edited to have a reboot/logout cycle or deletion of the Scripts folder then MRP and the log will also stop at this point.

 

I have had that a couple of times when testing the insiders, also once on a rs3 install too although that was after the latest CU (march).