Tomcat76

So the file was corrupt?

If you want, you can try out test release 70820a which removes the %SYSTEMROOT%\HFSLIP folder at first GUI logon. But I'd definitely try to figure out the cause of your problem because your situation isn't normal.

If the .REG files were placed in HFGUIRUNONCE you may need to reboot first before they take effect. Did you try that before reapplying them? Well... Installation of IE7 requires the OS to be activated already, otherwise the setup program will abort. I suppose your "regular" XP source is a corporate edition or one that doesn't require activation, which explains why IE7 installed properly on that. You could try to slipstream it instead by using IE7SVCPACK=1 in HFANSWER.INI.

Your log seems to be fine at first glance, though I'm not sure WGAPluginInstall.exe is supported properly. Can you make an installation without nLite? I want to make sure it doesn't mess up the RunOnceEx that occurs right before SVCPACK.INF is accessed.

It's not "unusual" after all then. The latest test release doesn't copy over SFCFILES.DLL if both SFCFILES.DL_ and SFCFILES.DLL exist in the source.

For Japanese you need 1.6.2 or newer. For other supported languages you need 1.4.0 or newer.

Something else must've gone wrong. The INF files should be processed before SVCPACK.INF is. HFSLIP.CMD is called from SVCPACK.INF so at that point it should be safe to remove the %SYSTEMROOT%\HFSLIP folder. Do all the HFSLPxxx.INF files still exist in the source after running nLite? Are they still referred to from TXTSETUP.SIF?

Well there's your problem. You have both sfcfiles.dl_ and sfcfiles.dll in your SOURCE folder. Windows setup can only copy one and it prefers the compressed one. HFSLIP updates only one file and it takes the non-compressed file. This is an unusual situation because a Windows source should only contain SFCFILES.DL_. My guess is that you used a modified (and uncompressed) sfcfiles.dll some time before applying SP4 to that source. You don't need to run HFSLIP again per se; you can just delete the file that wasn't updated by HFSLIP from your SOURCESS folder. In any case, deleting the uncompressed file in your SOURCE folder (the SP4 version is the compressed one judging by the dates you mention) should prevent this issue from happening again in the future.

892130 - LegitCheckControl.cab - not a security update 936181 - MSXML 4.0 August '07 - search for "936227" in the_guy's list 933579 - MSXML 6.0 August '07 - search for "936227" in the_guy's list 938828 - "STOP 0xc0000005" - not a security update 937143 - Cumulative IE update August '07 - typo in the_guy's list; he has "937413" 927891 - Access violation error - not a security update 931836 - 2nd cumulative time zone update - not a security update 924496 - Vulnerability in Windows Object Packager - replaced by 937143, which you don't have

Bit difficult, but it seems Windows Update is tripping over olecli32.dll and sfcfiles.dll. What are the versions of these files before and after installing the Rollup on top? The latest version of olecli32.dll can be found in Windows2000-KB913580-x86-ENU.EXE. The sfcfiles.dll file should be the one from the Rollup.

Please... read the note at the beginning of the first post. This is a general problem with the Windows/Microsoft Update site which also occurs when installing KB933360 by hand. Temporary fix: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones] "TZVersion"=dword:00000002 But when WU and MU are finally updated, you'll have to change it back to: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones] "TZVersion"=dword:00000003

Yes. Read the note at the beginning of the first post...

The syntax is the same, but what may be your problem is that Windows 2000 needs full paths at T-13 and T-12. This, for example, won't work: REGEDIT /S myfile.reg It should be done like this: %SYSTEMROOT%\REGEDIT /S myfile.reg

I think you'd be better off reporting this to the developer. We are only "using" it. http://www.ryanvm.net/forum/viewtopic.php?t=5017

I have a couple of questions... Is Windows2000-Script57.exe the new scripten.exe renamed so it's supported by the current final release? If it is, you may want to know that it can't be slipstreamed properly right now. MS screwed up the digital signature in the binaries inside that update causing Windows setup to refuse to copy them into DLLCACHE. However, HFGUIRUNONCE didn't fail on me during the tests I did with the new scripten.exe. Does the User Profile Hive Cleanup Service install properly? (see Add/Remove Programs) You are slipstreaming MDAC 2.8 SP1 (MDAC_TYP.EXE) but also a hotfix for MDAC 2.5 SP3 (MDAC253-KB927779-x86-ENU.exe). You need MDAC281-KB927779-x86-ENU.exe when slipstreaming MDAC 2.8 SP1.

They also withdrew WindowsXP-Windows2000-Script56-KB917344-x86-enu.exe (including the localized builds) from the Download Center. This just leaves us with the basic KB917344 hotfix for WSH 5.6 so I was afraid the Windows Update site would be updated to include the new scripten.exe on Patch Tuesday. Luckily that didn't happen. I hope that's because they are aware of the problem but I reckon it's just because it hasn't been localized yet. But least Windows Update is OK if you only slipstream the mini hotfix into WinXP, or IE6 (with SCRIPTEN.CAB) + the mini hotfix into Win2K.

I was familiar with the term "softlink" but didn't know "junction" could refer to the same thing as well. Have you used DOS-based tools before that can handle junctions?

Well... If it doesn't work with CMDLINES.TXT either then chances are slimmer it's an HFSLIP-related problem. And the fact that you say your CMD and BAT files don't work after Windows setup has completed is strange as well. BTW... HFGUIRUNONCE is intended for programs/files to run after the first user logon. Can I see your HFSLIP.LOG file? Are you using other tools to slim down the new source?

HFSLIP can handle MSI files for MSXML in the HF folder. It can be used to speed up the process (one extraction instead of two). MSXML4/6 as EXE: extract EXE > extract MSI > process DLLs MSXML4/6 as MSI: extract MSI > process DLLs That's what HFSLIP is doing internally. If the first worked for you, I can't think of any reason why the second would fail because the MSI file is the same. You took it out of the MSXML4 EXE package but that's exactly what HFSLIP is doing too when you give it the EXE.

There is a non-public hotfix for aclayers.dll (KB917140) but I'm not sure it would solve the problem. I suggest you run a chkdsk /r on the partition which holds your HFSLIP working folder. Then delete the SOURCE folder and copy over your CDs again. I suppose you already tried another blank CD/DVD so I won't mention that

There must've been a conflict somewhere. Did you remove the previous MSXML4 update?

No problem. Try the new version...

2K is OK.

OK

Are you sure the file isn't corrupt? Does it have a newer date than the one in the SOURCE folder?