Tomalak

Hello Tomcat76, can we do something to help you analyze this strange update? Just in case you have not enough work and want to provide new test versions... My findings (for the English update, Windows XP version): I removed the "amd64" directory as I have an i386 processor. All 7 files in the "i386" directory are binary identical to those one directory level up. So I removed this directory too and changed the references in 'msxpsdrv.inf' to use the files in the root directory (two lines, replacing "= 2" by "= 1"). After that running 'update.exe' in the "update" directory worked flawlessly, and the KB934238 was installed without problems (i.e. WU and MU didn't report the optional update as still missing). This way the installation directory looks like all other updates: some files in the root directory, and some elements in the "update" directory. Sorry if this view sounds plain stupid or naive, but I don't have a clue how these MS installers work and what you do within hfslip to process them. I don't even understand your sentence with the "two installations" taking place. Any chance to add support for this update with further help from the community here? Tackling the language packs later on should not be too difficult (I hope). The German version for example just contains a few replacement files (and an additional .mui file) in the root directory, and an appropriate installer in the "update" directory. No confusing and needless "i386" or "amd64" directories here... Thanks and keep up your great work! Tomalak

As promised here's a full list of all KB934238 related downloads Microsoft currently provides. The English "base pack" always has to be installed, and then if necessary the appropriate language pack on top. Update for Windows XP and Windows Server 2003 XPS Shared Components Pack English (United States) Languagepack Arabic (Saudi Arabia) Languagepack Czech (Czech Republic) Languagepack Danish (Denmark) Languagepack German (Germany) Languagepack Greek (Greece) Languagepack Spanish (Spain) Languagepack Finnish (Finland) Languagepack French (France) Languagepack Hebrew (Israel) Languagepack Hungarian (Hungary) Languagepack Italian (Italy) Languagepack Japanese (Japan) Languagepack Korean (Korea) Languagepack Norwegian (Norway) Languagepack Dutch (Netherlands) Languagepack Polish (Poland) Languagepack Portuguese (Brazil) Languagepack Portuguese (Portugal) Languagepack Russian (Russia) Languagepack Swedish (Sweden) Languagepack Turkish (Turkey) Languagepack Chinese (People's Republic of China) Languagepack Chinese (Taiwan) Update for Windows XP x64 Edition and Windows Server 2003 x64 Edition XPS Shared Components Pack English (United States) Languagepack German (Germany) Languagepack Spanish (Spain) Languagepack French (France) Languagepack Italian (Italy) Languagepack Japanese (Japan) Languagepack Korean (Korea) Languagepack Portuguese (Brazil) Languagepack Russian (Russia) Languagepack Chinese (People's Republic of China) Languagepack Chinese (Taiwan) Kind regards, Tomalak [Edit 2007/06/19: duplicate links consolidated]

Here you go: http://www.download.windowsupdate.com/msdo...17194a1e384.exe I'm preparing a post with a full list of links (versions for Windows XP, Windows XP x64, Windows Server 2003 and Windows Server 2003 x64 plus all available language packs). Kind regards, Tomalak

Err, I can't find a download for that ID, so I don't understand which "ActiveX Compatibility" setting you mentioned. I just saw the update on both KB articles and I couldn't find 890046 in your list, so I thought it might probably been missing. If installation/slipstreaming of IE7 (no updates for IE5 or IE6, I'm using Win XP SP2 Pro) is enough and hfslip deals with this, there's no problem at all. I don't know, didn't try an installation on a real PC for some time now, only in VMs. Not sure if it would show up there at all (the old update didn't do as far as I remember). Maybe someone else can contribute here although it might take a few days, it's a brand new update. Again, I only had a look on your list and recognized that the files in the new update completely replace the old update (which is in your interactive list). Regards, Tomalak

Hello Tomcat76 & the_guy, two issues with your update lists: 1. KB890046 (MS05-032) is probably missing: it just contains "agentdpv.dll" (version 2.0.0.3423), which supposedly has been replaced by version 2.0.0.3424 coming with KB920213 (MS06-068). However, both KB articles were updated on 05/08/2007 and now explicitly state that MS06-068 does not replace MS05-032, both patches should be installed. I'm not sure why (didn't read the full details in the bulletins), according to http://patch-info.de/artikel/2006/11/14/168 the update MS06-068 does not set a certain killbit, but MS05-032 does. I guess hfslip could deal with this directly, so indeed only the newer update might be necessary... Comments? 2. KB885626 (certain Intel processors in combination with old BIOS) has been replaced by KB936357 (KB article not yet available). Both contain "update.sys" (new version 5.1.2600.3124, old version 5.1.2600.2508). Kind regards, Tomalak

