ok at least on the right track and no major problems, with latest w10 it seems m$ have either locked some registry parts or they are ignored, maybe the GUID has changed slightly... I am still looking at the ShellBags areas and trying to work out which causes that super all dark text problem.
'ThisPC' is possibly in another area, will have to 'sniff' the entire registry for changes when adjusting that particular view... Will also have to do the value checks for all OS's -- hmm this may take a while when i can get time
Take your time, shoudnt be prio I changed to detailed view and ran the script again, it reverted back to normal for some reason but not the ithers
If the 'ThisPC' view revert back to default then it may be the way the script has to delete the registry section blocks first before creating the changes... I will see which ShellBags bit is for the 'This PC' section and re-add the 'details' view bits in so all windows look the the same view... Even if that is the only one that is 'special' in that it always resets to 'Icon' view (i think that the default) then it not a major hurdle. Just happy to see that it works ok for the majority of the explorer views and not cause some weird effects. I will see if it can be made better, before i add it into the next MRP's new option list for now, as i can, once 'perfected' it then make a multi-choice one for Icon, Large/small Icons, Details, Content, etc but that will be a while yet, need to make sure it will work in 7 to w10 (all builds). Only tested on w10, although it should work on 7 and 8.1 - will have a play when time permits as i know some Vid/GUID's are different for each OS and some are re-used as something else, probably why the bypassed section of the script causes that color confusion on 1803/1809+ with dark mode set. Thanks for testing. It has certainly changed from my personal tweak as i only had the General template changed for my needs, the new script allows changes for the Libraries and other windows too, i did say it could get a bit complicated, but i like a challenge.
Ok So I ran the script again, this time it did not reset This PC to default. I'll deploy W10 again tho Edit: As deployin over LAN it doesnt appear to change This PC even if I modify script or not.. I'll move stuff around in deployment to see if it helps
Quick question. I can see in the MRP_Project log: "The Model name was not defined within BIOS or User specified." Can we make MRP use "CS Base Product" in Motherboard Information section and apply that as model?
I see from your log that your SetupComplete.cmd had a RD <scripts> line or a shutdown /r as the rest of MRP was aborted because it was deleted automatically via one of those commands. Majority of the MRP options would of been set, only those in the '===[ Enabled Options ]===' part would not of, as those are actioned upon the first reboot just before the user name entry etc oobe stage or in MRP terms the Addon Manager stage.
Regarding the Model Name, that part has not changed sine i took over i think, it is checked in two places, one in the BIOS itself - if the OEM Manufacturer has added that, or via a section in the registry that gets its info from the DMI area. If those are not defined or a user entered one then that Model part is left undefined. I did toy with the idea for checking the CS Product area but as that can be 'To Be Set By OEM...' or 'Default String' or some weird characters i decided to leave it as it is and add the User entered one. To tweak it again would be a bit of extra coding, i could have a 'special' trigger word that would tell MRP to use the CS Product info... The trigger word could be '#CSP#' which i doubt any OEM maker would use there?
i have used many scripts & Unattended software setups via setupcomplete.cmd inside your $OEM$ directory & created $1 $2 directories for installation of Unattended software setups . Installation rebooted many times i think almost 8+ times but in last installed OS . Time Taken to install is more then 20 minutes but if i dont use any $OEM$ it will install within 5-6 minutes.
Anything added into the $OEM$ be it the MRP or any Office package, other software, drivers etc will take extra time. M$ have made a few undocumented changes to the $OEM$ system and i think they are making the things we took for granted since XP days slowly harder, as with insider builds, the OEM branding may not always take on the first run, (Core/Home for instance), so a 2nd reboot is required. Like with windows 8.1 with the thinner boarders option that needs 2 reboots to take. MRP has a lot of error checking to make sure it functions as best as possible even if it has crashed, so that it will clean up the OS of any ruminants of the project etc.
At work and on my phone so spelling may not be perfect as i had to turn off that predictive text crap and writing long messages is a pain in the proverbial!
I think thoose Unattended Silent setups have made machine rebooted that many times or else you are absolutely correct it reboots 2 times to complete installation pre & post OOBE.
Just realized i have been working on MRP for four years -- as in yesterday 16th October [2016] (GMT) !! Sorry no fanfare or 'special' release this time The project has come a long way since that time. i still have the original data zip i got from @The_Guardian, never thought i would still be working on the code base 4 yrs on! Many thanks to all that have contributed, be it reports, suggestions, beta testing, OEM branding, or just using the project, without you all i probably would of gave up long before now, even a serious illness did not stop me, that has slowed me down a lot, but i do read the reports, suggestions etc as it helps me pinpoint areas that could do with a nip and tuck to tweak things. As @Enthousiast can agree with me , i have made quite a few 'screw' ups along the way and it has at times took me ages to work out a fix before the baseline release...
do i have the rights to decompile your decompile.exe . i want to see the contents plus coding structure . i promise for my personal use not any professional cause.