johnwinterflood

But apparently this is an ancient addition - released in June 2005!!. So why is it wanting to download this one. Surely this must have come in with SP2 or at least SP3?Anyone else's machine trying to download this ancient update? Any clues why?

OK it seems that my problem is solved - and here is what I did. I left the entire list of hotfixes the same, but just reordered them by their build dates according to nuhi's instruction. Since a few of them (IE7 and addons) didn't have build dates, I ensured that IE7 was first and the addons last with the rest in between according to their build dates. I also turned on warnings and these were the ones that I got: While integrating IE7 it came up with the following "Newer file already present warnings": browseui.dl_ - File is newer than the one integrating. File version in ISO: 6.0.2900.5512 File version in hotfix: 6.0.2900.2995 jscript.dl_ - File is newer than the one integrating. File version in ISO: 5.7.0.16599 File version in hotfix: 5.7.0.5730 shlwapi.dl_ - File is newer than the one integrating. File version in ISO: 6.0.2900.5512 File version in hotfix: 6.0.2900.2995 vbscript.dl_ - File is newer than the one integrating. File version in ISO: 5.7.0.16599 File version in hotfix: 5.7.0.5730 Following that I got the following warnings: KB941569 - Direct integration for this hotfix is not supported. KB942763 - Direct integration for this hotfix is not supported. KB946648 - Direct integration for this hotfix is not supported. (msgsc.dll - File is not present in the ISO to be updated.) KB938127 - Direct integration for this hotfix is not supported. KB953839 - Direct integration for this hotfix is not supported. KB953838 - Direct integration for this hotfix is not supported. KB956391 - Direct integration for this hotfix is not supported. While integrating KB958215 I got the following "Newer file already present warnings": mshtml.dll - File is newer than the one integrating. File version in ISO: 7.0.6000.16705 File version in hotfix: 6.0.2900.5694 urlmon.dll - File is newer than the one integrating. File version in ISO: 7.0.6000.16705 File version in hotfix: 6.0.2900.5694 wininet.dll - File is newer than the one integrating. File version in ISO: 7.0.6000.16705 File version in hotfix: 6.0.2900.5694 And finally: KB960714 - Direct integration for this hotfix is not supported. I thought I would try installing it before slipstreaming WMP11 and it installed OK and seems to run fine. It came up with one file that it wanted to download and install - KB808461 which "installs a permanent copy of the Package Installer". So I guess this must be a very late addition? Since it did not list any of the hotfixes for which "Direct itegration is not supported", I suppose that answering yes must have caused them to get installed by some means? Anyway it seems that I now have a system that boots and really the only change I made would seem to be reordering the hotfixes and leaving WMP11 out.

