Protocol7

Thanks Bilou but the snag there is that the path for oemscan.bat (or oemscan.cmd as I'm calling it now) needs to be set first and this needs the cdrom detection. The line in winnt.sif would need to read something like this: Detachedprogram=cmd.exe (or can nircmd be used here instead?) Arguments= /q /c /start /min (detect cd-rom drive letter and set %cdrom% variable) (%cdrom%\oem\oemscan.cmd)

It works! Finally! BIG thanks Bilou . This is much better than the old oobeinfo method as it sets the key first time rather than trying to replace one at a later stage. Ah, to think of all the time I wasted on that one.... Now I just have one other small hurdle to overcome. I only had an $oem$ folder on the CD to copy nircmd and the oemscan batch file to the hd so i could run them (no extra fixes or drivers). Of course, using this method kills the repair and recovery options of setup so it would be nice if i could just call them directly from the CD. I've been trying to do a hybrid of the code you listed in the arguments below and the cd-detection code that is used in oemscan.bat but my head is melting with variables, if's, do's, % signs and whatnot. So can I just ask humbly to be spoon-fed the correct code to be placed in the cmd arguments for winnt.sif? here's the cd-detection code from oemscan.bat: for %%i in (C: D: E: F: G: H: I: J: K: L: M: N: O: P: Q: R: S: T: U: V: W: X: Y: Z:) do if exist %%i\WIN51 set CDROM=%%i As you can see it looks for the "win51" file and sets that drive as "cdrom". Then it's just a matter of calling "%cdrom%\oem\oemscan.cmd" (oemscan.cmd and nircmd.exe are stored in a folder called "oem" on the root of the cd along with oemscan.exe and the directories containing the oembios files). If I can get his done I'll finally have things exactly as I want them

From looking around some more I figured out how to get oemscan to run from detachedprogram. Oemscan.bat is copied to the root of c: and executed, copying the appropriate oobeinfo.ini file to the system32\oobe folder on the hard disk. But still setup refuses to read the key from it so after I enter pass the name/organisation screen I'm still presented with the enter product key window. It seems oobeinfo is very unreliable so is there any other method that can be used to specify the product key at this stage of setup? here's how my setup is looking atm: WINNT.SIF [Data] MSDosInitiated=0 UnattendedInstall=Yes [Unattended] OemPreinstall=Yes OemSkipEula=Yes UnattendSwitch=No [GuiUnattended] DetachedProgram=CMD.EXE Arguments="/Q /C START %SYSTEMDRIVE%\OEMSCAN.BAT" OOBEINFO.INI [Version] ProductKey ="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" I hate to admit defeat but this is just taking way too long. I must have burned and done over 2 dozen installs trying to get this oobeinfo.ini method to work. So at this stage I'm just hoping there's a more reliable way to set the key.

Tried again with a regular oem key in winnt.sif and oobeinfo.ini but still no go. I'm guessing oemscan is being called too late in the setup for the copied file to make a difference. Is there an easier way to call it earlier? (currently it's running from [setupHotfixesToRun] in SVCPACK.INF). I couldn't figure out the RIS+DetachedProgram method that was posted earlier. Does RIS even work for a Home Edition install CD? Seems to be more for server-side deployment of installations.

Hi xehqter. From the command prompt in Windows I get the same error. I also tried it with promptkey.vbs (and setting a regular non-slp key in the winnt.sif file). [Hewlett] PATH=".\HPQ\" MATCHARG="XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" CMD="cscript promptkey.vbs @@@@" This didnt work either though, as when oemscan ran the script it popped up the key change dialog with no key inserted. Entering the correct one got the same "key not changed" error. Oemscan.log again shows that the command was executed successfully. When I booted into Windows I was prompted to activate. But this time when I ran oemscan (although it still didn't insert the correct key) when I pasted it into the box it said "key accepted" FreeStyler posted another method earlier using the oobeinfo.ini which seemed the tidiest way (though I haven't figured out how to stop it creating a "Owner" user by default) but yet again even though the oobeinfo.ini was copied correctly and contained the vendor-specific key, it wasn't changed. As a cop-out I could always just leave out a winnt.sif file and enter the correct key manually, but it seems as if the scripts are working for some. The hard work is done really. Being able to build one CD that can install the proper vendor-specific copy of XP is a major help. I'd just like to have them 100% authentic as you can tell from the Product ID if the key matches the Manufacturer (all this info is collected by the WGA tool) so you never know when MS might start taking notice of this. That and I hate having to admit defeat in the face of a challenge B)

Hi everyone. I stumbled on this site last week when I was trying to reinstall a Packard Bell that had a dead HD. It's amazing the work you guys have come up with and I'm very grateful to you for it I was able to put together a cd that I should be able to use on a few brands of machines but I'm having a major headache with the key change script. I'm using the changekey.vbs that TheUni posted back on page 3 of this thread but no matter what I do it always pops up a dialog box saying "Key Not Changed. You will have to change it later". Is it because I'm trying to replace a SLP key with another (vendor-specific) SLP key? I'm doing this on an OEM Home Edition SP2 (with RyanVM's post-SP2 fixes addon pack). Here's how a typical entry in my OEMSCAN.INI looks: [Hewlett] PATH=".\HPQ\" MATCHARG=".\HPQ\serial.txt" CMD="cscript changekey.vbs @@@@" The serial.txt file simply contains the vendor-specific key in XXXXX-XXXXX-XXXXX-XXXXX-XXXXX format with no quotes or anything else. Oemscan.log shows that the key script was executed successfully so there's no problem there. I also get the same result running it within Windows. I've tried this with a few different SLP keys (which I know are valid) so an invalid key isn't the cause either. Has the script been changed since then? For now this seems to be the easiest method, but if there was a way to run OEMSCAN before Windows setup looks/prompts for the key that would be even better as I could use it to set the correct SLP key at the start rather than setting one and then changing it at the end of the setup. I saw mention of running it from DetachedProgram earlier but I tried it last night and must have goofed because it didn't run. But for now if someone could help me with this changekey.vbs problem I'd be very happy as I've spent almost 2 days (and many cdrw burns) trying to nail this. Once I have this method working I can start thinking about trickier stuff like DetachedProgram.