Tomcat76

He showed it twice (posts 17 and 19). The file is OK as far as I can see...

That file looks to be fine. I think you should try removing I263_32.drv, ir50_32.qtx and l3codecx.ax. If that doesn't help, it's surely the lack of an INF file in HFEXPERT\CODECS. I can't think of anything else because codecs install fine here.

I split this topic because it may be useful to other people. Thanks. I just updated my XPSP2 list. The link on my update lists still work. I just checked them and the version is the same as what you attached. I don't think that should be a concern for you because HFSLIP ignores all .CAB files in HFCABS that do not appear on my update list. HFSLIP only searches for CAB files with specific names in that folder.

What could be an issue is that you don't have an INF file in HFEXPERT\CODECS (or in HFSVCPACK). For some of those codecs, simple registration (what HFSLIPWU.INF does) is not enough. I'd still like to have a look at your HFSLIPWU.INF file from that last run, though.

Thank you, officer Lewis

Do you still have the problem if you remove WINNT.SIF?

The new version is out. It defaults to slipstreaming IE7 into Windows XP, but I also re-introduced the possibility to have it installed at first GUI logon and even made that the default method for Windows Server 2003 (since slipstreaming still isn't supported for 2K3).

I've just noticed that many of the localized packages of IE7 have not yet been released as a "non-WGA" installer. This could be problematic since HFSLIP 1.6.4 defaults to the "SVCPACK method" which will fail if the OS requires validation. I don't think I will embed the code for the "first GUI logon method" again; so HFSLIP 1.6.5 will simply default to slipstreaming IE7. Sorry for the inconvenience.

You haven't read the info on IE7 slipstreaming. After you've fixed those problems, please attach your HFSLIP.LOG, TXTSETUP.SIF (not WINNT.SIF) and SYSOC.IN_ files.

Don't bother. The reason why AU/WU/MU don't work is the same as lek's: the HFSLIPWU.INF file is practically empty. But the reason why your HFSLIPWU.INF doesn't do anything useful is probably due to the fact that you aren't using a clean source as a base. I can see that clearly by looking at your TXTSETUP.SIF file. Please don't reuse an HFSLIP-modded source (or modded by another tool) because HFSLIP can't handle that.

Can you compress and attach your NEW TXTSETUP.SIF file? And if I may give you some advise... Please take a look at my hotfix list and remove all updates from the HF folder that are not shown. I see many (potential) problems.

That is actually by design. There are files which don't exist in the original source yet and adding them into AU.INF is too difficult because localized versions of AU.INF contain special characters. Stripping everything away from AU.INF and having HFSLIPWU.INF take over the necessary actions is the easiest solution. That's the version of the wrapper. What's the timestamp? 31-Jul-2007? You see the same symptoms as lek and he never really said that his problem is solved. It's fine. I'd like to have a look at these files:HFSLIP.LOG SOURCESS\I386\HFSLIPWU.INF SOURCESS\I386\TXTSETUP.SIF

Some programs may need .NET 2.0 to be activated, but I agree with Arie that that setup is too complicated. Here's what I'd do in such case: SVCPACK.INF: 1) Install DNF20.exe 2) Install all apps that can be installed from SVCPACK.INF (including Catalyst Control Panel) 3) Registry edits, etc. 4) Install DNF11.exe at the end <Windows setup finishes> First logon: 1) Install "mini" DNF30.exe and apps that can't be installed from SVCPACK.INF

Only when installed from SVCPACK.

Can you show me your HFSLIP.LOG file?

tzchange.exe is a utility to install or update time zones, but it isn't needed here because every time zone update (every registry edit) is hard-coded in this package. Just drop the file in HFEXPERT\WIN\SYSTEM32 if you want to keep LANDesk happy...

IE7 doesn't update this file so it should be safe. I've been slipstreaming it with IE7 since May 2007.

Actually, Silent .NET Maker determines the name of the XPSEPSC update inside the .NET 3.0 package and then searches for a file in the main folder of which the name starts with that (and then replaces the original with what it found). The reason SNM takes the complete name of the original executable is so the update for the language pack is not used by mistake. You probably mean that you are installing DNF11.exe and DNF20.exe from SVCPACK.If you install .NET 1.1, your computer needs to be rebooted before you can install .NET 3.0. To be more precise, the problem is that if you install .NET 1.1 and then .NET 2.0 (either separately or as part of .NET 3.0), then .NET 2.0 won't be "active" yet. And .NET 2.0 needs to be "active" before you can install the extra programs that are inside .NET 3.0. But if you install .NET 2.0 first (or .NET 2.0 as part of .NET 3.0), then .NET 2.0 will be active, allowing a successful install of the other .NET 3.0 components. If you want to install everything without rebooting, you only have one option: DNF20.exe > DNF30.exe > DNF11.exe What you propose will work because the final reboot of Windows setup (which occurs after .NET 1.1 and .NET 2.0 are installed) will make .NET 2.0 active. DNF30.exe can therefore be installed at first logon. Does that make more sense?

@Floppy I moved your post here.

It is normal if you don't put it in nLite's "keep list". You may find this utility useful if you want to use nLite after HFSLIP. It must be run before running nLite, though. What I wonder about is the title that's showing in the title bar. Is this a modified version of Silent .NET Maker?Not that it's important at this stage, but the XPS update named as xpsepsc.exe is not supported. You should keep at least "xpsepsc-x86-en-us" in the name. I see two problems.1) You are including both msxml6_x86.msi and msxml6-KB933579-enu-x86.exe. Silent .NET Maker only takes one and it uses the MSI because it's faster, but the file named "msxml6_x86.msi" is old so you should remove it. Silent .NET Maker will then use msxml6-KB933579-enu-x86.exe. If you want, you can use msxml6.msi from inside msxml6-KB933579-enu-x86.exe to make things faster but it's not required. This should solve the KB933579 problem. 2) Your KB934238 problem is probably due to the absence of the KB934238 update for the main .NET 3.0 package. You only have the KB934238 update for your language pack.

Why don't you just rename the FDVFILES folder and run HFSLIP again?

Fudeba-- HFSLIP is for updating a Windows source, not standalone packages of .NET Framework. You can't even install those updates without installing .NET 1.1 and .NET 2.0 first.

Well... The only thing I can think of is that something is stripping away Windows Media files or catalog files.

This file can't tell you whether all hotfixes were slipstreamed correctly or not. It only displays a list of NEW files. You probably misread. There is a way to reduce the amount of HFSLP*.INF files. See here. It's created by HFSLIP. It's for the Show Desktop icon that is missing when you slipstream IE7. At T-13, sdesktop.scf is copied into the correct location with the correct name depending on the language your source is in. See HFSLIPSD.INF. Yes; that's what it's for. I updated the intro post a little.Thanks.

Your HFSLP151.INF file is fine. It's exactly the same as mine, though it's #152 here because I'm also slipstreaming WMP9. Do you still have the problem if you don't use FDV's fileset?