Interesting results re Server 2016.... On the QT using a VM i setup with the SLIC 2.5 Dell bios file i was getting SLIC Table Invalid or Corrupt, when i checked with the Slictoolkit the RSDT entry had a red != mark so it was corrupted So i then tested with my trusty Dell 2.4 slic and all was ok... I am at moment installing latest test MRP 118 (TC10) to see if the 2.4Dell slic (that i know works) actually detects ok. But this VMware is so slow as im still using v12 I cheated to do the SLIC tests in the QT by using a W10 VM i had setup ages ago - can tell it was ages as the QT was v49.1 that was on the desktop At least now with a fresh S2016 install i can do some script tests.... More details later as they appear... Edit: Taken just under an hour on this VM install to get to the first reboot after copying the files!!!
Well after 7 hrs on this i have finally decided to give up on Server activation. If MRP activates it then all is good, if not then i am NOT going to fix it as i have had enough pissing about with Servers now. The VM way is so damn slow and i not have a real PC i can flash the bios with Dell 2.5 SLIC, so for the time being Server activation is on hold until i decide to try again. Plus I want to test other things with MRP or it will never get it released before the end of the month! I also have to test win7 to see if all this messing about has affected that too, if it has i will just revert back to before i started this Server code change. What might be the problem now is that m$ have altered something and the SLIC is just ignored somehow under OOBE stage when Server is detected? The SLIC check is 100% identical to the code in the QT so it is not the code... Either way enough is enough for now.
If query tool works and oobe doesn't then somethings up with M$ obviously. Put on back burner for now until more testing can be done at a later date. Don't stress your self out. Just some friendly advice.
This is what is puzzling me the code is exactly the same routine! It works manually once installed, just not during oobe - yet win Vista/7 does, it seems to be S2016 that is being the usual awkward beast. I know OOBE stage has some quirky things going on but i thought only the SLIC may be hidden on HP/Acer/Lenovo when a win 10 kernel (inc Server 2016+) Have just added some debug code that lists the SLICVersion detected by 'Generic_4.exe /SV' and what WMIC returns for OA2xBiosMarkerStatus ... Sadly i not give up that easy - not quite yet anyway as i am determined to get to the bottom of this bugger once and for all
I have cheated a bit, (which might come back to bite me), I have a PC in for repair and have backed up its original BIOS and modified the latest BIOS with SLIC Dell 2.4 (my 2.5 seems to be corrupted?) So it a bit quicker now to install S2016 - but no SSD so it takes about 20 mins to install - unlike the VM 1.5hrs and a bit EACH test install - sod that!
You and M$ need marriage counseling. lmao! I had to make a pun on that statement. I could not resist. lol
First set of results: Un-Listed Yet OA2xBiosMarkerStatus = 1 which is SLIC marker OK and Present.... I am wondering if Generic_4 (which is for w8.x/10) kernels (using .NET v3.5/v4.x) is not active properly as i checked and there is no .net v3.5 available -- v4.x is though.... So more debug code to use generic_2 (uses .Net v2.0 which available on S2016) - if the generic_4 returns unlisted or nothing at all...
Read and replied Let me see if this new modification works as if it does then it is not MRP or my coding (which is a first lol), but the lack of correct .net working... Which if true i might have to re-write a few other bits but then until Server's use MSDM i can relax a while.
Well can confirm that Server 2016+ has some weird way in that it returns 'Un-Listed' during oobe stage for the SLIC table data, no matter if generic_2 or generic_4 is used so it not a .net issue as i thought, but something else m$ has done. Will have a think as i may have a solution for Servers...... it should not affect normal Vista/7 SLIC activation's only Server installations....
Is this a new refresh of server 2016? Has anyone ever got server 2016 to activate with included MRP? I am curious...
My test results via MRP at OOBE stage (before Admin password create screen) Code: Txt Location : ["C:\Windows\Setup\SLICv.txt"] SlicVersion : [Un-Listed] SlicVersionXX : [Un-Listed] Generic Vers : [4] Re-test using .net 2.x Generic... SlicVersion : [Un-Listed] SlicVersionXX : [Un-Listed] Generic Vers : [2] SlicVersion : [Un-Listed] SlicVersionXX : [Un-Listed] OA2Table : [1] SlicVersion : [Un-Listed] SlicVersionXX : [Un-Listed] OA2Table : [1] Just returns Un-Listed as the variable is null'ed so it has to be created by the Generic's ....
The odd thing is that OA2Table = 1 which is slic OK and present via WMIC but there is no way that WMIC returns the damn slic version, typical m$ half doing the coding, gez wouldn't take much to have a GET option as GET SlicVersion /value or something but no that is too easy. Instead you have to mess about poking into the Kernel DLL's etc Well as it IS detected properly at the desktop side (after oobe stage) i may have a solution that might just work for Server's only....
Looks like its being blocked. Again I wonder is this a refresh of server 2016? Has anyone tried an older version of server 2016? Need to figure out what if anything is interfering with the included tools.
en_windows_server_2016_x64_dvd_9327751.iso is the iso i am using. the hash will not be genuine as i have added the $oem$ folder into it but the last 9327751 is the same as i not renamed it. Code: Windows Server 2016 (x64) - DVD (English) File Name en_windows_server_2016_x64_dvd_9327751.iso File Size 5391 MBytes SHA1 Hash 7E33DF150CB4D1FE3503E23433A1867DDD79A6EE File Type DVD Architecture x64 Language English Release Date 2016-10-12 08:57:22 Product ID 2133 File ID 70321
If that is the case then its a matter of time before that blocking is done on other servers even possibly home user versions as well. Have you tried changing the name of the generic exe files to see if it then runs in oobe? Then again M$ might be trying to block access during oobe only since you say it works after on desktop. To me it looks like it cannot reach the kernel during oobe thus resulting in null.