Hello my friend ! Did you have a alternative if the OOBE.cmd can't be run because the system had a OEM-DM key installed ? Thanks Can be install in Audit Mode ?
If the PC has a OEM-DM you can just use the ei.cfg file to show, (or pre-select), the list of Editions available to install, OR the 'PID.txt' with the generic key for the single Edition you wish to install either one of the two mentioned files used should be placed in the Sources folder where Window's Setup.exe will see it and ignore the internal OEM-DM and run the oobe.cmd as normal. Otherwise Setup.exe will see the internal key and install that Edition if it is present in the image. They are the only two ways i know of that not involve removing any unwanted Editions from the WIM/ESD file. MRP cannot be installed as such during Audit Mode, it used to 'pause' to allow any audit functions the user wanted to perform, but this 'pausing' caused a few headaches and so the pause feature of MRP was removed. MRP will attempt to run all the way through if Audit Mode is used. It is more safer to do all your audit mode stuff on your Edition's image(s) first then commit+save it, once all your actions been done then use MRP as normal via the $oem$ in the 'Sources' folder method. Sample ei.cfg and PID.txt files can be found within the MRP archive under the Optional folder.
What I do after I install what I want in audit mode I put mrp files from script folder in the scripts folder of the system then sysprep. After sysprep the mrp runs normally. That's my method.
Sysprep and myself are not the best of friends, therefore i avoid that side of testing because of my inexperience in that field. I have lost count of the amount of times i have ended up with a corrupt/non serviceable image using Sysprep, or even DISM to make a up-to-date ISO with latest drivers etc - so i stick to the 'safe' methods i know works which not involve those processes. -------------------------------------------------------- MRP update: 1. The 'Disable Internet Probing' option works OK, on win 7 the yellow ' ! ' may be present for up to 35 seconds give or take on a boot up/reset cycle , but you should have internet access, providing your WiFi or LAN connections are OK, then it should clear the 'limited' status, nothing i can do about that because if i adjust the timeouts it can cause the OS to lock out the connection totally. The timeout can/will vary depending on the speed of the PC and/or internet connection. This option works for both LAN and WiFi connections. 2. Adjusted other code in the Telemetry option, it has more tweaks added to update the routine. Advisory Note: It is not wise to use this option with Insider builds if you are going to be signed in to the program and your experiences will vary on what effect this could have as some preview features/functions may be prevented from working. More updates later as they occur
Something i have been working on for the Creator.... Thanks to @The_Guardian for nudging me to have a go at making this mode. Click for large picture. It is experimental and there is still a bit of work to do to fully get the mode to work, but for now it does the job Also a slight make over to the program layout - a new W10 tab (2) to allow for expansion of options. When loading the Creator you will be asked if you wish to use the Dark Mode and your choice will be saved in the .ini file. If you select 'Yes' then you will not be asked when re-loading/editing the .ini file. If 'No' then you will be asked each time. In the .ini file this mode is set via :CreatorDarkMode= which is below the Version line, the program's default is 'No' which will cause the Creator to ask your choice.
Server's are very fussy beasts! But it should of worked ok as there is the SLP key and XMS Cert for Dell 2.x in the MRP As no MSDM key is present in the bios it should of ignored that check (windows setup.exe i mean) and Oobe.cmd etc should of been ran. Vmware71 is that a version below v12.x of VMware? as if i remember older Vmware workstation/player did not work correctly. v14 onward there was fixes for server 2016+ i think.
Licensing Channel {RCode} : OEM_SLP {0xC004F063} License Status Reason : The system is missing a required OEM licence component, {ACPI Table/Key/Certificate etc}. It seems the modified OEM bios your using has some problem?? .... Hence MRP was not run because the Windows Setup.exe detected some problem.
@Enthousiast ran a test server (standard) 2016 install (minus any slic table or modified VM bios) and MRP ran through all ok - apart from any activation So not sure what is going on, with your system/vm that is causing oobe.cmd not to run etc.
The test system is running ESXi 6.0 QT result shown above is with efi BIOS modified using the VMware EFI Mod Kit [Updated 09-2019] from this forum. I also tried bios440 BIOS modified with phoenixtool273 - same result. What does the OEM_SLP {0xC004F063} error mean? I guessed, that this is related to the missing DELL.xrm-ms cert file, which is not copied to the system because oobe.cmd is not executed?
Ah ok, i not have ESXi we only test with Vmware Workstation/player. But as long as it is emulating the 'bios' as normal i cannot see why it not working as to the windows setup the emulated pc acts like a normal one (with the limitations of emulation). The error code means that either the ACPI (SLIC table data), XRM or key is not present, basically one of the main ingredients to achieve activation via the SLIC method is missing. As MRP not ran it was unable to copy the XRM cert over and in the case of the QT report that error meant the Cert was missing as you have the SLIC 2.5 and you entered the Key. I am trying to work out what the problem is why oobe.cmd was not run and so MRP was ignored too. In our tests so far, all works, (although as we not have the SLIC v2.5 vm bios at moment - only v2.4 Dell), to check SLIC activation, but regardless of that on our installs oobe.cmd was called by the Server's Windows Setup.exe and MRP was processed as usual. It seems something is interfering or confusing the Windows Setup into thinking that a MSDM table is present and just ignoring the oobe.cmd/setupcomplete.cmd stages...
For Windows 8.x/10/Servers - we use the following ei.cfg contents, and fingers crossed it has never failed, we always get the Edition selection and MSDM bypass so oobe.cmd etc works. Code: [Channel] _Default [VL] 0
What is strange is that even on my VMware W/Station v12 that i have, Server 2016 does run oobe.cmd + MRP although some elements not work properly due to lack of the VMWare fixes that was added in v14 onward. I assume you are installing the 'Desktop Experience' GUI version as the non 'Desktop Experience' version may not be calling oobe.cmd for some odd reason. I remember ages ago that i tried the non 'Desktop Experience' version and MRP failed to run properly because the OS had no internal enabled GUI elements so the branding side failed, however the activation part was ok. So i am unsure what the actual cause is. As mentioned before, Server's are very fussy beasts and a life of their own.