Inki

Thank you for your comments. I greatly appreciate your rapid feed back. I am still baffled by the time stamps, because I have usually checked my installation by doing spot checks of both version numbers and time stamps against those given for the updates, if I remember correctly. I may be gravely mistaken, but either HFSLIP or Windows changing the modification time stamps during installation seems weird to me. I'll take your word for it, though. IE6SP1 is very much present even without the cabs, because it comes with USP5.1, and I saw it in action when using WU. I will certainly continue to check my HF population, which may be a bit superfluous, but has never really created major problems before. If you are referring to updates being present for both MP6 and MP9, that is intentional and experimental, (and the experiment also covers logagent.ex_ in replacements). P.S. And my apologies for the messy HF population. Deep inside I knew that I really should have a clean presentable version in addition to the collection of obscurities that I have been working with. Still, I decided to post it as it is, just in case it might reveal something else useful. P.P.S. I thought I might as well air some thoughts on MP6 vs. MP9: As far as I can tell, W2k comes natively with MP6, and I am not aware of any method to totally eradicate it. Some MP6 files remain even if one installs MP9, and MP6 actually remains operational. Therefore, my thinking is that it makes sense to keep those MP6 files also updated as far as possible, and I think WU also would suggest so. As far as I can tell, MP6 and MP9 hotfixes mostly are not even overlapping or conflicting, so it seems reasonable to apply them both in an attempt to simulate a situation where one would have MP9 installed on top of a fully patched MP6. In one case, however, the udates in MS08-076 for MP6 and MP9 do conflict. Both contain the file logagent.exe so that the MP6 version has a lower version number but a later date, causing it to be selected by HFSLIP, which is why I have the MP9 version of the file in the replacements folder. An alternative experiment would be to only include the MP9 hotfix from MS08-076, and to replace the MP6 hotfix with just the file streamdll.dll, the only one that would not be overwritten by MP9. I am sure that this all appears very nutty, but it is just some light-hearted experimentation, not to be taken too seriously. P.P.P.S. This might not be relevant at all, but I thought I'd just bring up two previous cases, where I have had issues with USP5.1, that were resolved, just in case it might be helpful: - Possibly two file copying issues with W2k SP4 patches, concerning MS07-057 and MS06-057 - Possible peculiarity relating to driver integration, using HFSLIP 1.7.3 with W2kSP4 and USP5.1

After patch Tuesday this June, I used the June 6 beta version of HFSLIP to make a new installation disk with W2k + USP5.1 + WMP9 + a whole lot of HF's. I found two strange things: 1. Modification time stamps on updated files in the system after installation appear to have come from the time HFSLIP packed them into ??_-cabinets, rather than the true modification date of the file in question. The time stamp of the actual files inside the cabinets in sourcess and on the installation disk appears to be correct, however. This seems to affect all updates, based on examining some random samples. 2. Files from the latest IE6SP1 cumulative update were installed, but the update was not recognized by MBSA or WU. Installing it then via WU was successful in the sense that the update was then properly recognized. However, the files with incorrect time stamps remain. No problems were immediately apparent with any other updates. I have never seen this behaviour before and have no idea what is going on with the time stamps. I am half expecting that I have done something silly, and would appreciate any suggestions as to what that could be. HFSLIP.zip

FYI, everything appeared to go smoothly, when I used the latest (20090107) script to create a passive, merged installer for .NET 1.1 and 2.0 SP1 + all hotfixes, and then applied that at T-13 with HFSLIP to create a fresh Windows 2000 installation.

I have not yet tried the installers with HFSLIP. However, I have noticed, that Tomcat76 used the utility msistub.exe, apparently to make it work with HFSLIP and Win2k, at least at some point, and this quote is from his original readme: Now I see, that the synthesized script does not refer to this utility, as Tomcat76's original script does, nor is the utility included.So, I wonder if it might be correct to assume, that the script would not work with HFSLIP on Win2k, or does it include some other method to achieve the same result?

