Tomcat76

I should've checked your logs earlier because it's clear why MBSA is complaining. Please put MPSetup.exe and wmfdist.exe in the HF folder. HFSLIP won't copy over any version of wmvcore.dll from the KB923689 hotfix into SOURCESS\I386 for Windows 2000 if neither WMP9 nor wmfdist are detected in the HF folder. Also, what's rootsupd.exe? If it's the Roots Certificate Update from Microsoft you can put it in the HF folder as well.

It depends on what you mean by "integrate". IE7 can't be slipstreamed into Windows Server 2003; you'll get errors all over the place during Windows setup. The first two methods outlined on Handling of Windows Internet Explorer 7 work for Win2K3.

I wouldn't really call it a deviation of the naming convention. This hotfix was released before the current naming standard went into effect. I doubt this hotfix is really needed nowadays. As far as I know, it's only compatible with the Netscape 4 API which is no longer used by Mozilla. Opera kept using it for a while but they recently changed that.

I wouldn't worry about MBSA too much, though I must admit that KB923689 is an awful hotfix. It updates wmvcore.dll, but there are several versions contained in the package. A different one needs to be installed depending on the version of Windows Media Player, and if that isn't enough it also depends on the WMP codec level (whether wmfdist*.exe is installed or not). I just let HFSLIP check the source and what's in the HF folder and, based on that, do what the installation INF of the hotfix does. If that doesn't satisfy MBSA...

@jimmsta To me, that sounds like the issues that existed with the betas, RCs and the first final release (and maybe even the second) of IE7. Be sure to use the latest final release; Microsoft have silently re-released it a few times. Also, I hope you read the instructions on hfslip.org; you need at least the latest cumulative update and the latest shell32.dll hotfix. If rebooting didn't do it, it may be the other problem. Unfortunately I think there's no way around that (at least not a clean one).

To my knowledge, you can't use paths in SVCPACK.INF. I have never experimented with that. That would actually be cleaner. Change the %HFSLIP% variable so it points to your custom directory and then move all files that are installed from %HFSLIP% by HFSLIP.CMD into that folder. But it's more manual work. I have never used those so I can't really say what's causing the failure. Here are some possibilities:1) You need a reboot for the changes to take effect 2) There's a mini post-install (titled "Windows Update") taking place when you first log on after Windows setup has completed. Some of the things you inject into the registry may be overwritten by that.

Well... That could be difficult. You can achieve that by setting the same multiboot path twice but you need to make sure that files with identical names really are identical too. Also, when the second SOURCESS folder is made, you should move some files from the second SVCPACK folder into the first (or the other way around, depending on which way you want to go), but not all. The easiest way to find out which files should REMAIN in the folder they are in is checking SVCPACK.INF; the CATs as well as all files that are installed from the [setupHotfixesToRun] section should remain in the folder they exist in.

Removing "HFSLIPTotalSlipstream" didn't work or did other registry tweaks fail as well?

Yes. Using the default first GUI logon method for IE7 integration, all IE7 registry tweaks should take.

The QFECHECK hotfix is supported with the latest test release, but you must use the Windows XP version for Windows 2000. Reason: the XP hotfix required only a minimal change to the HFSLIP code (two characters) while the 2K hotfix needs more attention (it's very ugly). No errors show up during Windows 2000 installation and it's working too. Concerning your other question... I never knew SVCPACK.INF supports direct installation of compressed files. I can change the code a bit so that files with a *.EX_ extension are treated as if they were *.EXE files, but it may not work since EXE files are now installed from a CMD file.

So far so good. Using the latest HFSLIP test release and the correct set of updates, the HFSLIP install went smoothly. I didn't notice anything special yet and WU is clean as a wistle. MS announced that it would be just a regular Service Pack, as in "a collection of updates", and it appears it is just that.

msscp.dll should be in your SYSTEM32 folder. The version in the update is newer than the one from the WMP11 codecs package (wmfdist11.exe, part of WMP11).

I just didn't get around to coding the HFSVCPACK_SW and HFGUIRUNONCE switchers on the web pages yet. Will do that when I have the time...

It goes in HF. I'll update my lists today or tomorrow. All new hotfixes should be OK; I tested it last night with XP Pro. XPSP2 + WMP11: windowsmedia11-kb929399-x86-intl.exe XPSP2: WindowsXP-KB929338-x86-ENU.exe ALL: Malicious Software Tool

Do you mind sharing the links? I only have these: Windows Server 2003 Service Packs Windows Server 2003 Service Pack 2 (32-bit x86) Release Candidate HFSLIP 1.4.0 and up support the RC.

You don't get it... I know how the silent/switchless installers are composed. I wrote the Silent .NET Maker script. The silent installers you will find are made like this: 1) Extract package 2) Create silent installer that runs the main exe in the extracted package with a silent switch *OR* 1) Create administrative installation 2) Create silent installer that runs the main MSI file in the extracted package with a silent switch Neither package brings up a usable file for HFSLIP. I need something like the INF file that installs .NET 1.0 on WinXP MCE. What I tried some time ago was exporting the registry changes after a manual installation of .NET 1.1 and .NET 2.0. I'm exaggerating here but it seemed like .NET took up half of the registry. Plus, some stuff is localized. This would require the user to have .NET x.x installed so I could export the correct settings from their machine from a batch. Also, like this, you are never sure that you covered everything. Either way, if this would ever turn out to be useful, I won't implement it into HFSLIP directly because it would more than double its current size.

OK. The problem with that hotfix is that it's a Type 2 hotfix but HFSLIP thinks it's a Type 1 hotfix. If you rename the file so that the word "windows" is no longer in it, it will be treated as a Type 2 hotfix. However, this will only take care of slipstreaming wmpns.dll and wmpns.jar. I see that the installation INF file contains a post-install command which may need to be executed. If that's the case, I'll have to hard-code support for this update. But rename the update and try it like that.

Are you sure about that number? The KB article gives this description: "When you upgrade to Outlook 2003 from an earlier version of Microsoft Outlook, your international options settings are not retained." And there is no downloadable file to fix this. They just provide some manual steps that they call a "workaround". Nothing about WMP9...

The problem remains the same. There's no file that clearly states what needs to be added into the registry and which files need to be run post-installation.

This may be impossible. I can make the INF file in UNICODE for non-English languages (will require quite a bit of extra code), but I'm afraid UNICODE won't do it for Russian. I think it needs to be UTF-8 and I don't know how to create a file in that encoding with a batch file. I'll try to make an HFSLIP version that creates a UNICODE HFSLIPPF.INF for non-English languages and then you can test if it works or not. This will be in a few days. If it doesn't work... you're out of luck.

That's a Windows problem. The old danim.dll should be registered but the new one should not. The registration is done by Windows setup and can't be stopped (at least not without hacking).

With "DRVINDEX.INF CORRUPTION" I was referring to HFSLIP leaving behind a near-empty DRVINDEX.INF in a specific situation. The error you see is something else and can't be avoided.

KB932590 updates msvcrt.dll whereas KB931836 updates the registry. KB932590 appears to be supported, btw. I don't see anything unusual about it that requires special atttention.

If you applied the update via Windows Update or Microsoft Update you should be able to find the link in C:\WINDOWS\WindowsUpdate.log. I tried this some time ago but gave up on it because I was starting to go insane, haha.Copying files is not an issue; it's more what goes in the registry and what commands should be run post-installation.

HFGUIRUNONCE or HFSVCPACK. Doesn't matter...