Multi-OEM/Retail Project {MRP} - Mk3

It could be added as a advanced option and when selected the user is informed of the risks involved.

But as enabling it could potentially cause major issues with the os. Which is something im not comfortable with because there may not be a way to revert it as the os might be unrecoverable or bootable.

It could be added like the special variable used to tell mrp not to wipe the scripts folder.

That way the user has to add the variable in the oobe.cmd and mrp would then act on it accordingly. It could not be selected by accident.

Let me think about it, time not been on my side recently plus it would need testing.

May have to only be allowed on certain os's.

 

As soon as i can squeeze some time i will see what i can do.

Im still thinking of the oobe.cmd variable method to be used as it a safety procedure as the user has to add it in and it not a select by accident option.

 

Added HVCI check into the next Query Tool

Result from my laptop:

Code:

WMIC.exe Command           : Present
HVCI Protection Status     : N/A
Trusted Platform Module    : No TPM instances found 

If present it will say Enabled {0x1} or Disabled {0x0} if the registry key/value is present.

It will be probably be 'N/A' on most OS's as key value not exist -- this is just to keep the QT result log aligned.

Uploaded to beta testing area for beta testers.

MRP coding will be next on my list. It will only be available via the oobe.cmd to prevent a user from just clicking the option and then ending up with a unusable OS. This way the user will have to enter the value for the variable and be conscious of that decision as by default the variable will be UNSET.

As i am unsure if HVCI is present in any CORE/HOME editions - which i don't think it will be, then will be ignored.

This special 'option' will be ignored on those Editions also anything below build 19041 to be safe.

For Server OS's it will also be ignored - just to prevent any issues, it is then up to the user to manually set it on or off - usually left alone as you want a Server to be as secure as possible!

Please note that force enabling this OS feature for a OS build that not fully support it could render your OS shafted!!!

MRP will try to prevent such events happening and will just ignore it when the flag is not set to allow it to be changed.

The special variable will have three settings:

Not defined = Left as OS Default, this could be default ON for those supported OS's as defined by M$.

Disabled = Force set the registry value to zero (0x0) to set as Disabled regardless if m$ set it as enabled or not.

Enabled = Force set the registry value to one {0x1} to set as Enabled regardless if m$ set it as disabled or not.

 

Example of the variable setting that will be in OOBE.cmd - by default when i upload the next new project -- it will be in a UNSET state as shown.

Code:

REM Enable/Disable Virtualization Based Security = Set variable to Enabled or Disabled to force set registry value.
REM MRP will ignore if certain criteria is not met or could be dangerous to the OS. Leave as unset for OS Default.
SET "HVCI_Setting="

DISCLAIMER
The end user will be responsible if they set this special option as 'Enabled' and/or for some reason the OS is unusable after the variable has been changed from the unset state.

Also note that the setting may or may not work under certain circumstances as it depends on the OS and how m$ handles the HVCI stuff.

 

Tomorrow i will look into the apps/store update issue. If i remember if any app is removed via the app tab in the creator, mrp sets a policy to prevent app updates as well which stops the reinstall of them on next windows update.

App removal is done via powershell appx removal and not by dism or other ways. Reinstall should work of any app but it never guaranteed due to many other dependant stuff.

Im unsure why changing language has the errors as nothing in mrp alters anything with the language parts of the os.

 

As i have to try and make time to do a test install tomorrow i will see what i can do.

*Edit - 18 April 2022* See my next post...

 

Have adjusted MRP to no longer set the option 'DisableStoreAppUpdates' to 'Yes' when removing any App, however this may cause the OS to reinstall any removed Apps when the next CU is applied.

You can still set the 'Disable Store App Updates' option manually via the Creator to try and prevent this happening. It all depends on how m$ change the internal code of the OS to force App reinstalls etc...

All that has been done is to no longer auto set that option when any App is selected for removal.

Also note that the 'Disable Store App Updates' uses a 'Group Policy' edit.

As for the changing language error during normal OS use , i cannot find anything within MRP that touches the language sections of the OS. All MRP does is read the values and not alter/write anything to the Registry.

 

'Cloudcontent' area of the registry is also part of the MRP config tweak - 'prevent adverts' that adjusts that area to stop the adverts - so that may be another option to uncheck to test.

I have re-checked the code about languages and it is the same as the QT , it just reads the registry/WMI values and shows the results in the log(s).

 

Have uploaded latest test decompile to the special beta-testing area plus a test of the next Creator with the new options etc added.

Note it is VERY experimental and may crash your install/OS if you use the HVCI option as it is still in early testing, i have only tweaked one area of the registry and it hopefully not cause a BSOD etc.

It did not on my test PC when i manually changed the registry value, my os is W10 21H2 (Education), it didn't crash/BSOD, however sadly i have not had time to do any fresh/clean test installs yet.

In theory all should be ok.

Clevo brand is now selectable in the next Creator, just make sure you also get a copy of the OEM's.7z file too that i have uploaded to the beta area that has the new brand in, plus a few changes to the Sapphire brand to make that one more compliant with Win 7.

@JanCerny if you wish to test this decompile - make sure you uncheck the 'Prevent Store Apps Auto Updating' option - which i think you had already, when i looked at you config ini file.

 

Just did a quick read on the internet about that error regarding changing the OS language, it seems that changing languages uses the cloudcontent system to download files etc to make the change happen, but as the cloudcontent is prevented from working it causes that error.

As I mentioned uncheck the option about 'prevent adverts' in the Creator and test - or as @tcntad posted to remove/REM the lines regarding that in WinTel.cmd if you are using that file.

Hopefully that will allow changing languages.

M$ certainly like to integrate stuff into multiple/other files/settings so it is getting more and more difficult to tweak the OS as we wish without having it break something else.

 

Sadly i still cannot get the right Video RAM when above 4GiB via normal methods due to m$ not updating the kernel calls, even the much pushed PowerShell cannot get the result either, well not as i found yet...

 

It is the actual Kernel WMI coding in all current Windows OS's that cannot return the above 4GB Video RAM , 3rd party programs get around it by using c# etc and probably some fancy coding , but i not know how to program in those languages. I try to avoid using 3rd party programs as much as i can unless i have no choice.