Thank you for this new script with support for NDP20SP1-KB947748. I appreciate it very much. Also, my thanks and appreciation to Tomcat76 for the original script. My first impression is, that the new script works perfectly with windows 2000. I used the non-loud version to prepare a merged installer for .NET 1.1 and 2.0 SP1 and all the associated hotfixes. Although I have not yet had the opportunity to use the installer with HFSLIP to perform a complete fresh system installation, I did try it out on an already existing installation: I first fully uninstalled all .NET software and then re-installed it using the installer. Both MBSA and Windows Update were happy with the result, and I saw no issue with the installer.

Thank you for this suggestion. One reason why I may not have thought about it myself is, that, if I recall correctly, .NET 3.0 and above have WinXP as a requirement.Also, on the face of it, I would have assumed that it would not be that simple, because the reason that Win2k needs the MS08-052 hotfixes for .NET is that there are specific gdiplus.dll files for .NET 1.1 and .NET 2.0 in their own specific subfolders, while WinXP makes use a single instance of gdiplus.dll. Thus I would have assumed that .NET 3.5 SP1 (and 2.0 SP2) might be a bit problematic with Win2k. Anyway, it would mean, that I would have to prepare the installer on an XP machine to be able to work with .NET 3.5 SP1. No problem with that per se. I will have to examine this thread more closely to see what it says about using only the 2.0 SP2 portion of .NET 3.5 SP1. If you would happen to have at your fingertips any comments about how readily feasible that is, or if there is anything in particular, that should be taken into consideration, I would greatly appreciate it.

<Emptied due to an accidental double posting>

I have a couple of computers running Win2k, and I have been using this excellent script to create a combined installer for 1.1 (with SP1 and other fixes) and 2.0SP1, which I then use with HFSLIP. All is fine, but I still have to manually apply NDP20SP1-KB947748-x86.exe (2.0SP1 version of NDP1.1SP1-KB947742-x86.exe, MS08-052) to have the latest gdiplus.dll put in place also for 2.0SP1, so that I can keep Windows Update and MBSA content. I understand, that when Tomcat made the original script, there were no updates for 2.0SP1, so he used an assumed naming convention for what support was built for them, and the script does not anticipate any updates beginning with a name such as NDP20SP1*. Also, from looking at the script I see that KB947742 has a specific hardcoded extraction command under 1.1, and a similar one might need to be adopted for KB947748 under 2.0SP1. However, I have not looked at the issue any deeper than that. So, I wonder if there might be any interest among those, who better know how things like this should be done, to see if KB947748 support could easily be added for 2.0SP1. If the interest is limited, I would appreciate a tip or two just in case I might feel bold enough to experiment on my own (never done scripts like this).

Thank you very much for the new test version, which I thought came up pretty fast. I noted that you were able to generate four change log items from this thread. After a brief test run it appears to me that everything has been perfectly addressed! The one and only, essentially cosmetic thing, which I noticed, and almost hesitate to mention, but I thought that you might like to know, is a small difference in HFSLIP.LOG content: USP5.1 slipstreamed by HFSLIP produces: OS in SOURCESS - Windows 2000 Professional SP4 English [service Pack Slipstreamed by HFSLIP] USP5.1 slipstreamed beforehand produces: OS in SOURCESS - Windows 2000 Professional SP4 (USP5.x) English I greatly appreciate your continued support for the USP.

