Adding back the W11 Taskbar Size option - if the win 11 OS does not allow the use of the setting it will just ignore it , but a later CU may re-enable it? It should work on the latest w11 'DEV' build {22616} again... Lets see if m$ remove it again later Testing continues.... Bit of a delay as been a busy week and weekend so it will be next week when MRP 145 is ready, sorry but i not want to release a version that not fit for purpose.
Any logs present at the root of the system drive?, if none then mrp never ran as for some reason oobe.cmd was ignored. If the input key screen appeared in oobe it indicates that there may not be a valid slic present in the bios or as mentioned above oobe.cmd was not run for some reason. I am guessing that the os installed otherwise, if branding for dell happened then mrp picked up dell via the dmi. If no branding or another brand used that would indicate it was not a dell motherboard and mrp used the dmi of the board. In xp days dell was a 'special' brand because the oem info that the oembios files used was in a different bios area. With vista and above that changed. Was the iso a dell made one as oem's can modify how the os is installed that could ignore oobe.cmd etc to run their own method.
the computer is using MSI motherboard and Intel CPU, which both bought by myself, NOT from Dell. yes, the install media was modified to add drivers of USB3, SATA which are common in present Windows 7 boot.wim and install.wim
These are about *.log/txt 200 files today. which log file will be useful? I can review and PM you a copy if needed. Thanks,
Usually there is just one or two logs in the root of the boot drive, one will be called project.log or mrp_xxx_project. There may be earlyrun log one too. The os should of had the msi theme as that info would of been picked up from dmi/bios. As not at home yet for a couple of hours i am unable to access my main pc. Mrp will only have a max of 3 log files and are always in the boot drive's root area by default unless the option to move them is used which in this case no options config ini file was used. If no logs that have any reference to mrp within indicates mrp was not run as oobe.cmd was ignored by the os setup for some reason.
Decompile.exe is missing , without that MRP will never run as that contains the actual project. Sometimes using a unattended xml file can skip some parts of oobe, but in this case it is clear the main Decompile exe is not present, well not in the picture.
Decompile.exe can be nabbed by Defender or any A/V as it thinks it is a threat, a false positive as nothing in it is malware, just the compilation system gets flagged.
yes, Decompile.exe is the main project file. If you had copied the $OEM$ folder from the MRP archive it would of contained oobe.cmd, Decompile.exe and OEM's.7z files that is the minimum required for a branding + vista/7 activation. Just oobe.cmd and Decompile.exe for no branding but vista/7 activation. BUT the motherboard would require a valid SLIC in the bios or no OEM activation will happen.
The oobe.cmd is needed too as that calls the decompile.exe, you can add you own bits to the oobe.cmd after the decompile calling part within the script, when you look in oobe.cmd it all is shown where to add your edits
If all goes well then if MRP runs ok, your MSI system should be branded/themed as MSI. Activation will depend if you have a valid SLIC present in the bios. MRP does not contain any method other than a OEM method for activation. For 7 you can use a genuine product key, Daz's Loader or KMS if the Edition is covered. Other methods for activation are outside this project.
The SLIC in the bios does not have to be the same as the board name, so for example a MSI board you could have a Dell SLIC added as long as the SLIC is valid MRP will attempt to OEM activate it using a OEM SLP key + Certificate. Server's use this same method too OEMSLP key + Cert + SLIC.
Have added a paragraph to the 'How to use MRP' spoiler part of the first post which i hope fully explains things better [---> Simply place the extracted '$oem$' folder into the 'Sources' folder of your 'clean' ISO/USB then save the ISO. This contains, by default, the main files required for the Project to work, Oobe.cmd, Decompile.exe and OEM's.7z , however for no branding, just remove the OEM's.7z file, this then just uses MRP for OEM activation. If you have used the MRPConfigCreator to make a 'MRPConfig.ini' file for your selected user options, place this into the '$oem$\$$\Setup\Scripts' folder in your ISO/USB/Image next to the Decompile.exe, Oobe.cmd etc, MRP will then use the .ini file to process your requested options during the OS installation. You do not need to use the MRPConfigCreator or use the .ini file if you not wish to have any of the selectable MRP tweaks and/or you prefer to do your own customizations. <---] I have not updated the first post that much from when i took over the Project in 2016 and most of the text is original and untouched.
update the Ver144 was unzipped on Win10, its defender removed Decompile.exe when unzipping. hence I changed to a Win7 computer to unzip the file. have obtained Decompile.exe. I tried the USB drive with three files: Decompile.exe, OOBE.cmd and OEM's.7z. after re-boot, asked computer name, then it still requests Windows key (25-letter) I have two OEM keys ready, one OEM Pro, another OEM home. which one I should apply to? or I can skip this step (then must activate in three days)?