Tomcat76

Updated again... Fixed support for Chinese Simplified, Chinese Traditional, Portuguese and Portuguese Brazil language packs for .NET 2.0 SP1, .NET 3.0 SP1 and .NET 3.5. @fric You're welcome

I was about to say that. But even if you disable SFC, you still need the cat file for the IE7 cumulative update (KB947864). This needs to be done like this: DELCATS=1 DELCATS_OVERRIDE=KB947864-IE7 "KB947864-IE7" is the name of the cat file inside the KB947864 update for IE7 without the .CAT extension.

You can also use the regular link for the roots update. What's weird is that this one is only a few days older than the previous one (December 2007), the time stamp is from March 2008, and they only started pushing it through Windows Update now. Must be something special if it needs to go through 5 months of validation...

New version is out, with thanks to Acheron Please read the introduction post because several things have changed.

@kenlau The newest version of the HFSLIP time zone plugin is compatible with SP3. @Neo2x I removed it from both lists because it isn't shown on Windows Update, but I'll put it back to avoid the confusion.

So far it seems to be going OK. .NET 3.0 SP1 from dotnetfx35.exe = OK .NET 3.5 from dotnetfx35.exe = OK .NET 3.0 SP1 language pack from dotnetfx35langpack_x86XX.exe = OK The only thing I'm still struggling with is the language pack for .NET 3.5 specifically from dotnetfx35langpack_x86XX.exe (the vs_setup.msi stuff). For some reason, it expects the .NET 2.0 SP1 and .NET 3.0 SP1 binaries (MSI and MSP files) in the root folder but that's not where they are located by default if you extract the language pack executable. I can have SNM copy the files, of course, but the point is to get the bits for .NET 3.5 only as the language packs for .NET 2.0 SP1 and .NET 3.0 SP1 are already processed seperately (with success).

Windows Update now wants to see KB898461 on XPSP3, yes. HFSLIP needs to be updated for this because the update doesn't contain SP3 binaries, but I prefer to make it a test release and wait a few days before making it a final in case it's just an error.

Why do people keep saying that? HFSLIP is perfectly capable of slipstreaming the Service Pack too, and it does it before anything else. Moreover, the Service Pack is slipstreamed into the source in the SOURCE folder. How HFSLIP works: 1) slipstream Service Pack into SOURCE 2) extract hotfixes and collect binaries into temporary folder 3) copy SOURCE into SOURCESS 4) slipstream collected binaries into SOURCESS @DPS I haven't tested slipstreaming WMP10 into XP SP3 because I didn't consider it "crucial" enough to delay the release of HFSLIP 1.7.6 even more. Also, the plan is to remove support for it in the future (the pre-alpha of HFSLIP 2.0 that's available here already doesn't support it). By the way, I'd like to know why you're using WMP10. WMP9 should play what WMP10 plays, and if you still want to upgrade why not take WMP11? I can't keep supporting every single version that Microsoft releases, and doing that slows down the HFSLIP run for people who either want "the basics" (point updates for stock components) or "the latest" (major upgrades). This is not a reproach; I'm only trying to find out what's so special about WMP10.

Anything reported in C:\WINDOWS\setuperr.log on the newly installed system?

Yes, I noticed that too. HFSLIP will need to be updated because the KB898461 update (even the one Windows Update downloads) doesn't have SP3 binaries. The SP2 binaries need to be force-copied.

Something seems to be overwriting it if it's set beforehand. Right now I can only come up with running this after first logon: REG DELETE HKCU\AppEvents\Schemes\Apps\Explorer\Navigating\.Current /va /f

Wow, man... You rock .NET 2.0 SP1 = working .NET 2.0 SP1 + .NET 2.0 SP1 language pack = working I also prepared the code for .NET 3.5 and the .NET 3.5 language pack but I still need to test it. A new version of Silent .NET Maker will be released shortly, including an updated 7zS.sfx file. BTW... Does anyone know if a full standalone package exists for .NET 3.0 SP1?

I have only tested this with Windows 2000 as the host OS. For that OS, you need to put update.exe from the 32-bit version of SP2 for Server 2003 in the HFTOOLS folder. Maybe the same needs to be done if the host OS is Windows XP or Server 2003.