Certainly, here you are. Just a few comments concerning the list of fixes in case you wonder: It does contain a few old and obscure hotfixes, some of which have been renamed for the benefit of HFSLIP. It is a work in process in the sense I have yet to re-examine the need for all those old fixes, and to otherwise update the structure to reflect the latest changes in HFSLIP, such as not requiring separate DX9 cabs. One thing which strikes me, is that HFSLIP.LOG mentions SP5. This may be OK depending on what is meant by it, but strictly speaking USP5.1 is still only SP4 with updates. Not at all knowing how HFSLIP really works, I could maybe foolishly speculate that SP4.CAB is not integrated into DRIVER.CAB because HFSLIP expects to find the non-existing SP5.CAB? UPDATED: You probably know this, but just to be on the safe side I could further clarify, that although USP5.1 does not replace SP4.CAB with SP5.CAB, it does create CDROMSP5.TST, which contains the version number of the USP. It does not remove CDROMSP4.TST, and both .TST files exist. And by the way, I tested to make certain that removing everything but W2KSP51.EXE from the HF-folder does not change the outcome concerning SP4.CAB. While I am at it, I could also point out another feature of HFSLIP which has existed as far as I can tell: When I use HFSLIP to slipstream USP5.1, I am offered the option of removing unnecessary .CAT files, which is nice. However, if I allow USP5.1 to slipstream itself into the source before using HFSLIP, I am not offered this same option. Actually, right after asking about making a multiboot CD, HFSLIP went directly to work, and during that transition there may have very briefly flashed on the screen some kind of warning or comment concerning finding something with SVCPACK or something similar in its name. UPDATE 2: I experimented by making a copy of SP4.CAB (as modified by USP5.1) and placing it in SOURCE\I386 with the new name SP5.CAB (I also included an equally renamed copy of SP4.CAT just to be sure). After that, I ran HFSLIP with option A for driver compression (in my normal configuration, having HFSLIP slipstream the USP). Indeed, during the processing I could observe SP5.CAB being extracted. Finally, in this case neither SP4.CAB or SP5.CAB was no longer present in the output by HFSLIP, and the individual driver files mentioned in the first post could now be found in DRIVER.CAB. HFSLIPLOG.ZIP