Hello all, is it possible to support the patch KB934238 (update for XPS printing component, reported as optional update by WU as I have installed .NET 3.0)? See details here: http://go.microsoft.com/fwlink/?LinkID=85688 The update can be downloaded in Microsofts WU catalog - either for English as a small package with only a few MB, or as an 94 MB download containing 23 different languages. The huge package (didn't look at the other one as I have a German Windows) consists of one generic English installer and a lot of associated language packs. One would only need one of these, I think. As these files do not follow a common naming standard (and have a different name for each language), hfslip will not take them out of the box. TC76, do you see any chance to deal with this? If you find a way (you're a genius, we all know) it would perhaps be better (as this is .NET 3.0 related problem) to offer that functionality in your silent .NET maker (http://www.msfn.org/board/index.php?showtopic=90779). Therefore only people using .NET 3.0 have to include this update and can do that by building new silent installers... Thank you so much, and keep up the good work! Kind regards, Tomalak

Hello all, although I'm integrating the patch KB920342 (update to PNRP version 2.0, put in folder "HF") it always appears on WU as not being installed. I'm using a german Win XP Pro SP2, last hfslip version it tried with is 1.5.0rc7. I do not have the logfile anymore, but if really necessary I can provide it in the next days (I've a lot of other optional updates, but nothing I'd consider as problematic). Has anyone experienced the same, or is the problem just with me? Thanks for help and comments, Tomalak

Ah! Just to or three of him? I always thought the "76" in his name denotes the number of clones he has (and which are currently all active working on hfslip at the same time)... Regards, Tomalak

Hello, just to clarify: no, my source does not contain the CAPICOM. I just stumpled upon this update on http://www.patch-info.de/winxp/ which (besides your list, TC76 ) also shows all updates necessary for an Win XP SP2 source. It contains a few more optional patches and is always up-to-date, explicitly stating the replaced hotfixes. Regarding MS07-028 the article mentions that installation is not necessary, but it advises to do so as it wouldn't hurt and would be a "precautionary step". So the author is wrong in recommending only the update instead of the full redist? Maybe I'll drop it completely from my next installation... Regards, Tomalak

Hello, I need this CAPICOm ActiveX control update: http://www.microsoft.com/downloads/details...c5-206df13af316 http://www.microsoft.com/technet/security/...n/MS07-028.mspx But it follows a strange naming convention. After decompressing the executable I get an .msi file. Is it correct just to put it into HF for the update to be integrated? Thanks! Regards, Tomalak

Hello all, before doing a long and tedious test myelf: has anyone already tried to integrate the new Windows Update Agent? http://download.windowsupdate.com/v7/windo...Agent30-x86.exe Any issues? I guess I could just replace the file for v2.0 and see if hfslip can cope with that, but perhaps someone already found this working flawlessly... Thanks! Regards, Commander Tomalak

Hello all, just wanted to inform you that a new version of the Adobe Flash Player is avaiable: http://www.adobe.com/shockwave/download/do...=ShockwaveFlash (offline installer) or, as usual: http://download.macromedia.com/pub/shockwa...ash/swflash.cab (for direct integration with hfslip) Kind regards, Tomalak

If you wanna do that automatically, and with often changing USB drives, just try USBDLM - it's a good remedy for all such problems: http://www.uwe-sieber.de/usbdlm_e.html Kind regards, Tomalak

Hello,sorry for the delay and for answering so late, and sorry for opening up a topic on KB888111 - there have indeed been some of these before, I just didn't search for them... Anyway, I tried to reproduce the problem today, and had to recognize that it apparently was my own fault. So I have to apologize once more. hfslip did everything correctly, the two files are present on the installation CD and they are listed in TXTSETUP.INF. The culprit is a configuration error in nLite (which I use to integrate the drivers into my installation CD), which then removed the USB audio drivers. Well, I guess no further action is necessary here, and this thread can be closed Kind regards, Tomalak

Hello, needing the UAA High Definition Audio class driver for my Windows installation I downloaded KB888111 and integrated it with hfslip (v. 1.4.1., Win XP Prof. SP2). According to the registry the patch was correctly slipstreamed, but I didn't have sound after installation and instead found an unknown device in the device manager. When trying to install the corresponding driver for it, I found at least the files "hdaudbus.inf" and "hdaudbus.sys" not being present in the system. They are part of the KB888111 update and reside in the 'commonfiles' sub directory but were apparently not installed. After manually extracting these files and using them for the driver installation, everything went fine and I had sound. Is it possible to update hfslip so it recognizes this patch and puts the all the necessary files into the appropriate folders of the Windows installation (namely "inf", "system32" and "system32\drivers")? Or is it really necessary to use the HFEXPERT feature for this? Thanks! Kind regards, Commander Tomalak

