i also prefer to use the ready made $OEM$ folder by@abbodi1406 Dubioza Kolektiv and Enthousiast I would also use the $OEM$ folder by@abbodi1406. I've been doing it that way for a very long time. I use KMS_VL_ALL-41r, (not the KMS VL ALL AIO-41r) it contains the $OEM$ folder, if you look in the Scripts folder you will find the bin folder and a setupcomplete.cmd Change the setupcomplete.cmd to KMS_VL_ALL.cmd. I then have setupcomplete.cmd and the KMS_VL_ALL.cmd in the Scripts folder. For the KMS_VL_ALL.cmd, I have this in my Setupcomplete.cmd. @echo off call "%WinDir%\Setup\Scripts\KMS_VL_ALL.cmd" /s /a This always works.
I want to use an MRP file and abbodi1406 $OEM$ folder together. As I showed in the picture. Can it all go in one $OEM$ folder?
Query Tool v115.0 is hopefully being released tomorrow or at very latest Monday 24th May in the morning {GMT}.- ------- MRP News A glitch when installing Vista/Svr2008 has been reported in that the project could just exit without error, leaving just a top 'header' part of the log file and nothing else in the project being run. Found the problem and now when a 6.0 Kernel is detected it will skip past that section. Basically CHCP on Vista/Svr2008 acts different on that kernel and so just causes any script to quit without any errors, that alone took a bit of investigation. The slight downside is on non Latin based Language OS's being installed some options that use your own wording such as Drive Name, Model Name etc may show incorrect characters because UNICODE mode could not be used. It may also affect some MRP C/Text Menu translations although that should not happen as MRP uses the OS's internal look up tables where possible and defaulting to en-US if nothing available. NOTE: I will not be supporting 6.0 kernel OS's any more as time has moved on, so if there is another glitch found it will be a case of if i can spare the time to fix it and is it worth it. Because this was a potential showstopper for those older v6.0 OS's i decided to spend a bit of time to see where the crash occurred and get it fixed. Also if .NET v3.5 is not installed then the SLIC checks will be skipped and just report that none is present as the routine to detect it had to be skipped, so no activation will occur even if the SLIC is actually present and correct. Also any SLP Product Key and Certificate will not be processed via MRP. If possible integrate .Net v3.5 into the WIM prior to using MRP as this will then allow the activation subroutine to operate and attempt activation if all criteria is met. No other changes have been made and the current v137.0 will be perfectly OK for win 7 through to 10. I will upload the MRP v137.1 refresh all being well on Monday because i still have a few little bits to sort out first, as i get time this weekend. Times/Dates shown are subject to changes.
Query Tool v115.0 has been uploaded, 2nd post download link, password and hashes have been updated. Spoiler: QT v115.0 Summary + Tweaked a few little internal code areas. + Added DotNet.exe (.NET CORE v5 runtime) version info, if detected. + Added experimental checking for SLIC v2.6 for Server 202x etc. This is mainly a interim release which addresses some cosmetic issues. ** ADDITION ** MRP v137.1 will be delayed a bit due to changing the .Net requirement to v2.x to find the SLIC etc, for some reason now the Activation Sub-Routine is created and never called... It finds the slic version etc ok, so it not the generic2.exe failing, it seems that the change of the .Net requirement has caused a issue later on in the code... Even branding fails as for 6.0 Kernels the desktop wallpaper has to be inserted into a system DLL file, which is a bit of a silly way as even XP/2000 never had to have that done. No wonder Vista was not liked on so many aspects. I may have to re-write the section slightly and that Vista's/6.0 Kernel activation is done later in the MRP add-on manager instead... Windows 7 and Server 2008-R2+ that use SLIC activations are not affected. If i cannot find a way to fix it then i may just remove Vista/6.0 activation altogether as it being a total pain now and more things i change affects other OS's, so i have to think is it worth it to spend time on such a EOL kernel?? Easier to just use Daz's Loader to activate!
I recently noticed or found out that Windows 8 (9200) do not support SoftwareLicensingProduct parameters ProductKeyChannel, DiscoveredKeyManagementServiceMachineIpAddress something to consider
Got to love msft, nothing straight forward - always something that challenges us to find alternative ways. Will adjust the MRP code and the next QT's next release to use the older, (slightly slower), KMS detection method to obtain KMS information for Windows 8.0, that should prevent any crashes or false results. Win 8.1/10 OS's will use the newer KMS detection method instead.
It is a case that 6.0 Kernels have a weird way to activate and i think for some odd reason that during the early oobe stages, (unlike 7+), that the activation stuff may not work or be available. To be honest I'm fed up looking at Vista now and the main thing is that other parts work again such as branding including the critical inserting of the picture image into a system DLL, mess that up and the OS is shafted.
@Enthousiast These silent options were added firstly in v134 to provide compatibility with POWIS custom RunOnceEx lanching