PVU

This is my first go with XP. I've done a number of 2K installs, and did a perfect 2003 HFSLIP install about a month ago - perfect! (although there wasn't much to slip). I used 1.50 for this XP install, and got flagged on a lack of a clean source. I always do some OEM TEXTMODE driver work prior to running HFSLIP. When I got the warning, I blew right through it - thinking it might have detected the my OEM work. But since I never got this warning before, I considered that it came from HFSLIP detecting the SP2 inclusive source. My log indicates, WARNING - Previously Patched Source Detected. The "virgin" XPSP2 (Pro) source disk is a full retail version - the kind you would have bought at a store before Vista came out. So I ran HFSLIP again with a new/clean SOURCE (I copied the entire disk). But this time, I didn't do any preliminary OEM TEXTMODE work. The warning popped up again, so HFSLIP was indeed flagging the SP2 in the retail source disk. I understand the safety measure of the flag, but is this something to be concerned about? IOW, do you have to have a true "gold" disk not to get flagged? Is the flag meaningless?

Yes sir. A BIG THANKS. Tomcat, you are definitely OUT of control right now. The energizer bunny on *something*. Dude, do you sleep? Nice cab files addition, and some serious work on 1.5. All you guys are great - and a big thanks to all those guys out there testing the betas. That's huge of you

TC, you say that WU may ask for it. This looks like it was published in February of 07. I've done a few HFSLIPs since it was published on Win2K boxes, and this hasn't been an issue. Have you run into this on your Win2K installs? Or, is this happening mostly on XP and 2K3 installs? Would this have anything to do with the WU Agent and/or KB927891? The workaround is no problem, but I haven't seen this yet for 2K. I'm almost ready to check it out on a 2K3 box. Strange indeed.

Mymrik, that's happening here too (standard US/English WU). It's also happening on one of my 2K boxes that was not created with HFSLIP. This must be a WU issue. Very strange. That IE6 cumulative security update is 3 years old. Also, I screwed up and included it yesterday on a WU. I wouldn't check the box now, but after I looked up the issue and considered that WU was wrong, I ran WU again, and it asked for KB867801 again.

KB931768 replaces KB928090. Same for Win2K Pro. These are the only 2 May updates for XP (and 2K Pro).

Postscript: Not really sure what happened with WinISO or UltraISO, but they were the problem. With the UltraISO try, I was working off a re-compiled ISO image originally created by WinISO, and that could have been a problem. At the very least, I'd leave WinISO in the bag. The HFSLIP ISO image creation option worked flawlessly. Everything in SVCPACK installed without issue, and I had no KB917008 issue this time around. WU crapped out on me the first 2 times, but that's probably WU's issue. john, I was headed there next... TC, thanks. I should re-name (hahaha!) this topic, "Trouble with ISO Software"

TC, I used UltraISO (should have saved the HFSLIP ISO because it created an ISO without issue). I'm still running into the same problem, but not to the same extent. dotnet11sp1.exe was renamed DOTNET11.EXE (did not install), vbrun60sp6.exe was renamed VBRUN60S.EXE, Media Player 9 was not installed, and I'm still getting the KB917008 WU issue. In UltraISO, do you need to uncheck "Recompile ISO when Saving Directly" under Config? The renaming was not as severe, but there were some instances. There were no "~" renames - I should have checked it before the install. My next shot is to burn the HFSLIP ISO.