@Acheron HFSLIP no longer replaces mstsc.exe directly. If you can tell me with absolute certainty that old Terminal Services clients aren't installed because of this, and that they aren't installed via another way (registry hives, etc.), I may consider having HFSLIP remove the uninstall command. By the way... If you're using XP SP3 this shouldn't be a concern as it already comes with TSC 6.0. But I see your point on this being done for each user account. I'll see if I can relocate the command to HKLM. @baruse I just created a new thread in the HFSLIP forum. Hopefully that clears things up. @SQ5FG The differences concern Win2K+WMP9, Win2K+WMP9+FDVFILES and Win2K+FDVFILES.

Because of a problem with SP3's wbemoc.inf, a custom cab package was created containing updated versions of wbemoc.inf. If the SOURCE folder contains Windows XP SP3 or if it is to be updated to SP3, HFSLIP won't continue if wbemoc.cab is not present in HFCABS. You can read more on the wbemoc.inf issue and others involving Service Pack 3 on this new page on the HFSLIP site. The new page is also accessible from the Guidelines section in the main navigation menu on the HFSLIP site ("Windows XP SP3" link). The Basic how-to and Downloads pages were updated as well.

There is something strange going on for you. According to the log files, SP3 isn't slipstreamed. Additionally, you write this: If I understand you correctly, it means that HFSLIP processes WMP11 and then processes the SP3 installer as if it were a regular hotfix. This is strange because the SP3 installer is in the HF folder, so it should've been picked up by HFSLIP and slipstreamed first (before anything else). Secondly, files with "936929" in their name (the KB number for SP3) are blocked from being processed as normal hotfixes so it should never have been processed after WMP11. I can't duplicate the problem you're having, and I also can't find a logical explanation for it after going over the relevant bits of the HFSLIP code; everything appears to be OK there. Also, I did not change the handling of WMP11 or SP3 between RC9 and the final of HFSLIP 1.7.6. By the way... Are you using the final version of XP SP3? If you downloaded it from the Microsoft Download Center its name should've been "WindowsXP-KB936929-SP3-x86-KOR.exe". Is it 331,133,480 bytes large?

No, you don't. I have updated the link in the navigation menu of the HFSLIP site so it clearly says that it's for XP SP2 only. The update list for XP SP3 doesn't have it either.

I don't really see what's so confusing about it. Slipstreaming is not the same as installing.

You should really thank 7yler for this...

The logagent.exe problem should be fixed with HFSLIP 1.7.6 (among a few other enhancements related to FDV's fileset). You can remove the WMPREDUC=1 fix but it isn't really necessary as HFSLIP 1.7.6 no longer uses it. I don't know if you realize this, but /catalog is a switch and not a subfolder. Have you tried putting wsusscn2.cab into the same folder as the rest?

Heh... And start /? would've given me the same answer. That'll teach me... Standalone executables are now installed like this: START/WAIT "" "%SRCPATH%<Userfolder>\filename.exe" Seems to work just fine. Thanks again...

I can see why that's happening, but it surprises me that no one mentioned this before. Maybe no one has ever used FDV's fileset with WMP9. Windows 2000 setup places logagent.exe and laprxy.dll in the Program Files\Windows Media Player folder, but they are expected in system32 with WMP9. When WMP9 is slipstreamed, HFSLIP normally modifies TXTSETUP.SIF so these files are copied into the system32 folder directly and a post-install command is executed at T-13... except when using WMP reducer files in HFCLEANUP (in which case HFSLIP won't tamper with the copying of logagent.exe and laprxy.dll, and won't ask to execute the post-install command). You aren't using the WMP reducer files, so HFSLIP will update TXTSETUP.SIF and add the post-install command. But apparantly FDV's fileset removes the references to logagent.exe and laprxy.dll from TXTSETUP.SIF again so these files never get copied, which causes the post-install command to fail. This is the error you're seeing. In the mean time, you should be able to work around this by specifying WMPREDUC=1 in HFANSWER.INI. HFSLIP sets this variable internally when slipstreaming WMP9 if WMP reducer files are detected. Setting this in HFANSWER.INI doesn't have any side effects in your case because it's only used by the part of the code that slipstreams WMP9.

Thanks for this. It's a really valuable tip, so you got yourself a spot in the hall of fame... Every additional file is now installed directly from the source, except when it's determined at T-13 that there are spaces in the path to the source, in which case silent executables from HFSVCPACK and HFFIRSTLOGON are first copied to the hard disk and installed from there. This is because of a limitation with the START command; it appears it can't handle quotes if they follow it immediately.

@kenlau Have you also tried with just IE7 (no updates)? It is also possible that the problem lies with the silent executables you have. There could be a conflict. @willydejoe1234 I haven't checked if UPHClean_Setup.exe is still needed, but I think it's not in SP3. I'm still including it myself.