Tomcat76

I'm working on one: link

HFSLIP 2.0 is still a very long way to go, so 1.x is still being updated. HFSLIP 1.x has the Recovery Console installed from a CMD file at T-13. The method only works for CD-based installs because I never found a way to poll for UNC paths simultaneously. It also requires the user to enter a multiboot path (if applicable) at the beginning of the HFSLIP run. Since I have eliminated all other needs for the multiboot path in HFSLIP 2.0, I decided to drop this feature in HFSLIP 2.0 until a better solution is found -- one which works for network-based installs too. If need be, I'll have it copy all files that are necessary to install the Recovery Console to hard disk (into the temporary %WINDIR%\HFSLIP folder) but then I first need to find out which files are needed. If you have any issues with how the Recovery Console is being installed with HFSLIP 1.x, please start a new thread.

I thought about the wbemoc fix again today and wasn't really satisfied with it. It was too complex, so instead I made a cab package that's supported directly by HFSLIP (1.7.6rc9 or higher) if placed in the HFCABS folder. This is just one file instead of two files compared to the HFTOOLS plugin, and the package is a lot smaller too now (5.14KB). Sorry for all this messing but I want to keep it as simple as possible for the user. In case you're wondering... There aren't any functionality changes between the plugin I released yesterday and the HFCABS package that's available now. The only difference is that I added a blank line above the [strings] header in the English wbemoc.inf files because it was glued to the other content, but that's only a cosmetic fix. By the way... No one explicitly mentioned this so I need to ask: is everything OK now if nLite is used afterwards?

Sort of. Passive mode to be exact, using the /qb switch instead of /qn. This means there's no user-interaction but you see the progress.

You don't need SP1 to slipstream SP3.

Well... HFSLIP wasn't really made to process only addons and SVCPACK installs. Such set ups weren't tested extensively so it's still possible that the problem lies there. Try HFSLIP 1.7.6rc8 with the wbemoc.inf fix in the HFTOOLS folder. If that doesn't help, try to find out if an addon is causing the problem.

When slipstreaming the service pack it doesn't matter, but you need at least SP1 when installing it normally (though I forgot if that was just for MCE or for all versions of Windows XP).

Yes-- just messenger.msi.

The HFTOOLS plugin to fix wbemoc.inf is now available from the main post in this thread. I released another RC because I pushed in a change for Chinese (Hong Kong). If all works well with this set up (with and without nLite), then a final version of HFSLIP 1.7.6 will be released tomorrow.

No... Take a left angle, then go straight from there. You can do it just like that, yes.

Can you ZIP and attach the HFSLIP.LOG file?

Hi Nuhi I'm using the only way there is with FIND.EXE while keeping it Unicode. But it doesn't really matter anymore. I found a minor problem with this method affecting some languages so I'm gonna steer away from it. Thanks for dropping by. To the others... I'll be releasing a final version of HFSLIP 1.7.6 shortly (probably tomorrow) which will contain all the changes mentioned in the changelog except the fix for wbemoc.inf, but will only post it here in the Test Releases thread. An external plugin package should be ready by tomorrow too so this combination can be tested extensively (including with nLite). If everything's alright with the plugin package, I'll make the final HFSLIP 1.7.6 public.

Well... If you count in the known limitations it should be OK to use. There are many. You should start out clean (blank folder), read the entire changelog, then populate the folders as necessary. What isn't mentioned is that DX9 cab files are no longer supported; you need to have the redist executable in HF, but that should be fine because HFSLIP 2.0 creates a custom cab package to be used the next time you run it. Actually, there is. I just checked and you can have it installed silently at first logon with HFSLIP 1.3.0+ if you put it in the HFGUIRUNONCE folder.

@kenlau You don't have WindowsUpdateAgent30-x86.exe in the HF folder. It's one of the requirements for Microsoft Update. KB892130 is LegitCheckControl.cab. I don't know about running WGA for the WMP11 initialization. I never had it. Is your LegitCheckControl.cab up-to-date (20-Mar-2008)?

