Shandra

In addition, and as a final remark on my behalf (it is time to get back to my real studies, though it was fun and reminded me to the time of 2005 where I was one of the minorities who bought xp x64 and where often forced to get used to modify .msi's with Orca) - I tried it again with the (official technet) sysprep way... the reason why WinToolkit recognized my first preped image as being corrupt was that I have chosen a custom name for the image.... still now, and after I've named it right, and though simply building a .iso via WT from the syspreped .wim worked like a charm (the get-package information afterwards was the same as for a real sp1 install-media), it failed when I tried to integrate IE11 and its prerequisites. That doesn't worked out well - WT integrated fine, the install resulted in failures which may well be searched in this forum for the early times of IE11 and its integration. So i am not sure if I missed some KB or if it ain't be possible to use WT on a syspreped .wim (which makes no sense IMHO, so my guess would still be a fault in my procedures - and that one may include that I where using a WinPE.iso handed over to the VM that where build with the current ADK release for Win8+; I used that because it is much easier to apply the dism commands (/capture-image) to build the .wim then using the old variant with imageX). As said, I still think that it is possible (else all technet sysprep how to build an oem/multilingual media, how to deploy sp1, etc. descriptions wouldn't make sense; At least for the sysprep way). In the meantime where the vm(s) where occupied with their install I checked the MD5 sums of the KB976902 files with their corresponding parts of KB976932 (SP1) and there where no differences to be found (haven't checked all of the files), so it should - in theory be possible - to get along that way to a working (and future proof) image... But as the OPs question (OEM based Win 7) and my curiosity about Dreamsparks PreSP1 Server 2008 R2 .img are just a minority in cases that may be neglected in the development of WT (or the Foolproof assignments/modules therein (which in my experiences make up 3/4 the time in the development of a GUI based project)) I just give up with trying any further (and will continue with my real work/study again ).

And keep in mind, that the OEM key from the sticker may be a "one-time only" key - as in using it, the activation will be bound to the hardware it is used on (I am mostly using SystemBuilder Variants(*1) for my system (as I build 'em myself or buy 'em without OS) and there thats not a problem (in short: I simply lack the Win7 OEM experience)), but as far as my knowledge has grown on the subject a vital change in hardware may or may not be activatable via phone or strictly license termin speaking may simply be rejected - so I see a reason to the "why someone will stick to autoactivation as long as possible", because then the OEM key could def. be used on changed hardware (if it is the first time this key is used - so why waste it on the OEM Hardware where its not needed) with just using the online activation. I am really not sure on this one, the MS specific sides (technet, etc.) are AFAIK strict on this one-time bound between key and hardware, other sides claim that an activation via phone is still possible. P.S.: with Win8 this whole OEM/Preactivation Discussion is Void - the new scheme where the "to be activated" key for OEM Systems is kept in the BIOS is a total different matter *1: Ok, from a German Point of view and an old Sentence about the resale of OEM licenses, MS SB variants where (AFAIK) the result of that verdict (as a different model to pure OEM license (like from Dell or such); SB (OEM) license is nowadays what is nearly 100% of the time sold to the customer here in germany (and I know only a few (real minority) shops who are actually offering the real retail)... And I am not sure what that means for reactivation on different hardware or such, but according to magazines like the C't (not talking Win8+ here) SB licenses under our law should be reactivatable under new hardware (but that may well be just an urban legend).

Yup - best option for the OP - though I would assume that by just changing the ei.cfg one has to use the provided OEM Key from the Sticker. A better way would IMHO include the transfer of the needed files (as mentioned in Post #7) from the original OEM DVD/install image that are needed so that the OEM Setup installs with the default OEM Key (which is different from the unique one on the sticker) and recognizes the bios SLP-key information to autoactivate Win on the OEM Hardware. For XP those would have been the OEMbios.**_ and wpa.dl_ files from the OEM CD, I don't know what would provide the corresponding information on Win7 OEM .wims. I am not sure what e.g. Dell is charging for a SP1 Install Media replacement and if that wouldn't be a better choice then to further investigate in this slipstreaming variant.

Leaves dual packages? Strictly speaking it does not(!). The install of SP1_added .wim results in a System where dism /online /get-packages get you the same output as for SP1_installed, just with the exception of the missing KB976902-package entry. No dual entries/packages to be found; Wouldn't make sense anyway, as the dual listing (setup order) clearly states package a_v1 is to be deinstalled then a_v2 to be installed. That is, as far as I understand it, the regular way with the deployment via dism (one of the basics/fundamental differences why we can't do it the nt5 way anymore and are not going to get a fresh install with <no updates listed and no backup files> on HDD). E.g. if you integrate IE11 via WinToolkit and query the resulting .wim, you will see that first the packages for the old IE are being listed as uninstall pending followed by the new IE package with its install pending.

As predictable, adding the SP1 package after KB976902 is a no go because of the pending state for the KB integration. Maybe I am a bit over-paranoid here, as it seem all (?) of the KB*02 files are also in the expanded SP1.cab directory, though there are some differences in the update.mum of those two: >> from update.mum KB*02 <update name="976902-10_neutral_PACKAGE"> <package integrate="hidden"> <assemblyIdentity name="Package_for_KB976902_RTM" version="6.1.1.17514" language="neutral" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35"/> </package> </update> >> from update.mum KB*32 <update name="976902-0_neutral_PACKAGE"> <package integrate="isolate"> <assemblyIdentity name="Package_for_KB976902" version="6.1.1.17514" language="neutral" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35"/> </package> </update> Now lets compare some dism /get-packages information for various installs/wims (Server2k8 std - Dreamspark.img/MS_Eval.iso): - All Images where listed as: Image Version: 6.1.7600.16385 - To keep the list short I removed the install date information from the following lines - for better comparison I put each listed package from the various sources interleaved and colour-coded (pre_SP1, SP1_added, SP1_Installed1, SP1_Eval) 1: Sp1_installed means a regular install of pre_SP1 and then executing the offline SP1 Installer followed by a dism /online /cleanup-image /spsuperseded without /hidesp Package Identity : Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385 State : Installed Release Type : Foundation Package Identity : Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385 State : Uninstall Pending Release Type : Foundation Package Identity : Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7601.17514 State : Installed Release Type : Foundation Package Identity : Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7601.17514 State : Installed Release Type : Foundation Package Identity : Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7601.17514 State : Installed Release Type : Foundation Package Identity : Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~en-US~8.0.7601.17514 State : Install Pending Release Type : Language PackPackage Identity : Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~en-US~8.0.7601.17514 State : Installed Release Type : Language Pack Package Identity : Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~en-US~8.0.7601.17514 State : Installed Release Type : Language Pack Package Identity : Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~~8.0.7601.17514 State : Install Pending Release Type : Feature Pack Package Identity : Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~~8.0.7601.17514 State : Installed Release Type : Feature Pack Package Identity : Microsoft-Windows-InternetExplorer-Optional-Package~31bf3856ad364e35~amd64~~8.0.7601.17514 State : Installed Release Type : Feature Pack Package Identity : Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-US~6.1.7600.16385 State : Installed Release Type : Language Pack Package Identity : Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-US~6.1.7600.16385 State : Uninstall Pending Release Type : Language Pack Package Identity : Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-US~6.1.7601.17514 State : Install Pending Release Type : Language Pack Package Identity : Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-US~6.1.7601.17514 State : Installed Release Type : Language Pack Package Identity : Microsoft-Windows-Server-LanguagePack-Package~31bf3856ad364e35~amd64~en-US~6.1.7601.17514 State : Installed Release Type : Language Pack Package Identity : Package_for_KB976932~31bf3856ad364e35~amd64~~6.1.1.17514 State : Install Pending Release Type : Service Pack Package Identity : Package_for_KB976932~31bf3856ad364e35~amd64~~6.1.1.17514 State : Installed Release Type : Service Pack Package Identity : Package_for_KB976902~31bf3856ad364e35~amd64~~6.1.1.17514 State : Installed Release Type : Update Package Identity : Package_for_KB976902~31bf3856ad364e35~amd64~~6.1.1.17514 State : Installed Release Type : Update Except from the fact that there are 4 packages unique to the Eval (I spared them from the comparison), the only real difference (not taking into account that the dism'end SP1 updates being in a pending state for uninstall/install) is still KB976902. Even if that is added as a package after the integration of SP1 it won't be installed during setup (why should it if those files are also in the SP1.cab). Even further integrations with Wintoolkit seem to be functional, but there I only tried the integration (with the selection of IE11/IE11 prerequisites, general and security updates from WTs alphawaves' Downloader [downloaded KB2461631/2732500/2773072 couldn't be integrated]) and i havent tested the resulting iso so far. As one who has no full understanding of the processes involved my bet now on KB976902 and the dism integration of SP1 would be that it will be functional at this time, but there must be a reason why M$ let it be installed before KB976932 and is not removing it from the installed updates list. Even if i have no idea why the SP.cab includes the KB.cab files in this case, I would assume that M$ sees a reason to let the KB still be uninstallable/becoming superseded after SP1 and that this method of SP1 integration may just be functional until the time where they offer an update that supersede that KB - but thats just my feeling at this moments.

Leogolash2o: Oops, Sorry - though my system is a Win7 (SP1 build) I should have said that I am currently trying to prep-up my Dreamspark Licence of Server2k8R2 - and thats only a preSP1 .img (and using an eval iso via MSDN/Technet as a base ain't an option as that one can't be upgraded to retail). Anyway I was more curious about the possibility if (and how) it can be done then being in need of it And an erata to my previous post: I am not sure what happened during that install where both the sp and prerequisite-KB where removed from the installed update list (maybe I just messed up my memory between the dism-preped_sp1 and regular pre-sp install); The various installs I tried today removed none of those entries, and if i added the /hidesp option to the cmd-line only the SP1 entry was removed. The dism-preped iso starts up with no entries in the updates list, and as far as I remember a Win7 SP1 install is listing the KB976902 as installed (?). So maybe the way quoted by abbodi has to be modified in some way? I will play around with it this evening (as said out of curiousity) and afterwards, to be on the sure side, just doing a regular install for activation.

I tried that manual and afterwards WTK recognizes that .wim as SP1, and a VM Install of it was functional - haven't tried it any further as there is some ununderstandable Thread over at RyansVM which I do not comprehend and somehow sounds like "does those persons in any way know what they are talking about" but at least leaves some doubts towards this method (As long as I do not understand how this whole nt6 package stuff works). And what puzzles me is that it the method above only consideres the KB976932 cab and ignores the prerequisite to install sp1 (KB976902) on a freshly installed Pre-SP1 Win7. But as that one is also removed from the installed updates list if one issues a "dism /online /cleanup-image /spsuperseded" that my not be a problem after all. As an alternative I tried it the SysPrep way yesterday, but the resulting install.wim I got from that installed fine as a VM, but when I tried to add further updates to it via WinToolkit it was only recognized as "beeing corrupt" :/