Script not running on Windows 7 SP1. Here is the log file Multi-OEM/Retail Project Version : CY20M01D22-R133.F1.BR - BaseLine Refresh [MDL Forum ONLY] DeCompile has detected a VMware Virtual Machine. The extracted OEM's folder structure appears correct. Installed DotNet Framework{s} : v1.1.4322, v2.0.50727, v3.5, v4.0.30319, v4.8.x or later {Rev:528049} Installed Powershell Versions : 1.0, 2.0 Using 'MRPConfig.ini' File : Yes - Checking for selected options. Config Creator Version Used : 38.0 MRP Options Pre-Check : Completed OK MRPConfig.ini, MRPInstall.cmd & oobe.cmd are still there in \Windows\Setup\Scripts folder. After first logon. oem branding is not applied neither any mrpconfig settings.
I had been informed of the problem and sorting the crash out. Due to bad weather and being unable to get home from work for a couple of days, i have been unable to work on the project until this morning, I will be releasing a updated project shortly, thanks for reporting. Windows 7 seems to be the only OS affected when a .ini is used... I will temp pull links in 2nd post until i can get the project fixed, i know where the issue is so will be a fairly quick fix.
OK 3rd time lucky MRP v133.F2 - Baseline Refresh as been uploaded, 2nd post download link, password and hashes updated. Spoiler: MRP v133.F2 BR + Fixed another issue when a OS lower than 10 was installed and a .ini used, due to a error in the options checking routine some items designed for Windows 10 only were silently run and as those 'Apps' do not exist in the OS and the fact that Powershell did not not like the commands, it totally crashed the branding/tweak setting script! + Added extra checks so that now any OS specific options are now forcefully disabled if the installed OS they are for is not detected. More items will be added to the list{s} as more options are added. Hopefully this finally fixes v133.x !
I say was a 'easy' fix, it was once the issue was found, with over 14,000 lines of code in that one script alone it took a while. For some reason when i fixed the " (quote) issue i somehow upset some of the variable checks which made the fatal crash, that script has always been very sensitive to any changes and i got burnt by that mistake again!
Sometimes it can take a while as if you are using a lot of option it can appear 'hung', also if you have added your own setupcomplete/usertweaks etc scripts they could delay things too such as installing any updates or office...
Occurring from time to time here too (not lately), independent of using mrp or not, it should run thru eventually.
The time taken from start install to desktop is variable, CPU/RAM/Drive type, the amount of options used, any alterations to the ISO/Install.wim, integration of any updates, or integration of a office package etc. If you are using any setupcomplete.cmd/firstlogon.cmd (wintel or Usertweaks) they all add time to complete... As mentioned regardless of using MRP there are times when Windows is just Windows and decides it not want to play nice.
I know at one time a faulty SLIC or MSDM table could trip up MRP, but that been fixed well over a year ago maybe close to two now.
FYI: About my lock screen issue, I tracked it down to 20H2. I tried Server 2019 unmodified over network (worked) and 20H2 unmodified ISO (didnt work) Last i tried 1909 unmodified ISO and it worked.
There seems to be a few 'quirks' in 20H2, probably something within that enablement package that triggers other changes that is dormant...
open the oem's.7z archive, locate the brand folder, open that, delete wallpaper.jpg or rename it wallpaper#.jpg {# being any unused number like 3,4,5 etc} rename wallpaper1.jpg as wallpaper.jpg. Close the archive.
I Think some of them are on that 'sherbet moon-dust' When you think about it , they certainly do the stupidest of things with wacky ideas and total cock ups when attempting to make said wacky ideas work