I would just like to confirm that I am having the exact same problem that LeveL has reported. However I do not have IE7-KB928090-WindowsXP-x86-enu.exe in my list of hotfixes (and neither do I have either of Stimpee's IE7 fixes - 933566 and 929969). Also I am having this problem trying to install from a CD to a real formatted hard drive (not a VmWare simulation). Like LeveL I recently reinstalled a system (actually WinXP on a MacBook Air) and noticed that it wanted about 22 more hotfixes than I had already slipstreamed into XP3. So I noted their names, dowloaded them all, and slipstreamed the whole lot into a new installation CD for a desktop which is now showing the identical symptoms to LeveL's. Here is the list of XP3 hotfixes that I integrated: WindowsXP-KB923789-x86-ENU.exe WindowsXP-KB938464-x86-ENU.exe WindowsXP-KB941569-x86-ENU.EXE WindowsXP-KB942763-x86-ENU.exe WindowsXP-KB946648-x86-ENU.exe WindowsXP-KB950762-x86-ENU.exe WindowsXP-KB950974-x86-ENU.exe WindowsXP-KB951066-x86-ENU.exe WindowsXP-KB951376-v2-x86-ENU.exe WindowsXP-KB951698-x86-ENU.exe WindowsXP-KB951748-x86-ENU.exe WindowsXP-KB951978-x86-ENU.exe WindowsXP-KB952287-x86-ENU.exe WindowsXP-KB952954-x86-ENU.exe WindowsXP-KB953839-x86-ENU.exe WindowsXP-KB954211-x86-ENU.exe WindowsXP-KB954459-x86-ENU.exe WindowsXP-KB954600-x86-ENU.exe WindowsXP-KB955069-x86-ENU.exe WindowsXP-KB955839-x86-ENU.exe WindowsXP-KB956391-x86-ENU.exe WindowsXP-KB956802-x86-ENU.exe WindowsXP-KB956803-x86-ENU.exe WindowsXP-KB956841-x86-ENU.exe WindowsXP-KB957097-x86-ENU.exe WindowsXP-KB958644-x86-ENU.exe WindowsXP-KB958687-x86-ENU.exe WindowsXP-WindowsMedia-KB952069-v2-x86-ENU.exe In addition I Added the following IE7 files (in this order I believe) IE7-WindowsXP-x86-enu.exe IE7-WindowsXP-KB938127-v2-x86-ENU.exe IE7-WindowsXP-KB953838-x86-ENU.exe IE7-WindowsXP-KB960714-x86-ENU.exe WindowsXP-KB958215-x86-ENU.exr I then included a couple of addons: Java Runtime Environment 6 Update 11.cab and a DotNet 2 thru 3.5 that I built using someones tool. I then added WMP11 (which itself needs 3 hotfixes) by running the dedicated slipstreamer after finishing the nLite run. The WMP11 files I included were: wmp11-windowsxp-x86-enu.exe WindowsMedia11-KB929399-v2-x86-INTL.exe WindowsMedia11-KB936782-x86-ENU.exe WindowsMedia11-KB939683-x86-ENU.exe At some stage I also added some drivers for a particular machine but I don't remember if I added them in the first nLite run or added them later (to tailor this distribution to a particular machine). Fortunately I decided not to install it on my main hard drive, but thought I would try it first on a second drive which I could format for the purpose. I unplugged the main drive so that it wouldn't go searching for previous installations etc. So that is my story and I may be able to do some experimenting with it if that would be really useful to nuhi or someone. Any clues anyone can suggest as to which new hotfix might be causing the problem would be greatly appreciated!

Hi, I hate to admit defeat but I am close to giving up on trying to get an unattended install from a copy of XP on a hard drive to a specific drive letter. I wonder if anyone here can offer some advice. The strange thing is that I have a couple of other machines in which the standard approach seems to work (although now I don't understand how it could have worked), but I cannot get it to work on this system. The starting point is a system with two drives, the first one has drive letter C: and is formatted FAT32 and has a well working XP installation as well as a soft copy of the Windows XP CD. The second drive has letter Z: (set by right-click on My_Computer/Manage, Disk_Management, right-click on second drive, Change_Drive_Letter...) and I wish to install a copy of Windows on to this drive WITHOUT changing its drive letter to C: or D: in the process! As I understand it, the main thing necessary is to pass WINNT32.EXE the option "/tempdrive:Z:" and I do this with a command in a batch file as follows: Batch file "InstallToZ.bat" set AnswerFile=.\InstallToZ.txt set SetupFiles=..\..\OemXpSp2\i386 %SEtupFiles%\winnt32 /s:%SetupFiles% /unattend:%AnswerFile% /copysource:lang /tempdrive:Z: /cmd:InstApps.bat /dudisable However when I run this it insists on calling the second drive D: and installing it as D: Earlier on in my attempts I had the additional option "/syspart:Z:" but now I understand that this option is intended for when one wants to remove the drive from the computer it was installed from and plug it into another computer. So having this option present makes it install to the second drive and call it C: so that when it boots up it runs as C: and calls the first drive (previously C:) D: instead. The remarkable thing is that on my other two systems it seemed to work fine with this option present! Another thing I found after pouring over the deploy.chm and ref.chm documentation, is that there is a line in the unattend.txt file which causes it to install to the first available partition (presumably ignoring the "/tempdrive:Z:" option?!). This line is: [Data] AutoPartition=1 I tried changing this to 0 instead of 1 with no effect. However on my other systems, it is happy to install to the drive I specified in /tempdrive regardless of this line. The documentation also suggests a couple of other lines that maybe should be changed: MsDosInitiated=0 ;0=Unattended Setup is running directly from Windows product CD (not true!). UnattendedInstall=Yes ;Yes=Unattended Setup is running directly from Windows product CD (not true!). However these lines cause no problem with my other system, and the documentation does not give a situation when you would use "MsDosInitiated=1" or "UnattendedInstall=No" in an unattend.txt file! One difference I noted between the systems which work and the system which doesn't, is that the systems which work have several partitions on both drives. So I tried partitioning the second drive and installing XP to the second partition on it, but no joy. It reassigns letters to all drives and partitions. Another difference is that on the systems which work, all formatted partitions on both drives are NTFS, whereas on the system which doesn't work the first drive is FAT32. However since I am not yet ready to format the first drive (until I get the second one working the way I want it), I don't want to partition or reformat it yet. As an almost last resort, after it had installed to the second drive as C:, I tried getting into the registry from that installation and changing C: to Z: and D: to C:. (I have no doubt that I was successful here as I have fiddled at this level before several times). After doing this, I tried to reinstall to the second drive using the "repair" option hoping that it would read the registry and try to restore things according to the drive letters found there. But even this did not work!!! My last resort will be to boot from the CD itself and do it the pedestrian way (which I am assuming will work!), but I would really like to solve this problem for the future. An interesting question relative to this problem is, how does WINNT32 determine what drive letter goes with what partition after the first restart? Does it have to search for and read registry entries from previous installations? And another question is why does it spend so long "scanning C drive" after the first boot - is it actually scanning the first (old C:) drive or the second (new C:?) drive and what is it scanning it for!