First of all, my appreciation for this project. Using HFSLIP with Windows 2000 SP4 and USP 5.1, I have noticed a peculiarity, which I am at a loss to figure out. I have noticed it with several HFSLIP versions including the latest, but I am certain that it has not always been there. No problems arise if I use option D for driver compression. However, if I select option A, the windows installation process is unable to find the following files: faxdrv.dll, hid.dll, mf.sys, parallel.sys, parport.sys, sonydcam.sys, and mouclass.sys. (At one point I even thought that this might be a CD read/write error as I don't use a virtual setup, but I think that I have ruled that out by trying different media and noting that the problem files are always the same and I can manually find them.) In both cases these files are found inside SP4.CAB, which is identical whether I select A or D. (Still, it is different from the original SP4 disk, and I quess it is modified by USP5.1.) I wonder if this somehow relates to the fact that my original source disk is SP4, and could it be that under option A the installation process somehow misses looking into SP4.CAB when SPX.CAB is not there?

OK, Thanks for the heads up and the replacement pointers. It is always a joy to be able to replace and get rid of some old stuff, and I have had the feeling for some time that I should re-examine this lot. Still, it is a major pain to do so and requires the right set of mind and enough energy, maybe even dark and dreary wintery days. I am by no means a software expert, rather a mix between physicist and business strategist, a home user in the true sense, and my forays into this world tend to be sporadic and short-lived. I appreciate and collect all the pointers I get and will make good use of them, so thanks again. Oh, and a belated thanks also to fdv for his valuable expert insights, which I unfortunately missed until looking up this thread again. Still I am not really a creature of detailed devotion , rather this is for me more like getting an urge once a year to solve a crossword puzzle.

Hi, Blizz, I have just recently been to this forum after not looking at it for half a year. I could not help noticing your topic, since I have had a roughly similar kind of interest. I do not know if you are still following this thread, but if you are, I thought that I might just as well do a little mischief by pointing you to an old topic of mine, which I just looked up myself: Obscure and non-critical fixes to W2k + USP51 (hope I got that topic link right, never tried one before). But do not take it too seriously, or it might cause an enormous waste of time and a major headache. I guarantee nothing that is in it. And please do not ask about it, because I have not really bothered about the question since, and I remember less than what is written in the thread. Also, Tomcat76 gave some additional information on the workings of HFSLIP in this thread, which probably may be quite relevant for some of those old fixes.

Excellent! 1.7.0rc1 seems to have cleared away my IE6-related troubles. And thank you for the additional information that you have given. I will keep it in mind the next time I gather enough energy to give my HFSLIP setup a thorough examination.

Thank you very much for your reply. I greatly appreciate your support for this USP by Gurglemeyer, especially since I imagine that it may not be widely used. (A good indication of this is if the IE6 level setting issue has not surfaced previously as I first noticed some symptoms more than half a year ago but dismissed it then as a temporary quirk. Sorry, by the way, for not raising the issue earlier.) Also, many thanks for your comments on my update list. The mutual interaction of different MDAC versions is something that I have never been too sure about. The USP does not include MDAC 2.8 SP1, which is included in HF as MDAC_TYP.EXE. When working manually I have usually first updated MDAC 2.5 SP3 and then installled and updated MDAC 2.8 SP1, noting that the first update may be redundant. This approach has apparently been carried over into my HFSLIP setup with the idea: "put them all in and let HFSLIP sort it out", which I realize may be incorrect. I will act on your recommendation and remove the update for MDAC 2.5 SP3. Concerning the contents of the USP (to the benefit of anybody who may be interested): I once made the effort of checking the file versions included in the USP against various updates, and the content of the posted log file represents my best understanding of what is and is not included in this specific version of it. I have duplicated one update from the USP in the HF folder: MS06-015 / 908531, because although its files were included, for some reason the update did not seem to install properly from the USP. Concerning the updates from "outside the list" (to the benefit of anybody who may be interested): I realise that these updates are not supported and I do have a "let's see if anything bad happens" attitude towards them. They are based on what early updates I have been able to find that have been missed by the USP (or left out deliberately, although I doubt it). Interestingly enough, some of these early updates have updated file versions, which have not been included in later updates. Of course, changes in some other files may have made these updates redundant. I have no idea, but it satisfies my sense of perfection to try to have a "completely updated" installation. Once, maybe roughly a year ago, I posted on this forum a more complete description of these updates just to see if anybody might be interested in making comments on them. However, during the couple of days that I followed the thread, I only saw one reply, which I found a bit discouraging, because it seemed to totally miss my point. I then decided in favor of some completely different interests and am sorry to say, that if there were any relevant comments later on, I unfortunately missed them and failed to reply.

Well, I did some experiments and found out the following: First, I placed all the relevant IE6 cabs into HFCABS. As a result, HFSLIP apparently recognized IE6 and the issues with MS06-057 and MS07-057 vanished. Instead, MBSA reported 5 new missing updates: 02-050, 03-023, 05-013, 05-044, 06-023, plus the post SP4 Rollup, all of which are included in the USP. Second, I also placed the post SP4 Rollup into HF. As a result, at first I was unable to install MBSA, because "installer services are unavailable or improperly installed" or something like that. So I installed Installer 3.1(v2) manually (it is included in the USP). MBSA then reported 7 missing updates: 05-026, 05-040, 05-042, 05-043, 05-044, 05-049, and 06-023, all of which are included in the USP. My impression is that this route looks a bit messy, and going along it might undo an unknown number of updates included in Gurglemeyer's USP that might not even be revealed by MBSA or WU. Might there be any way of letting HFSLIP know that the basic IE6 is taken care of by the USP, and that it should not worry about it?

Certainly, I can attempt it, let's see if it will appear here somewhere... At least it will demonstrate that I am still in the process of figuring out what works and what does not. Great tool, by the way. Actually your guess is certainly very accurate in the sense that I don't have any IE6 cabs in my HFSLIP setup, because I am using Gurglemeyer's USP-5.1.2195.24 as a base and as a source for IE6. It sounds then as if this might not be detected as an IE6 installation because of that. Edited addition: Perhaps I should place some IE6 cab into HFCABS just as an indication for HFSLIP that IE6 is involved, although it is already included in the USP? Furthermore: I do have some old and obscure patches included (my version of W2k "fully patched" backwards in time as far as possible), with some of them having been renamed to work with HFSLIP, and probably not all very useful. However, they are unlikely to impact this issue, as I get the very same result when using only MS07-057 with the USP. HFSLIPLOG.ZIP

Hi, I may be mistaken, but it appears that HFSLIP 1.6.5 does not copy all the relevant files from the October cumulative patch for IE6 SP1 on W2K SP4 (MS07-057/KB939653). Also, I have noticed that MBSA (Microsoft Baseline Security Analyzer 2.0.1) seems to frown at the file comctl32.dll (5.81.3900.7109), which HFSLIP copies into W2K SP4 from MS06-057/KB923191. It seems that MBSA would be more pleased with comctl32.dll (5.81.4968.2500), which is located in the xpsp2_binarydrop subfolder within the same patch file. I certainly have no idea which file version would be better or more correct. Anyways, it is easy enough to silence MBSA by placing the latter file (compressed it into comctl32.dl_) in the HFSLIP\FIX folder. Hope that this information is useful- or at least not too wildly out of core context

I have been looking at creating a Windows 2000 installation CD with completely patched OS and IE6SP1, based on Gurgelmeyer's Unofficial Service Pack 5.1 with IE6SP1 and a large number of hotfixes (I actually use 5.1.2195.24). The main thing here is that there are some old/obscure fixes to IESP1, which even Gurgelmeyer has missed, but which I have found to be available on MDGx's fine site and I hope to incorporate on my installation CD. I realize, that it is wholly unreasonable to assume that HFSLIP should support any old hotfix that one could find somewhere, and this is not what I am after here. Rather, I have tried to see how far I could get along these lines, not really knowing what might be expected to work. Well, this is how far I got, not being an expert in Windows, and if you have any comment on it, I would be grateful. If you have information on how to better handle some of the updates below, I would greatly appreciate it. If you feel that my thinking has been totally along wrong lines somewhere, I would especially love to hear about that. By the way, comparing against Tomcat76's dynamic hotfix list (as of March 1), it appears to me that USP 5.1.2195.21 contains IE update 905495 and OS updates from W2KSP4 to 908531 (not 904706) plus 912919, 893803 and 911564, and USP 5.1.2195.24 appears to additionally include 832414, 913580, and 917344. I do not have precise information on the contents of USP5.1, but this is my hasty and unreliable observation based on file versions. From outside the list, it appears to me that USP 5.1.2195.21 contains at least 818043, 819745, 820608, 838989, 842773, 842933, 894395, and 896430, and USP 5.1.2195.24 additionally would appear to contain at least 885912, 897711, 898465, and 912916. In this post I only look at hotfixes, which do not appear on Tomcat76's list (as of March 1) and are not covered by USP 5.1.2195.24. I believe this would leave me with the old/obscure IE6SP1 updates and some newer non-critical OS updates as listed below. For the hotfixes below, I have indicated with a version number those update files, which, according to my best understanding, are of interest. Other files, which apparently are replaced by other hotfixes, I have mentioned without a version number. I have also used the following shorthand notations: [ms] Downloaded directly from Microsoft [2k] Downloaded second-hand from the W2k-page on MDGx's fine site [ie] Downloaded second-hand from the IE-page on MDGx's fine site {0} Type 1 hotfix, which I have renamed by adding a "Windows-" prefix {1} Type 1 hotfix {2} Type 2 hotfix HF Folder These hotfixes I place in the HF-folder. As far as I can tell, they seem to be OK (but what do I know): - KB139071: [2k] {0} Windows-2K139071.EXE (asycfilt.dll 2.40.4528.0, oleaut32.dll 2.40.4528.0, olepro32.dll 5.0.4528.0, stdole2.tlb 2.40.4528.0) - KB322656: [ie] {2} Q322656.EXE (ieinfo5.ocx 5.50.4918.1900, msrating.dll) - KB816362: [ie] {2} Q816362.EXE (mshta.exe 6.0.2800.1182) - KB824220: [ie] {2} Q824220.EXE (imgutil.dll 6.0.2800.1236) - KB824463: [ms] {1} ie6.sp1-kb885258-windows-2000-xp-x86-enu.exe (proctexe.ocx 6.3.2800.1471, dxtmsft.dll, dxtrans.dll) - KB830460: [2k] {0} Windows-Q830460.EXE (msvcirt.dll 6.1.9845.0) - KB830849: [ie] {2} Q830849.EXE (inetcpl.cpl 6.0.2800.1413, shdocvw.dll) - KB838751: [2k] {0} Windows-Q838751.EXE (msvcrt.dll 6.1.9847.0) - KB893627: [ie] {0} Windows-XP893627.EXE (iedkcs32.dll 16.0.2800.1500) - KB900732: [ie] {0} Windows-Q900732.EXE (ieakeng.dll 6.0.2800.1510) - KB911589: [2k] {0} Windows-Q911589.EXE (proquota.exe 5.0.2195.7090) - KB922667: [2k] {0} Windows-2K922667.EXE (large number of files) - KB924432: [ms] {1} Windows2000-KB924432-x86-ENU.EXE (ole32.dll 5.0.2195.7103, rpcrt4.dll 5.0.2195.7085, rpcss.dll 5.0.2195.7116) - KB924867: [ms] {1} Windows2000-KB924867-x86-ENU.EXE (kernel32.dll 5.0.2195.7111, mpr.dll 5.0.2195.6824) (looks almost like a "-v2-" for KB917422/MS06-051) Oh, and by the way, at least one of the above hotfixes, but I don't recall which (and don't now have the patience to re-check all the KB-articles), requires an additional registry tweak to be fully activated, but this is described in the corresponding KB-article. FIX Folder With these hotfixes, I first extract the files of interest, then re-compress them into .??_ files with Makecab.exe /D CompressionType=LZX /D Compressionmemory=21, and finally place them in the FIX folder: - KB327922: [ie] IEAudioUpdate.exe (Note 1) (start.wav) => start.wa_ - KB834158: [ie] {2} IE834158.EXE with additional fix from: [ie] SHDOCFIX.ZIP (Note 2) (shdoclc.dll 6.0.2800.1443, mshtml.dll) => shdoclc.dl__ - KB896156: [ie] {0} Windows-Q896156.EXE (Note 3) (mshtmled.dll 6.0.2800.1502) => mshtmled.dl_ (Note 1) I believe HFSLIP could also handle this as a type 2 hotfix, but since it is a straightforward case of file substitution, I chose to do it this way. I am not sure if it is really needed, but it certainly is harmless. (Note 2) After extracting shdoclc.dll, I apply the patch from SHDOCFIX.ZIP and readjust the checksum with modifype.exe -c before continuing with recompression. I am working under the assumption that this would be enough and there would be no need for the actual hotfix file. Still, I guess there would be no harm from also having the hotfix file in the HF folder. (Note 3) From what I can judge, this is a structurally complex and non-standard hotfix, that is designed to generate different file versions for different systems, and is not supported by HFSLIP. So I first apply it manually to my system and grab hold of the resulting mshtmled.dll file for re-compression and inclusion in the FIX folder. I suspect (but am not 100% certain) that this might be enough and nothing else from the hotfix file would be needed. If this turns out not to be the case, I assume one would need to integrate it manually (/integrate:<location>) into the SOURCESS folder at the end. Maybe I just have not the found the right piece of instructions or documentation yet, but I wonder if HFSLIP has a mechanism for integrating, rather than slipstreaming, an unsupported, user-specified hotfix so that one would not need to forego automatic iso-creation in order to do it manually, if required. Mixed Feelings about unofficial updates I have also found two "unofficial" updates, which seemingly could be applied using either of the two methods above. Still, I feel unhappy about feeding unofficial updates to HFSLIP through the HF folder, and using the FIX folder just seems messy. Today I actually apply 886677 through FIX and 918144 through HF. - KB886677: [ie] {2} Q886677.EXE unofficial (not 100% sure it is really needed) (mlang.dll 6.0.2800.1599) - KB918144: [ie] {2} Q918144.EXE unofficial (Jet 4.0 update, 9 files) I wonder, if it would make sense or be possible for HFSLIP to apply the XP2 / Server2003 versions of these hotfixes to W2k. (as in the case for QFECheck or the recent timezone update). Still, I guess this might require specific support, and it is probably not that essential as the FIX folder also seems to do the trick, even if one does not want to use unofficial updates.

