After using the oembios changer, you might notice that the oembios files in the \windows\system32 directory are no longer protected by "windows file protection" (wfp). You can rename or delete oembios.bin, oembios.dat, and oembios.sig without any wfp interaction. If you run microsoft's mgadiag utility, you'll also notice that it has some wfp related errors too: File Scan Data--> File Mismatch: C:\WINDOWS\system32\oembios.bin[hr = 0x80070714] File Mismatch: C:\WINDOWS\system32\oembios.dat[hr = 0x80070714] File Mismatch: C:\WINDOWS\system32\oembios.sig[hr = 0x80070714] The oembios changer does copy the oembios.cat security catalog to the \windows\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} wfp directory. But for some reason, the "new" oembios files are treated as "foreign". This is because of a time stamp issue with the wfp system. To correct this issue type the following commands: cd \windows\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} rename TimeStamp oldTimeStamp cd \windows\system32\catroot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE} rename TimeStamp oldTimeStamp Now reboot the system and you'll have wfp protecting the new oembios files that you've installed and mgadiag won't give any more filescan errors either. WFP has now been effectively cracked for our needs. Do note that you cannot simply delete the \windows\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\TimeStamp file. You must first rename it, then reboot, let windows create a new TimeStamp file, and then you can delete the old timestamp file.
The section labelled "File Scan Data-->" in the mgadiag output definelty has windows file protection scan data in it. If the \windows\system32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} directory is renamed or deleted, look at all the errors that we get in mgadiag: File Scan Data--> File Mismatch: C:\WINDOWS\system32\winlogon.exe[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\licdll.dll[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\ntoskrnl.exe[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\ntdll.dll[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\kernel32.dll[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\crypt32.dll[5.131.2600.5512] File Mismatch: C:\WINDOWS\system32\advapi32.dll[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\setupapi.dll[5.1.2600.5512] File Mismatch: C:\WINDOWS\system32\oembios.bin[hr = 0x80070714] File Mismatch: C:\WINDOWS\system32\oembios.dat[hr = 0x80070714] File Mismatch: C:\WINDOWS\system32\oembios.sig[hr = 0x80070714] File Mismatch: C:\WINDOWS\system32\syssetup.dll[5.1.2600.5512]
I can't reproduce the errors. I have tried it a few different times. I was going to add the TimeStamp commands you used, but I cannot see why.. This changes the timestamp file... Code: @echo off REM Rename TimeStamp file in catroot set name=%SystemRoot%\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} set senme=%SystemRoot%\system32\catroot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE} REN %name%\TimeStamp oldTimeStamp REN %senme%\TimeStamp oldTimeStamp But.... 1. I cannot reproduce your errors, 2.. No TimeStamp file is recreated for catroot\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}..do we need it???
on a windows install that has been converted from vlk to oem, try renaming or deleting some of the oembios files in \windows\system32. if windows file protection does not copy new copies of the oembios files into \windows\system32 or display a popup window about unrecognized file versions, wfp is treating your newly installed oembios files as "foreign". having the oembios files "protected" by wfp is nice. if your harddrive gets bad blocks where the oembios files reside, windows will automatically pull a copy of the oembios files out of \windows\system32\dllcache and install them into \windows\system32\. microsoft always seems to be coming out with new versions of their windows genuine disadvantage program too. it's unknown whether they'll fail systems in the future because of a wfp timestamp error or not though.
I know how to get the data from the MGADiag tool, there were no errors on the systems I tried it on..
Changes are: added script to update timestamp to avoid said errors in the MGADiag. Updated the OEMBIOS.EXE to newest version.. Any questions or suggestions please post them....
all liknks time out at 99% any chance for a rapid share or other link i have tried them on 3 differnt computer runing vista and 7
I tried using the latest version of the OEMBIOS changer on a Dell XPS400 that I installed the OEM version of Windows Home Server. It did not activate. (I know the BIOS has a Dell SLP string.) I used the Dell OEMBIOS files from 911medic's link. I put them in the compressed folder and then followed the OEMBIOS changer dialog to change the files and then reboot. Am I missing something?
Probably the correct string..Dell System is what you need, not Dell Computer. You must be sure the string is correct. Any dell string at any address is not good enough, the server is specific...
The string is Dell System according to the SLIC toolkit. Here is the string: 000FE076 000FE076 - 000FE086 Dell System I noticed there is another possible Dell System string listed on the last tab of the SLIC toolkit; could it be that this one is in the wrong location? If so, is there anything I can do about it such as the Windows 7 loader type programs?
OEMBIOS came back with: Windows XP OEMBIOS Test v1.1/269/106 (C) 2007-2010 severach @ msfn forums F: Dell System OEMBIOS.CAT CRC=63875D1F F: Dell System OEMBIOS.CAT CRC=B6F0EEFD These Royalty OEM install CD's should preactivate (SLP) on your system. Lines starting with E: are not reliably detected when running under Windows Press Enter! I'm not sure how to interpret that based on what you've indicated. Thanks for your help so far, I really appreciate it.