An update from previous post Spoiler Something has definitly changed but what. I'll keep trying myself. I'd love to keep using MRP and the way I install OS the same way as "always" Edit: It doesnt work an original untouched wim either Edit2: Works with untouched ISO, putting the $OEM$ folder in sources] Edit 3: As long as OEM's.7zip isnt in the scripts folder, it works fine. I cannot use a customtheme option
Weird as the oem's.7z is required if you are using branding/customtheme option... A log report would hopefully shine some light on the problem as there are tests done on the oem's, (if present), to make sure the structure is correct and no corruptions. I am suspecting that something is upsetting the 'extract-to' pointer... Possibly it is being pointed to the wrong drive letter? -- Or the dreaded space in a path which can give some really odd results, although i have done my best to eliminate those type of problems. Have now tweaked the extraction routine slightly which hopefully will fix that to always make sure it is the system drive that the OS is being installed onto, as it may not always be C: , have done a install with the test 109.1.IT1 MRP and it does all work as usual. I needed to do a test anyway as added a new 'SSD Tweaks' option which i wanted to make sure was working - which it does, (plus it can be reverted later if required). More details later as it still being tested thoroughly before being added mainstream.
I'll get back to you as soon as I can with a log/debug. Of course I vad oems.7z copied when applying customtheme.
I never thougt about it but MDT makes 3 partitions, boot, recovery and Windows. I changed it to have one drive/partition. This did not work. THis time I only kept decompile.exe and OOBE.cmd
As i have never used MDT i am unaware of how it creates or does stuff etc. From what you mentioned it seems it possibly moves the OS drive letter about at some stage. This would present a problem, but with the little change in the extraction routine i done today, it now should be whatever the actual OS's drive letter is, so if it moved it to say x: then MRP should use x: as the 'system drive' letter. As the majority of the project works ok it seems that it is in a tiny area of code where the oem's are extracted and then used during the processing to insert the brand theme.
So Server 2019 all went ok with branding - the log shows nothing amiss. The above log will show that OEM's.7z is missing and MRP will just use the default windows theme. When you put the OEM's.7z file with decompile etc i gather everything else works but no branding, the log should indicate that either there is a structure fault or the file is not present (which also means the 7z was not extracted in the right place or not at all) - sadly to check for each error would take ages to process so i just check if the 7z was present, or nothing was extracted correctly.
Yes if I remember correctly it was deployed the same but I can do another test when I come home. They have the same number/version right? I understand this is a hassle, I bet there's some changes in how OEM partners do it too between the versions. How does Install.cmd work?
yes all versions same. Only this new test 109.1.it1 is slightly different in the extraction routine for the OEM's part. Install.cmd is complicated to fully explain, but basically it does a lot of checks what OS, Edition is installed, checks options used (if any), sets all the options during the processing. DMI is processed to see what brand is to be used (or if customtheme set to a valid brand) and then copies over the required theme files to windows\system32\oobe\info folder etc. The project is far more advanced than what was before, quite a lot is error checking and adapting 'on the fly' to compensate such as if a DMI conflict arises to then check something else to see which to use, its not perfect but it does a good job so far in working out which brand to use and failing that either the SLIC (or MSDM) brand name is used then if those all fail to just use the default windows theme for the OS.
Once again, Its a remarkable project, it has grown alot since previous developer. not to forget them at all but remember.
Have updated the oem's detection routine... Now you will see one of the following lines in the Project.log: The extracted OEM's folder structure appears correct. ==> As it says. The OEM's archive was not detected. Windows default theme will be used. ==> This is if the oem's.7z archive file is missing from the 'Scripts' folder, or not used. The extracted OEM's folder was not detected. Windows default theme will be used. ==> Something went wrong in extraction, could be a drive letter change during deployment or other failure. The OEM's.7z file or extracted OEM's folder was not detected. Windows default theme will be used. ==> either is missing in action!
Who cares . OEM_SLP is important as it can be used with the Loader . Interesting is OEM_DM for EnterpriseS 17763.
Servers are a beast unto themselves! As Server 2019 is based on W10's 1809 kernel you would think any problems with non Server 1809 would be the same, but it goes to show that there are subtle differences in what is 'bolted' on around the kernel. Considering Themes are not normally associated with them and are generally not used by default shows the different OS's coding structure. Plus it seems there may be MSDM's available for S2019, but due to limitations, MRP will not be able to process them like non Server Editions, I have added information into the Server 'Read Me' notes for the next MRP to explain why. The project log will show new info too if S2019 is installed. Basically because Servers not usually have .Net installed by default this causes the MSDM routine to fail as it relies on .Net to obtain the MSDM key etc, so to avoid a lot of extra code to be added, the routine is simply ignored. Maybe in the future i am able to write a non .Net/C# reliant method which will make MRP non dependant on those external libraries, we will see.