OK. Thank you very much for your additional comments. I greatly appreciate the fact that you have found the the time to look into this, which must really be on the sidelines of your project.

Well, having renamed the hotfix file - from: Windowsmedia9-kb817885-x86-enu.exe - to: Wmedia9-kb817885-x86-enu.exe HFSLIP now slipstreams the updated files nicely into the installation source. Because the basic setup package for Windows Media Player 9 (MPSetup.exe) includes older versions of the updated files, I may boldly/naïvely assume that any post-install requirements that they may have are likely taken care of by including the installation of MP9 later in the installation sequence. Therefore, my best guess is that the only real problem with this hotfix is its problematic naming, both in terms of deviating from the assumed type convention and its KB article number (making it more difficult to find).

OK. Thank you very much your answer and advice. I had actually thought that it might be a question of naming-based type recognition, but I was uncertain of the actual criteria. As I don't really use Netscape, which this hotfix supports, nor am I a Windows expert, I will probably not be able to comment on the proper functioning of the update and the post-installation commands. Still, maybe some knowledgeable Netscape user out there may have a practical interest in this case.... (Funny by the way, but I can not help wondering if there is a link between the typo in numbering and the fact that the hotfix supports Netscape, but maybe that is being too cynical)

Yes, it seems that there is indeed a numbers mixup. For some reason: - the number on the Hotfix file is 817885 as given in the first posting. - the number on the KB article is in fact 817855. Silly of me not to notice this straight away. (I edited the correct KB number also into the first post.)

