Bezalel

For about 3 months I didn't go into a certain CompUSA because I was almost caught collecting oembios files and factory keys from floor models. Its easier to get the files from a laptop because you can naturally rest you hand over your USB drive. BTW You only need one set of files to test the CD.

Although my method is currently working SFC is aware that the files have been changed because oembios.cat was parsed before the files were changed. If the end user ever runs SFC manually they will be prompted for the oembios files that match the origional oembios.ca_ that was left on the CD. My two question now are: When SFC parses the oembios.cat file where does it store the thumbprints of the remaining oembios files? (I am able to delete the oembios.cat file, it is not protected but SFC still knows that the files aren't origional) Can I run cscript.exe from DetachedProgram? (To replace oembios.cat before it is parsed.) Presetup.cmd looks interesting but I'm trying to keep away from hacked binariess

Thats understandable, I myself am figuring out this process so it keeps changing You only need the files created by CollectFiles.rar you don't need the files contained in ColletFiles.rar (The files in CollectFiles.rar are pretty sloppy and leave behind an enviroment variable but they do work.) Here is listing of the contents of my $OEM$ directory: 44656C6C20436F6D707574657220436F72702E.BIN 44656C6C20436F6D707574657220436F72702E.CAT 44656C6C20436F6D707574657220436F72702E.DAT 44656C6C20436F6D707574657220436F72702E.SIG 44656C6C20436F6D707574657220436F72706F726174696F6E.BIN 44656C6C20436F6D707574657220436F72706F726174696F6E.CAT 44656C6C20436F6D707574657220436F72706F726174696F6E.DAT 44656C6C20436F6D707574657220436F72706F726174696F6E.SIG 4865776C6574742D5061636B617264.BIN 4865776C6574742D5061636B617264.CAT 4865776C6574742D5061636B617264.DAT 4865776C6574742D5061636B617264.SIG 544F5348494241.BIN 544F5348494241.CAT 544F5348494241.DAT 544F5348494241.SIG cmdlines.txt CreateBatFile.vbs RestoreOEMFiles.bat RestoreOEMFiles.tmp smbios2.exe

I have a set of files that worked on a Dell, HP, and Toshiba PC. I made the following changes to the CD: I deleted OEMBIOS.BI_ OEMBIOS.DA_, OEMBIOS.SI_ from the CD (make sure you leave OEMBIOS.CA_) I removed all lines referancing any of the OEMBIOS files (including OEMBIOS.CAT) from txtsetup.sif and dosnet.inf. I created a winnt.sif file that included a MS Generic key http://www.microsoft.com/technet/prodtechn...y/oempreac.mspx (Home users should use a Factory Key) I copied the files from activation.rar to the $OEM$ directory along with the files created using CollectFiles.rar

Take a look at http://www.msfn.org/board/index.php?showtopic=63258 I wrote these scripts specificly for your situation. BTW The COA-Key is useless unless you want to call MS every time you install. You need to extract IBM's Factory-Key.

Unfortunately the problems you are having are completely unrelated to the topic of this thread.

There probably already is a winnt.sif on the CD. Take the key supplied (on the CD) and use it in your winnt.sif.

The OEMBIOS files are MS copyrighted files, such a project would probably be considured warez.

If you use the key from the Registry (or the key in your Dell CD) you will not have to activate it at all. If you use the key from the sticker you will have to activate by phone. The CD Key is not tied to any manufacturer, the OEMBIOS files are. You are focusing too much on the key when you should be focusing on the OEMBIOS files. The key isn't the problem, it's just the symptom. Here is a timeline of what happens on startup when you use your Dell CD on a Dell and a Non-Dell. Dell: WPA creates a hardware inventory and saves it as WPA.DBL Using the OEMBIOS files WPA checks that the PC is manufactured by Dell Verification passes - Have a nice day Non-Dell: (System Builder - Not yet activated) WPA creates a hardware inventory and saves it as WPA.DBL Using the OEMBIOS files WPA checks that the PC is manufactured by Dell and is using a factory key. Verification fails - proceed to next step WPA.DBL is compared to WPA.BAK to determine how much hadware has changed Verification fails (WPA.BAK doesn't exist) - proceed to next step User is prompted to activate User attempts to activate online Activation fails (factory keys can't activate) - User is informed that the key must be changed User enters key on sticker User attempts to activate online Activation is sucsessful - WPA.DBL is signed and copied as WPA.BAK - Have a nice day Non-Dell: (Royalty OEM - Not yet activated) WPA creates a hardware inventory and saves it as WPA.DBL Using the OEMBIOS files WPA checks that the PC is manufactured by Dell and is using a factory key. Verification fails - proceed to next step WPA.DBL is compared to WPA.BAK to determine how much hadware has changed Verification fails (WPA.BAK doesn't exist) - proceed to next step User is prompted to activate User attempts to activate online Activation fails (factory keys can't activate) - User is informed that the key must be changed User enters key on sticker User attempts to activate online Activation fails (Royalty OEM keys can't activate online) - User is informed that they must activate by phone User attempts to activate by phone Activation is sucsessful - WPA.DBL is signed and copied as WPA.BAK - Have a nice day Non-Dell: (already activated) WPA creates a hardware inventory and saves it as WPA.DBL Using the OEMBIOS files WPA checks that the PC is manufactured by Dell and is using a factory key. Verification fails - proceed to next step WPA.DBL is compared to WPA.BAK to determine how much hadware has changed Verification passes - Have a nice day There are more steps involved that I am aware of (and probably many more that I am not aware of) but these show a comparison between different types of systems

Maybe I should clarify my last post. SLP doesn't browse the DMI or SMBIOS tables for a specific entry, instead it searches for the sting within a specific range. The manufacturer may choose to search from 000E:4000 to 000F:FFFF (the entire BIOS) to allow for flexibility in BIOS design and allow them to place the string anywhere in their BIOS. They may also choose to use their name as the search string. WMI uses multiple sources for its data. I think the manufacturer and model originate from SMBIOS.

There is an issue with this method. If the user ever runs SFC manually they will be prompted for the Dell OEMBIOS files. I haven't figured out yet how Windows knows that the files were changed, the replacement files are digitally signed by MS and they are present in the dllcache.

%SYSTEMROOT%\SoftwareDistribution\DataStore\DataStore.edb

This is exactly what the post http://www.msfn.org/board/index.php?showtopic=63258 is about.

All installation of Windows XP should have the OEMBIOS files. On retail copys these can be deleted but if you delete them on a SLP Pre-Activated computer you will lose the Pre-Activation.

SLP Activation doesn't check the DMI tables, it searches through a specific memory address range looking for a particular string. The OEMs provide the address range and string to MS who encrypt them and provide the OEMs with an OEMBIOS file set.

Information on my multi-manufacturer CD can be found here http://www.msfn.org/board/index.php?showtopic=71016

If your freinds have PCs made by Royalty OEMs (The COA will have the OEM name instead of "OEM Product") you will not be able to activate them online. This change was implemented begining in Feb 2005. Instead of using your Dell CD why don't you make one CD per manufacturer. Take a look at http://www.msfn.org/board/index.php?showtopic=63258 for more details.

Sorry for this, maybe, stupid question - but to avoid misunderstanding:Do I get you right? As long as I have the oembios files and the corresponding product key from the registry I can use them to create a pre-activated installation CD of any version of WIN XP, including Home, MCE2005, TabletPC2005 and Pro? And what do you mean with I don't get this.Thought the product key of a pre-activated installation has to fit to the oembios files which on the other hand fits to a special manufacturer? MCE and TabletPC are based on Pro so they use the same OEMBIOS files. (I have used OEMBIOS files extracted from a Dell Pro with a Product key extracted from a HP MCE to create a Dell MCE CD set.) I'm not sure if the files can be interchanged between Home and Pro. The Product Key is tied to the edition of windows being installed. In my multi manufacturer CD (not finished yet), I do not change the product key for each manufacturer.

My suggestion would be to setup a WSUS server and configure each machine to check in every hour. Then install the updates until the server says the machine is up to date.

First recover the OS, then use the scripts in the first post to extract the Sony specific files and merge them with a hologrammed CD.

That method is only for PCs manufactured by Royalty OEMs.

These keys were released for computers built before Feb 2005 that have SLP media without a factory key.

This script is an excerpt from http://www.microsoft.com/technet/prodtechn...oy/wpadepl.mspx for each Obj in GetObject("winmgmts:{impersonationLevel=impersonate}"). InstancesOf ("win32_WindowsProductActivation") if Obj.ActivationRequired <> 0 then 'If necessary, save/set proxy Obj.ActivateOnline() 'If necessary, restore proxy end if next

If you keep changing the origional post the answers may or may not be applicable. instead start a new post for new questions. Modify one of your dosnet.inf/txtsetup.sif file sets to copy a tagfile to your HD. At T-12 call a script from cmdlines.txt that checks if your tagfile exists on your HD and installs software. You will need an $OEM$ folder to hold the cmdlines.txt but the source files can be anywhere on the CD. (I keep these files under $OEM$ but not in one of the special folders that get copied to the HD.) You can also use DetachedProgram in one of your winnt.sif files but this might be to early for some installations.

Why can't you use the $OEM$ folder and set OEMPreinstall to Yes in one of the winnt.sif files and No in the other file?