I'm doubting as to what really the best solution is: "unicode.header+wbemoc.inf" or just custom made wbemoc.inf files in a plugin package. HFSLIP edits wbemoc.inf to avoid the error message for "napclientprov.mof". You see that error because wbemoc.inf wants to copy napclientprov.mof (and napclientschema.mof) from the CD, but it doesn't exist in the source with that name. MS have renamed it to napprov.mo_, and not even in a clean way: they compressed napclientprov.mof to napclientprov.mo_, then renamed napclientprov.mo_ to napprov.mo_ (instead of first renaming and then compressing). So they probably intended to have it on the CD with a long file name originally. But the guys who did TXTSETUP.SIF/LAYOUT.INF decided to rename it but didn't notify the people who did wbemoc.inf. --- It's always nice to come up with theories... The best way to work around the problem would be to change this: napclientprov.mof napclientschema.mof ...into this: napclientprov.mof,napprov.mof napclientschema.mof,napschem.mof But that's not something HFSLIP can do, so it just removes the lines. This is not really a problem because the files are also copied via TXTSETUP.SIF (wbemoc.inf just does double work), but it's not as clean. So using "unicode.header+wbemoc.inf" is much easier for me, but it's pushing the use of the unclean method. For the end user it shouldn't be that much of a difference in that both scenarios would require an additional package to be downloaded.

I don't see how. If you still had SP2 from before and now put in SP3, you'd be wasting more time DELETING the SP2 installer...

I also noticed the nLite'd file is in ANSI and that it's broken. As far as the one modified by HFSLIP is concerned... If the original wbemoc.inf is in UNICODE, HFSLIP will use FIND.EXE to remove the instances of napclientprov.mof and napclientschema.mof from that file (because FINDSTR.EXE can only be used for ANSI files). There's no other option. I'm in the process of creating an HFSLIP plugin that includes edited wbemoc.inf files for both Professional and Home, and for all languages, but that's still going to take some time. Either way, the resulting file is in UNICODE and Windows installs fine if you don't use nLite after that, so I don't understand why nLite has a problem with it. Is it that "FF FE binary string"? Does the lack of it prompt nLite to treat is as an ANSI file? Whatever it is, I don't have another option right now.

You can include as many SP installers in the HF folder as you want, but HFSLIP will only use the latest -- and only if it's still applicable.

Yeah, I just tested it myself and can confirm it. I first thought it was because most of the silent .NET installers remove that key but don't recreate it, but that doesn't appear to be the problem. I'm not sure if this is of help, but I did one more test using the latest pre-alpha of HFSLIP 2.0 with messenger.msi in the HFFIRSTLOGON_SW1 folder and it installed fine (at first logon).

Does everything work if you replace WBEMOC.IN_ created by nLite with the file that HFSLIP made? I want to see if this solves the problem.

@Ehdu It appears that messenger.msi can't be installed at T-13. Someone else already noticed that. @0d14r3 From what you're saying, it is unclear to me if you used a clean source for HFSLIP or not. As Martin H points out, you should first run HFSLIP on a clean source. If you used HFSLIP first and then nLite, then the problem might be that you don't know what the HFSLIP_POST_getnewfiles_v3.cmd plugin is for. If this plugin is in the HFTOOLS folder, a file named NEWBIN.TXT is created when HFSLIP has finished. This file contains the file names that you should enter in nLite's Keep box. I can't see any trace of the files that were slipstreamed by HFSLIP in the [KeepFiles] section of nLite's LAST SESSION.INI log you provided.

I don't think it's lame. I could come up with a set up that allows either one or the other, but it would take some time to work out.

Please remove IE7MUI-x64-enu.exe. I don't know if it's the source of your problem, but it's definitely not supported. cWnd.exe is supported with both versions of HFSLIP. If you tried to attach HFSLIP.LOG directly, that won't work. You need to ZIP it first.

KB941569 is sort of a cumulative update in that it contains different versions of the same binaries. SP3 obviously doesn't contain the WMP11 versions. I don't know. It could be that the file isn't 100% compatible with SP3, or that modifype needs to be run on it. Do you have the same problem when updating XPSP3 using HFSLIP 1.7.6rc7?

What I meant was to change the extension to *.msi and have it handled by HFSLIP. I didn't expect it to work by double-clicking it, but it may work with the switches that HFSLIP uses to install *.msi files.