I attempted to slipstream KB817855 into Windows 2000 by placing: Windowsmedia9-kb817885-x86-enu.exe in the HF-folder While running HFSLIP 1.4.1, KB817855 flashed up it's own notification complaining about bad switches. Can you tell me: 1. Is this hotfix supported and does it make sense to try to slipstream it in the first place? 2. Is there some obvious thing that I have missed here? Sorry, if my question is trivial, but I am just learning what HFSLIP can do, and I have not found an answer to this elsewhere. (P.S. Note the different numbers for the KB article and the hotfix file, look like a MS typo in one or the other)

Thank you for your information on KB832414. The question I had in mind but failed to spell out is: Since W2k contains MSXML 2.5/msxml.dll by default, is it better to - leave it as it is, or - upgrade it to the latest version 8.0.7002 with KB832414? My uninformed guess is that with later versions of MSXML (2.6/msxml2.dll, 3.0/msxml3.dll, etc.) installed it probably does not matter very much. Like erpdude8 said above, later versions fix problems with 2.5, and I guess they take care of most of the business anyway. (I do have them on my system.) Still, based on what I have understood I would choose to also upgrade the msxml.dll file, because: - New versions of MSXML after 2.5 do not replace files for older versions, there may be some parallel functioning (?) - One would (naïvely, perhaps) expect the newer msxml.dll file to be less buggy, just in case if it might be used. - Microsoft in its grand wisdom has decided to include the upgraded msxml.dll file in XPSP2 and 2003SP1. - It satisfies my personal desire for completeness . So you can also read my post as a humble between-the-lines suggestion that maybe there might be a case for including KB832414 for MSXML 2.5 in the Unofficial Service Pack. Of course, this might be a bad idea, but I would not know, as my reasoning is no better informed than what you can read above .