Are you installing the MUI CD? This hotfix was a pain to code in. It contains many files that surpass the 8.3 file naming standard.I'm not sure what MUI CD is, but from what I just googled (language changing/setting tool), I pretty sure the answer is "no". That's most surely the problem. The original filenames are hardcoded into HFSLIP.CMD so if they are renamed by whatever tool you use to create the ISO, they will not be found anymore during installation. I suppose KB917008.CAT is not renamed because it follows the 8.3 file naming standard.I have switched to UltraISO a long time ago but I'm sure WinISO should have a setting to disable automatic file renaming. Okay, that explains why IE has been acting a little off (and it seemed as if WU was struggling also). Here is a list of the SVCPACK renames: DOTNET~1.EXE should be dotnet11sp1.exe KB8324~1.CAT should be KB832414_Win2K.cat KB8938~1.CAT should be kb893803v2_w2k.cat KB9054~1.CAT should be kb905414.cat KB9236~1.CAT should be KB923689.cat KB9280~1.CAT should be KB928090-IE6SP1-20070125.120000.cat KB9299~1.CAT should be kb929969-ie6sp1-20061220.120000.cat MSDRMC~1.MSI should be msdrmclient.msi MSXML2~1.CAT should be msxml2-kb887606-enu.cat RMCLIE~1.MSI should be rmclientbackcompat.msi VBRUN6~1.EXE should be vbrun60sp6.exe I'm not using VM. Do you think I could simply manually reinstall those hotfixes again, or do you think the entire install is suspect - would you start over? WinISO allows you to rename individual items, but I can't see that you can apply a global-type setting. I'm a little lazy (too ), so I'll check out Ultra ISO, but this might be a good time to just go with the HFSLIP ISO burning sollution. Thanks

For the most part, my recent installs worked out with 1.4.3. However, on two Win2K installs, I produced the following errors: WU asked for Windows2000-KB917008-x86-ENU.EXE dotnet11sp1.exe - not found/not installed vbrun60sp6.exe - - not found/not installed The KB917008 was a bit of a mystery as it was the only HF item flagged by WU. I don't think the file is corrupt - I got the same result on 2 different computer installs with 2 distinct filesets. The files in the HFSVCPACK folder were weird in that DOSHERE.INF and tweakui.exe installed, but the other 2 did not. The dotnet11sp1 is from RyanVM. See the attached HFSLIP.LOG. In the i386/SVCPACK folder of the ISO/disk created with WinISO, there are "~" abbreviations. For instance: DOTNET~1.EXE, VBRUN6~1.EXE and some others. Is that normal? The source folder contains normal files. Only the WinISO created ISO/disk contains the abbreviated files. However, the KB917008.CAT file in the ISO (disk) I386\SVCPACK was not abbreviated. [The attached HFSLIP.LOG was modified only to remove notes I made at the end of the log to note failures] HFSLIP.7z

Thanks, TP, I'll give it a whirl. Those Nvidia drivers seem to give everyone fits. Fernando 1 has a 55 page topic on the nLite forum for just 32-bit Nvidia RAID issues. If he charged per post, he could ... upgrade to Intel. I'm an Intel guy - love their Boards and their drivers, but I also go the OEM route for the mass storage driver. I think I'll just keep manually installing their video driver when I need 'em. Although Vorck's got me thinking about C:\HFSLIP\SOURCE\$OEM$\$$\SYSTEM32 for some of the required installation stuff - on an old Intel 815 board setup. You guys have done a great job with this project. Every day I get sucked in a little further. Thanks again.

Hi all. It looks like all of this is finished. I just want to confirm that. I always merge using (the default) option A. Based on TommyP's advanced page and Tomcat76's indications, my take is that you can simply extract ALL binaries (including INFs) for all drivers into HFEXPERT\DRIVERCAB, and that you don't have to create sub-folders if you don't want to. Is that correct (assuming no name conflicts)? It would seem that sub-folders wouldn't mean much in the end due to an all-inclusive CAB. My take is that you also need to take Oleg II's advice to heart in his Third step: editing INF files. Or, is the original post about editing INFs outdated? Was this taken care of by the introduction of HFEXPERT\DRIVERCAB? As a side issue, DRIVER.CAB and DRVINDEX.INF are affected while HFSLIPping. This is more of an unattended question, but could you manually mess with those prior to running HFSLIP and get the same result? This may have been addressed, but I was considering removing some crap, and adding necessary drivers. If the answers are "simple", this may take care of this for the most part for the HFEXPERT\DRIVERCAB newbies (like me). I'm assuming that this is for all drivers except mass storage drivers. Thanks

A day later, and still no KB Article.

I missed this one. Thanks, fellas.

guy, I looked into both HF (Win2K) executables. Very similar. The article didn't indicate that KB935843 replaces KB925902 (which seems strange given the contents). Can KB935843 replace KB925902? If not, I wonder why they didn't do a KB925902 v2.

