Tomcat76

This shouldn't be too hard. The .mfl file is misplaced (it can be dealt with without hardcoding) and some processes need to be run post-installation (hopefully they work at T-13). I'll check it out.

HFSLIP copies over the ASMS folder from hotfixes.

There's always the possibility that one or more hotfixes are incompatible with WINNT.SIF, just like you can no longer use the branding options if you slipstream IE7 into XP 32-bit. Well... That's about all I can say on WINNT.SIF. I'm sorry.

To my knowledge, not all files exist loose in the I386 folder as well... like some DirectX binaries.

I'm also renaming folders during tests but have never experienced that. Do you mind using the new test release (80327a) and trying to duplicate the problem again?

The only thing that looks suspicious to me is the AutomaticUpdates variable. What happens if you comment it out?

I don't know much about WINNT.SIF myself, but you can always attach it here if you like (after blanking out sensitive data). Maybe there is something that catches my eye. BTW... The INSTALLRC variable has no effect as HFSLIP64 doesn't have code that handles installation of the Recovery Console. See the default HFANSWER.INI that's linked from the first post in this thread for a list of variables that you can predefine.

I never had the problem you're just mentioning and I'm also using VMware 6.0. Make sure you got the latest plugins (if you're using any). Did you see any error messages during Windows setup? Does C:\WINDOWS\setuperr.log show anything post installation?

None that I can see. It was just "more stubborn" compared to XP

This info has been on the HFSLIP site for a very long time. Look for info on the HFEXPERT subfolder on http://hfslip.org/advanced.html, more specifically the HFEXPERT\DRIVERCAB and HFEXPERT\SPXCAB subfolders.

OK. This release (80322b) should be OK to work with. Server 2003 is quite a PITB... I have tested both Windows Update and Microsoft Update with XP SP2 and Server 2003 SP2 and everything comes out clean (considering what's supported). The real bug hunting can begin...

I think I've found the problem with Windows Update. For some reason, the registration of SysWOW64\wuweb.dll from AU.INF is failing. I'm going to hardcode it in HFSLIPOC.INF.

Which software is installing that? Microsoft Update still offers version 1.7.18.7...

Oh yeah... Is that an original source or was it patched before? I'm only asking because of the "INFO" message in HFSLIP.LOG. Also, have you tried without WINNT.SIF and CMDOW.EXE?

Yeah, I'd like a screenshot. I don't know why exactly, but my problem with Microsoft Update seems to be fixed. XP x64 + updates shown in first post == MU doesn't work after first GUI logon XP x64 + updates shown in first post + time zone plugin == MU doesn't work after first GUI logon XP x64 + updates shown in first post + time zone plugin + SWFLASH plugin + no GDIDetectionTool edit == MU works I have tried twice (full format and reinstall) with the latest setup and everything works for me now. Don't know what triggered it.

I'm getting the problem with Microsoft Update too, but haven't been able to find out why yet. It could be because I'm not nuking AU.INF as with HFSLIP for 32-bit Windowses. In the mean time, though, you can get around it by logging off and logging back in. That does the trick for me. I suppose you mean "Programs" folder. I have it, using both the standard and the classic Start Menu.

I guess that's new in the new fileset. They weren't "OFFed" in the filesets from May and December 2006. Thanks for mentioning this. The new test release (sticky thread) checks the full name of both files before setting the SFCFIX variable.

Try the latest test release. Please show me the HFSLIP.LOG if you still have the problem.

You actually can't test those because they're blocked. Try with the list shown in the first post. You can maybe do a run with files in the HFSVCPACK folders too. Are there any hotfixes in your list that aren't mentioned in the first post?

It's already in the first post.

Oops... The script wasn't copying subdirectories of REPLACE. Should be fixed now.

The SOURCESS folder is normally deleted automatically the next time you run HFSLIP. But in your case I suggest to start out with a clean folder structure (remove the SOURCESS folder, remove the content of the SOURCE folder and copy your CD into the SOURCE folder). Either slipstream the service pack manually or let HFSLIP do it.

I just tested it again in a blank folder, and the HF, HFTOOLS and SOURCE folders are created automatically on first run. BTW... The first beta is out.

It's your call... The script is capable of slipstreaming SP2. But it's no longer important; 80316c should fix the problem with new 32-bit binaries.

OK, thanks. Just an FYI... Please slipstream SP2 because there are still problems with how completely new 32-bit binaries are handled (Windows setup is only instructed to copy them into the correct location, and not yet to rename them from "wfilename.ext" to "filename.ext"). I hope I'll find a solution for this that is both clean and works quick.