You will find all information here:http://www.microsoft.com/technet/windowsserver/sp2.mspx Regards, Tomalak

Of course, here it is:http://tinyurl.com/38s8ts Kind regards, Tomalak

Hello, just a quick question: I guess it's not necessary to download and include the new timezone update KB931836 (replaces both KB928388 und KB929120) as the appropriate changes will again be directly incorporated into hfslip, right? Maybe in one of the next test versions... http://support.microsoft.com/kb/931836/en-us http://www.microsoft.com/downloads/details...a9-ef9061a9a3ca Kind regards, Tomalak

Yeah, the official MS method is what I used in the end (nLite was my friend which relies on the OemPnPDriversPath entry). But of course a pure hfslip solution would be nicer... I'm not familiar with INF files, so no idea what especially the ATI driver's problem is. I've seen nothing in its INF file that would make this one file (ati2erec.dll) fail. But if you want I can send you the file next time I try to prepare an installation? Thanks for your all your support, Tomalak

Hello all, besides the necessary security updates I always include a lot of optional but recommended (by MS ;-)) updates. My last installs with them went really fine (except the drivers, see separate threads), there were no missing updates when visiting the Microsoft update website. Oh, stop, there is one, a really resistant one: KB920342 (update for PRNP). It does not work for me, I always have to install it manually afterwards. I'm not sure whether this is a side-effect of the other patches or not - if you think it's due to them, I can post a list of my updates of course. But the files contained in the update are independent from the other patches and I don't think this is just a slipstreaming interference. Can someone have a look at this and possibly confirm the problem? Maybe something in hfslip has to changed (as so often with strange MS executables), I used version 1.2.2 for my tests (Win XP SP2 Pro, German edition). TC76, any idea? Thank you very much! Tomalak