It looks like KB925902 wasn't tested well enough by Microsoft: ... KB935843 patches/fixes (but does not replace) MS07-017/KB925902. Download

I searched and didn't run across this here. On the web, there was minor reference, but nothing ironclad. I want to slipstream a few hotfixes into a Windows Server 2003 disk, and will OEM/textmode setup a few drivers. One of which is the ATI Radeon video driver. I read some reference to using the XP driver for Win2K3, but... Which ATI driver (INF) should you use? The latest are C2_44981.inf (Windows 2000), and CX_44981.inf (XP). Thanks

Microsoft Security Bulletin Summary for April 2007 (v2) http://www.microsoft.com/technet/security/...n/ms07-apr.mspx For Win2K: MS07-017 was released on 04/03 (Tomcat76 has already addressed this on his dynamic page) - KB925902 replaces KB896424 and KB91219 MS07-020 - KB932168 replaces nothing - added HF. MS07-021 - KB930178 replaces nothing - added HF. MS07-022 - KB931784 replaces KB920958. Don't know if MS07-017/KB925902 was tested yet. 020, 021, and 022 are brand spanking new.

It looks like it replaces: KB896424 MS05-053 Vulnerabilities in graphics rendering engine and KB912919 MS06-001 Vulnerability in graphics rendering engine

LeveL, I'm sure it would. So would HFSLIP. I generally like to do some $OEM$ pre-install work in the SOURCE folder prior to running HFSLIP. Actually, I think the way I do it, I have to. IOW, I "can't" modify winnt.sif after HFSLIPing. Last time I did, I blew it to a degree, and Fernando 1 reaffirmed this. Anyway, the INTEGRATE command worked without issue. I just posted to see if I had missed something with post 2K versions - to see if others were getting the same issue. I think it's my own little weird situation.

TC, it's the weirdest thing. I expected to write back saying, "yep, that got it". I even waited to try it. Still no go. The result was the same as running the simple, C:\SP2\i386\UPDATE\UPDATE.EXE -s:C:\ Strange for sure. Even stranger now that you say it should work.

...prior to using HFSLIP. I have manually slipstreamed Service Packs before - mostly SP4 into Win2K. It's been a while since I slipped SP1 into Win2K3, and, to be honest, I can't remember exactly how I did it. Anyway, whenever I've slipped SP4 into Win2K, the integration process (via UPDATE.EXE) always produced the additional Service Pack files - SPNOTES.HTM and CDROMSP4.TST. These were always produced by expanding the Service Pack into a directory (C:\SP4), and then using the UPDATE.EXE command (C:\SP4\i386\UPDATE\UPDATE.EXE -s:C:\). When manually slipstreaming SP2 into the Windows 2003 i386 folder (located at C:\), the integration worked. Windows said so. But I noticed that there were no additional files created (that would be needed to burn a disk). Specifically, there were no SPNOTES/RELNOTES.htm (not a big deal), and no win51is.SP2. So of course I tried it again, and got the same results. So I googled, and ran into this one. It gave me the "bright idea" to dump the whole 2003 disk into a folder, and use the INTEGRATE command. Well, that did the trick. I got my additional files - most notably, win51is.SP2. Then for fun, I compared the i386 files created by the UPDATE command and the INTEGRATE command (and this was the folder that I dumped all original disk contents into) with WinMerge. They were different - some binaries were different, and there were additional files in the INTEGRATED i386 folder. Again, I can't remember how I did SP1 with Win2K3 before (I probably nLited it), but did something change concerning manually Service Pack slipstreaming in (XP and) Windows 2003? The bottom line is that the UPDATE command didn't get it done the way the INTEGRATE command did. But then again, I didn't dump all of the original 2003 disk files into a folder when running the UPDATE command. [i put this here in preparation for HFSLIPing a few other items, but I've "always" manually slipped service packs.]

Rov, I just PM'd you. "Call me". I can help.

TC, thanks for the update I know it's a lot of work to maintain your dynamic pages.

It's good - at least now it is. So is 1.5.0.11. The Check for Updates tab worked.

Thank you Supe.