Hello all, after a first try a few weeks ago (with very little success) I now again tried to integrate driver files into my installation with hfslip. I used "daddydaves" useful Drivercabhelper (http://www.msfn.org/board/index.php?showtopic=89021) for this task. Just wanted to report the results 'cause I discovered some problems (that could maybe get resolved?). Will have a closer look at your suggestions before the next installation, but this may take a few weeks. Okay, here we go: Most of the drivers obviously were successfully packed into the driver.cab (TPM, Monitor, Audio, LAN, WLAN, Bluetooth, Modem) and used by Windows during installation. For some others I'm not sure (especially for the Intel chipset and the ACPI drivers of the notebook manufacturer) - I had not enough time to test whether the files provided by me were used or the default files coming with Windows. Will check this next time. Here I definitely experienced problems : Graphics card I used the files from the ATI catalyst mobility driver. During installation the file "ati2erec.dll" could not be found, so the graphics driver was not successfully installed. The strange thing is: this file was present in the ATI package, I put it into the DRIVERCAB directory, and it was in the recreated driver.cab - although installation failed, I could not convince the search dialogue that it was indeed there. For all other files no error messages appeared. I'm really at a loss here why this file could not be found, and why it was the only one. Anyone with similar experiences, using the ATI drivers? Mouse/Touchpad (called "Ultranav" bei Lenovo) Drivers for this (provided by Logitech) were present in DRIVERCAB, yet Windows used its own default drivers for the mouse and the touchpad. No idea what went wrong. Manually updating them worked after the Windows installation, drivers were definitely compatible. Again: anyone with the same difficulties or even a solution? PCMCIA I provided the files for the Texas Instruments CardBus Controller (PCI-1510) in DRIVERCAB. But after Windows installation the driver seemed to be the default version provided by Microsoft. The odd thing is that the files of the driver as provided by Lenovo only consist of an .inf and a .cat file (not a .sys or anything like that). I could use them to "update" the driver information in the hardware manager though. What's up here? Nethertheless, kudos for this great functionality of slipstreaming drivers, I really like the clean approach! In case the issues were not all my fault I hope I was able to shed some light on still problematic areas... Regards, Tomalak

Hello all, on my most recent installation I tried for the first time this feature of integrating SATA drivers (in the STORAGE subdirectory of HFEXPERT). I used the Intel Storage Matrix driver (iastor.sys). Worked almost perfectly on the first try, even with a self-created and customized storage.ini. The text-based installation phase went fine, the drive was recognized and installation started. But during the GUI-based phase a window popped up asking me for the location of the iastor.sys file. Directing it to the i386 directory of my installation CD solved this and installation went on. This is not a big flaw, but it prevented real unattended driver recognition. IMHO possible solutions are: 1. I should have followed the directions in the thread http://www.msfn.org/board/index.php?showtopic=63302 (integrating drivers), especially step 3, for the STORAGE directory and its contents also, not only for DRIVERCAB. Would this indeed help during the GUI-mode phase, without the line to be added to iastor.inf destroying the successful driver inclusion for the textmode installation phase? or 2. Should I duplicate the driver files contained in STORAGE and put a copy of them in DRIVERCAB, without the unnecessary storage.ini and a modified iastor.inf of course? Which of these methods is the one to use? Sorry, I had no time to test them, and I need a working notebook now, so no further installations for the next few weeks. Anyway, I think the correct solution should be mentioned at the start of this thread, could one please add a note to the first post with the instructions? Thanks! Regards, Tomalaks

Hello all, short update as an information for others trying to use a recovery installation to make an installation CD. I was able to create a working installation CD this weekend, so here are my findings (specifically for Lenovo Thinkpads): 1. Just deleting the svcpack directory and the svcpack.inf file is not enough. Installation went fine during textmode and GUI setup without any complaints (no missing files etc.), but after booting into the fresh installed system I found a lot of updates missing although they have been included in the hfslip run. The additional files still present in the i386 directory and the references in dosnet.inf to the files within the removed svcpack folder obviously interfered with the slipstream activities of hfslip. 2. Deleting all these superfluous files was the way to go. They can be recognized by not being spelled in uppercase letters (about 100 files in my case). I verified this by comparing against another WinXP Pro CD with just SP2 slipstreamed, the number of files being identical now. References to those files and the svcpack directory had to be removed from the dosnet.inf file. No more modifications necessary, and no other files had to be changed (I removed unattend.txt, but this doesn't count). 3. The OS identification files (WIN51, WIN51IP and WIN51IP.SP2) could be found within the i386 folder. They had to be moved one level up. The other files normally present in the root directory (setup.exe, the readmes, etc.) had to be copied from another CD, they were not on the harddisk after the installation. But they are not absolutely necessary. 4. Other differences compared with the contents of the other CD were about 6-8 updated files (telnet.exe, eula.txt, ...) and of course the four oembios.* files (needed for the Windows key to be accepted). I didn't care about them and used them as they were, no problems here. Using the resulting file set as input for hfslip and burning a CD from it gave me a working installation CD with the setup itself working smoothly (no errors, no messages), and a fully patched system afterwards. Other things I noticed are not related to this and I will report them in other, more appropriate threads. Thanks for reading so far... HTH, Tomalak

Yes, it's a Thinkpad (Lenovo). I know about the recovery partition and their "Rescue & Recovery" software, but that will only reset the computer to the initial status it had on delivery (only one usable partition, lots of crap software installed, not up-to-date). Didn't try to create and explore the recovery discs yet, as I thought those will just give me the same options I have as when booting into the recovery partition. My guess is that I will not get a useful Windows installation CD this way - at least not a better one as with copying the i386 directory from the harddisk and creating one myself. Other experiences? Will spend some time for this issue on the coming weekend. Is my assumption correct that I can also use an old but clean CD and just use the product key from the "unattend.txt" of the new notebook? Will this work (using the OEM key which doesn't require activation as opposed to the one which is printed on the label on the bottom of the laptop)? Maybe this would be the easiest solution, but being curious I will also try the direct approach (removing svcpack and see what happens when hfslip runs)... Thanks for your help so far, Tomalak

Hello all, just got a new notebook - there are no recovery CDs provided but there is a full i386 directory on the hard disk, so I decided to create full installation CD myself from that source. The problem is: the vendor apparently already included some patches and corrections. The directory contains a lot of dll's and other files that seem to have been added by slipstreaming. The svcpack subdirectory also is filled with additional executables. My question is now, before spending days of testing: how to deal with that, how to deal with an unclean source? Should I let hfslip just do its work and slipstream all updates, possibly overwriting some of the already integrated files? What about outdated patches that are not removed this way? Which problems do I have to expect, and how to possibly circumvent them? Or should I just remove the svcpack subdirectory and try to clean my source this way? But then what about still existing but invalid references (to be found in files in the i386 directory) to these deleted files? And additionally, how to detect which files in the i386 folder itself have been changed compared to a fresh SP2 installation source? Thanks for hints and good suggestions before tackling this! Regards, Tomalak