xpman

At least to me http://flyakite.msfn.org/xpprosp1.htm looks exactly like a step by step solution. At which point does something not work?

I had hoped this would not be such a hard question to answer So to be more specific: Is there anything else I need to do in the setupldr.bin for 2K3 R2 SP3? "winnt.sif" is mentioned (several times, I think). I changed all i/I386 occurrences, even kept the cases. So be summarize: 1. Manual installation from a multi-boot CD runs through. 2. Unattended runs through just as well when winnt.sif is on a floppy disc. 3. Unattended does not work when I have winnt.sif in my 4-letter boot folder. Searching did not reveal such a problem, so I probably did something stupid and hopefully obvious to someone. Where's the mistake?

Thanks for all the replies. Please let me clarify some things: 1. I am doing only a CD install. I only mentioned RIS to say "please do not give me RIS-solutions - I cannot use them". 2. I only put the $OEM$ folder at the root because some postings said that this worked for them (compared to putting it into some subfolder). 3. My motivation for not having it beside the I386 is simply the multi-boot scenario: I want to share the $OEM$ folder space-efficiently between several Win5 editions. Also the reason why I decided to post in the multi-boot, not the unattended forum; I see little need to move the folder if you have just a single OS. Regarding some of the new suggestions: 1. I tried OemFilesPath=D: (no success, I actually had tried ="D:\") 2. I tried OemFilesPath=%source% (which was not exactly the suggestion, I still presume that $OEM$ must be left out; I also thought there was no such variable during any install phase) So I still have no success, just some more questions: 1. Should the quotation marks make any difference? 2. Does the trailing back-slash matter in paths? 3. Is there actually a variable pointing to the setup source? I never saw this. (would be nice to have setupsourcedir as a full absolute path) (I somewhere read that this line does e.g. not work when you add a comment after it, so I suspect anything now.) And maybe I misunderstood something: In my experience, if you enable preinstallation, txtsetup copies the entire $OEM$ folder after copying the files specified in txtsetup.sif. So the bar remains at 100% for as long as that takes. So with no files being copied in my case, I take that as a sign that the folder redirection does not work. Am I maybe wrong about this? Will using OemFilesPath make the copying unnecessary and the setup process will simply look at that new path? And would this be the reason that an absolute path must be specified?So when I say "not working", I mean that I do not see the $OEM$ folder being copied as it usually is. Am I expecting something wrong? My general request is to see a working solution from anyone that uses this variable for CD installs. EDIT: I just let one install run through using OemFilesPath=D: - and cmdlines.txt in $OEM$ was not executed, although the CD drive is D: after the installation.

I have been at this problem for the last couple of years, never gave it a high priority, though. During this time, I only focused on CD installs, I have little to no clue about RIS. Still, it has always been bugging me, and with Win6x around I finally want to close my gaps around Win5x. deploy.chm says about this, among other things: What is *not* there: - any mention of relative or absolute paths - any mention of a difference between CD or RIS installs, setup.exe and winnt32.exe The following posting has several intersting points in it (http://www.msfn.org/board/oem-single-direc...hl=oemfilespath) - it claims that UNC paths work for RIS installs - it quotes a Microsoft engineering saying that for CD installs you have to specific a drive letter (and thus an absolute path, I guess) This posting (http://www.msfn.org/board/oemfilespath-t19810.html) claims success by placing the $OEM$ folder in the CD root and using OemFilesPath="$oem$" or OemFilesPath="..\$oem$". After reading these (any many more postings), I tried the following setup: - Windows XP Pro SP3 (I used the SP3 setupldr.bin for the multiboot, just to be sure) - $OEM$ is located in the CD root - I have one partition (and some free space) on the HDD, the primary partition is called C: in txtmode setup - I tried d:\, d:\$OEM$, \$OEM$, \ as OemFilesPath (presuming that the CD drive would be D:) Still, I have not had any luck. Setup only copies the files from txtsetup.sif and then reboots. The $OEM$ files are not copied. With all the postings around, I expected to actually find a "solved" anywhere, but no such luck. Then again, in the multi-boot forum, there are only 5 total hits for "OemFilesPath". I truly hope that this is a trivial one for someone who has had success.

Adding the win51s tag files to the DVD root and "extracting" the files again based on txtsetup.sif has done the trick (I can post the current file list again if anyone should be interested). The installation runs through smootly, however, now my winnt.sif is ignored, which is right in my boot directory (w03a). This works perfectly with XP. I looked through the w2k3 setupldr.bin (am bit aimlessly, I admit), and do not see what could be wrong. Again, all search results indicate I am doing the right thing. EDIT: putting the winnt.sif file on a floppy disk (disk image in VMWare, to be precise) works. I only have problems when the answer file is on the CD.

There was one basic mistake that I noticed, my bootdisk script used the wrong setupldr.bin (from xp pro sp1, which doesn't have to be cracked). However, even using the correct one now, I only get a bit farther: The setup screen appears, prompting me to press Enter, R, or F3, but none of the keys actually do anything. I'd think that at least at this point, setup is loaded and setupldr.bin has served its purpose. Let me also list the tag files that I have for both XP Pro and 2K3 R2 SP2 x86: win51 win51ip win51ip.sp1 win51ip.sp2 win51ip.sp3 win51is win51is.sp2 win52is.r2 By the way, is the setupldr.bin the same for both the x86 and the x64 versions? I am asking because it also contains references to AMD64, which is nowhere to be found on my x86 setup CD. So, naturally, I don't have it on my multi-boot disk, either.

Should be easy enough (if you keep the boot and sources folders as they are): Add "chain /boot/etfsboot.com" to the cdshell.ini file. I think unlike for XP, you need no tag files in the DVD root (although I see I copied the setup.exe there for some reason). It would of course be helpful to know what you *did* try exactly (or, alternatively, which other posts you found searching and why they did not help).

EDIT: the original issue I started out with is solved, but I am still stuck with winnt.sif being ignored on the CD (postings #3 and following). I have successfully been using my XP multi-boot disk for a couple of years now, but trying now in VMWare to add the Server 2003 R2 SP2 x86 to it, I am running into some problems. Reading through the 2003 multi-boot posts, I find that the same methods as for XP seem to be applicable and that I should be doing everything right - still I get stuck half-way through the loading of the "extracted" boot disks: 1. I "extract" the boot disk files using a script on txtsetup.sif. The resulting files are: 1394bus.sy_ acpi.sy_ acpiec.sy_ adpu160m.sy_ adpu320.sy_ afcnt.sy_ aic78u2.sy_ aic78xx.sy_ aliide.sy_ amdide.sy_ arc.sy_ atapi.sy_ biosinfo.inf bootvid.dl_ cbidf2k.sy_ cd20xrnt.sy_ cdfs.sy_ cdrom.sy_ classpnp.sy_ cmdide.sy_ cpqarray.sy_ cpqarry2.sy_ cpqcissm.sy_ cpqfcalm.sy_ c_037.nl_ c_10000.nl_ c_10006.nl_ c_10007.nl_ c_10010.nl_ c_10017.nl_ c_10029.nl_ c_10079.nl_ c_10081.nl_ c_10082.nl_ c_1026.nl_ c_1250.nl_ c_1251.nl_ c_1252.nl_ c_1253.nl_ c_1254.nl_ c_1255.nl_ c_1256.nl_ c_1257.nl_ c_1258.nl_ c_20261.nl_ c_20866.nl_ c_20905.nl_ c_21866.nl_ c_28592.nl_ c_28593.nl_ c_28598.nl_ c_28605.nl_ c_437.nl_ c_500.nl_ c_737.nl_ c_775.nl_ c_850.nl_ c_852.nl_ c_855.nl_ c_857.nl_ c_860.nl_ c_861.nl_ c_863.nl_ c_865.nl_ c_866.nl_ c_869.nl_ c_874.nl_ c_875.nl_ c_932.nl_ c_936.nl_ c_949.nl_ c_950.nl_ dac2w2k.sy_ dac960nt.sy_ dellcerc.sy_ disk.sy_ dmboot.sy_ dmio.sy_ dmload.sy_ dpti2o.sy_ drvmain.sdb fastfat.sy_ fdc.sy_ flpydisk.sy_ ftdisk.sy_ hal.dl_ halaacpi.dl_ halacpi.dl_ halapic.dl_ halmacpi.dl_ halmps.dl_ hidclass.sy_ hidparse.sy_ hidusb.sy_ hpcisss.sy_ hpn.sy_ hpt3xx.sy_ i2omgmt.sy_ i2omp.sy_ i8042prt.sy_ iirsp.sy_ intelide.sy_ ipsraidn.sy_ isapnp.sy_ kbda1.dll kbda2.dll kbda3.dll kbdal.dll kbdarme.dll kbdarmw.dll kbdaze.dll kbdazel.dll kbdbe.dll kbdblr.dll kbdbr.dll kbdbu.dll kbdca.dll kbdclass.sy_ kbdcr.dll kbdcz.dll kbdcz1.dll kbdcz2.dll kbdda.dll kbddiv1.dll kbddiv2.dll kbddv.dll kbdes.dll kbdest.dll kbdfa.dll kbdfc.dll kbdfi.dll kbdfr.dll kbdgae.dll kbdgeo.dll kbdgkl.dll kbdgr.dll kbdgr1.dll kbdhe.dll kbdhe220.dll kbdhe319.dll kbdheb.dll kbdhela2.dll kbdhela3.dll kbdhept.dll kbdhid.sy_ kbdhu.dll kbdhu1.dll kbdic.dll kbdindev.dll kbdinguj.dll kbdinhin.dll kbdinkan.dll kbdinmar.dll kbdinpun.dll kbdintam.dll kbdintel.dll kbdir.dll kbdit.dll kbdit142.dll kbdkaz.dll kbdkyr.dll kbdla.dll kbdlt.dll kbdlt1.dll kbdlv.dll kbdlv1.dll kbdmon.dll kbdne.dll kbdnec.dll kbdno.dll kbdpl.dll kbdpl1.dll kbdpo.dll kbdro.dll kbdru.dll kbdru1.dll kbdsf.dll kbdsg.dll kbdsl.dll kbdsl1.dll kbdsp.dll kbdsw.dll kbdsyr1.dll kbdsyr2.dll kbdtat.dll kbdth0.dll kbdth1.dll kbdth2.dll kbdth3.dll kbdtuf.dll kbdtuq.dll kbduk.dll kbdur.dll kbdurdu.dll kbdus.dll kbdusl.dll kbdusr.dll kbdusx.dll kbduzb.dll kbdvntc.dll kbdycc.dll kbdycl.dll kd1394.dl_ kdcom.dl_ ksecdd.sys lp6nds35.sy_ l_intl.nl_ mountmgr.sy_ mraid35x.sy_ nfrd960.sy_ ntdetect.com ntfs.sys ntkrnlmp.ex_ ohci1394.sy_ oprghdlr.sy_ partmgr.sy_ pci.sy_ pciide.sy_ pciidex.sy_ pcmcia.sy_ perc2.sy_ perc2hib.sy_ ql1080.sy_ ql10wnt.sy_ ql12160.sy_ ql1240.sy_ ql1280.sy_ ql2100.sy_ ql2200.sy_ ql2300.sy_ ramdisk.sy_ saport.sy_ sbp2port.sy_ scsiport.sy_ serenum.sy_ serial.sy_ setupdd.sy_ SETUPLDR.BIN setupreg.hiv sfloppy.sy_ slip.sy_ spcmdcon.sys spddlang.sy_ storport.sy_ streamip.sy_ symc810.sy_ symc8xx.sy_ symmpi.sy_ sym_hi.sy_ sym_u3.sy_ SYSTEM32 tffsport.sy_ toside.sy_ txtsetup.sif ultra.sy_ usbccgp.sy_ usbd.sy_ usbehci.sy_ usbhub.sy_ usbohci.sy_ usbport.sy_ usbstor.sy_ usbuhci.sy_ vga.sy_ vga850.fo_ vga860.fo_ vga861.fo_ vga863.fo_ vga865.fo_ vgaoem.fo_ viaide.sy_ videoprt.sy_ volsnap.sy_ watchdog.sy_ wd.sy_ wmilib.sy_ SYSTEM32\NTDLL.DLL SYSTEM32\SMSS.EXE 2. I placed those files into a folder called w03a below the DVD root folder. 3. I modified setupldr.bin accordlingly, replacing I386 by W03A 4. I modified the txtsetup.sif, pointing to the somewhat lenghty windows source path on the DVD (which always worked for me for XP this way, although my problem starts before setup begins copying files from the setup source). 5. I load setupldr.bin within w03a. Everything works fine, the drivers are loaded (at least 10 times faster compared to directly booting the 2003 iso directly, which I find strange). 6. Right after the status bar says that windows setup is being loaded, the screen goes black with a white, static cursor in the top left corner of the screen, but compared to my XP boot disks, it does not change to setup but stays this way. I think the files are right, I modified setupldr.bin correctly (after all, all the disk boots, the drivers are being loaded), so I have no clue where I went wrong. I stuck to the guides I found in the postings here, which look just like what I did for XP, and did`t even find anyone having this particular problem. Is it obvious to anyone where my mistake lies?

After some searching I found some good postings in the multi-boot forum on how to put Vista alongside XP, etc. using cdshell. This works very well. At the same time, I found that my Autounattend.xml is only executed when being in the root of my DVD but not from the sources folder. The main issue for me is now how to add multiple Autounattend.xml files on the CD and select corresponding installs from the boot menu. What I found in this forum so far all relates to using a command line switch on setup.exe and selecting the answer file. Something which I would happily do if I could when booting from DVD - but of course that doesn't work. My guess so far is that if that works it might be possible from WindowsPE; but firstly I have no clue how (and haven't seen any related suggestions in response to other multi-answer-file questions), and secondly that would mean not being able to select the Vista target computer from the main boot menu but only after booting WinPE (ok, that may be regarded as a negligable 'flaw', but I'd still prefer it). With XP it worked so nicely using the different boot folders. However, I haven't found anything corresponding to such a solution. It would be great to be at least pointed in the right direction. (Since the actual multi-boot part works and this seems rather related to the placement of Vista-specific files like the answer and wim files, etc., I think the Vista forum is the better place to ask about this. I didn't even get a hit searching for autounattend; unattend brought a few hits, but they didn't related to my Vista issue.)

There is a general question that has been bothering me ever since I started my unattended Vista efforts: a On one hand I read that every retail DVD has all Vista versions on it and that it only depends on the key; I find lots of postings here that deal with this subject b On the other hand I see instructions of how to integrate all Versions on one DVD, which involves a time-consuming integration step into the Vista image for each version that is to be integrate c Also, when trying to slipstream SP1 using vLite (which fails with a CabLib error, but that is maybe beside the point here), I also have to select a Vista version. I get offer all versions after my DVD has been analyzed, but still I have to choose. I hope the vLite forum is suitable to ask the actual questions: 1. Regarding vLite: Why do I have to select a Vista Version in vLite? If I leave the default key, then I should be prompted anyway during install, right? And hotfixes, SP1, etc. should not depend on the Vista version, should they? 2. Generally: Why do you have to integrate versions explicitly as described above in b if a is true? (ok, that is a bit off-topic, but it certainly does not belong into the general Vista forum in my view). (3. Any pointes regarding Vista multi-boot scenarios? My searches were pretty fruitless, just as those where I tried to find how to combine XP and Vista on one DVD. nLite and vLite seem to be made "just" for single installations.) I hope for those who have been dealing with unattended Vista longer than I have, this is a simple question. And please just disregard whatever question you feel is way off-topic for the vList forum.

His settings is more thorough but I found that my simple ones are working too The default user settings are for the default user from which each new user inherits the settings, i.e. every new user that is created will have those locale and input settings. It also implies that each user can then change them so that everybody can have different locale and input settings. These settings can of course be let away. Coming to think about it, I am rather getting confused about the normal system, user, and input settings. I also sometimes have trouble like that, including some German websites. I like to think that this is rather to some bad web programming. Most importantly, I think that if the language is installed in the language group, then everything should be readable. Locale rather concerns if you have , or . as decimal symbol and input how you enter text. But displaying text should not be changed by any settings you modify after installation.

The solution (at least the one I use) just involves some entires in the winnt.sif. So the detailed procedure can be found in the the preinstallation reference (SUPPORT\TOOLS\DEPLOY.CAB on your XP CD). However, as language support consists of a combination of languages, keyboard layouts, and locales, the corresponding settings involve more than just setting one parameter (so there are several possible solutions that might match your initial request). I use the following to get Japanese language support with Japanese, US, and German keyboard layouts: [RegionalSettings] LanguageGroup=7,1 SystemLocale=00000407 UserLocale=00000407 InputLocale=0407:00000407,0411:e0010411 UserLocale_DefaultUser=00000407 InputLocale_DefaultUser=0407:00000407,0411:e0010411 Traditional and Simplified Chinese are language groups 9 and 10 (1 is US and Western Europe), so LanguageGroup=1,9,10 should work for you. As for the rest you'd have to look into the presintallation reference for the parameter meanings and on the Microsoft website for the value encodings. As ref.chm links only to an overview site, I also had to search for it. The values are listed at http://www.microsoft.com/globaldev/referen...xp/xp-lcid.mspx So with this value list and the preinstallation reference, I think you can accomplish your task. I also struggle with the various parameter meanings, but I think it helps to just group them into the default user part (which is quite clearly what each new user will inherit, and which always is just one value) and the rest (which determines what is to be installed, and which may be a list of values). Good luck!

I've had some more time to deal with the problem: a. I use hivesft.inf to import both SFCDisable and SFCSetting with 0xffffff9d (I use both for testing). b. I modified the two bytes in sfc_os and also replaced SFCDisable by SFCSetting. I found the following: At T-12: 1. The modified sfc_os.dll is installed properly. 2. The registry settings from hivesft.inf are correctly imported. 3. The copying operation for the disk management files succeeds (just as for termsrv.dll) Now somewhere after T-12 and before T-9 the following happens: 4. SFCDisable is reset to 0; this, according to some other posting, is normal, and it doesn't appear to be influenced by the modified sfc_os.dll. Still, it shouldn't matter because sfc_os.dll should look at SFCSetting anyway. 5. The modified disk management files have been replaced by the original ones. Whenever I try to replace the files again after that (from a cmd that I leave open), the files fully disappear in system32 for a few seconds and then the original ones appear again. All I find in the forums concerns overwriting system files either after the first real boot or right on the installation medium. In the latter case WFP shouldn't matter anyway. I'd prefer having a choice at T-12, though, especially because termsrv.dll cannot be replaced as easily once Windows is fully up and running (at least not without another reboot). Any clues?

927357 (http://support.microsoft.com/kb/927357/), which fixed the RunOnceEx problem, is not included in the cummulative IE7 update 933566 (http://support.microsoft.com/kb/933566). The fix was contained in the now obsolete 928090 cummulative update (http://support.microsoft.com/kb/928090/). Consequently, RunOnceEx is (again) not working anymore. Which IE7 fix should be used now to keep that fix?

1. Help came when I was looking at how to disable WFP, which lead me to this post: http://unattended.msfn.org/unattended.xp/view/web/64/ After applying modifype dmadmin.exe-a and then compressing the file as before makecab dmadmin.exe dmadmin.ex_ The installation went through perfectly. So it was just a checksum problem. Interestingly, none of the guides I read mentioned this. But then they only described how to replace the files in a live system. I guess that Windows doesn't check the checksum then. 2. What I am unsure about now is a. which files to require such modifications. b. if I can do any damage applying modifype.exe to the "wrong" file, i.e. one that doesn't need it. Does the exe check this? 3. I then tried to disable WFP with a modified sfc_os.dl_ and the hive modification so WFP would be disabled at T12 already. Copying the RAID files in a script worked then (I verified that the files were overwritten), but after the first reboot they were gone again. The reason for doing it this my is to keep the modifications to the original medium at a minimum and the allow the replacement of files besides sfc_os.dll at a minimum. The fact that I got no WFP message box when copying the files over at T12 suggest to me that WFP was indeed disabled. But why are the files gone after a reboot, then?

All my attempts in the meantime to solve this failed so far. Does anybody maybe have a hint regarding the replacement of such files in general? I have a similar problem with termserv.dll.

I have some problems concerning the slipstreaming of the XP Pro RAID modifications. I use the guide according to this link http://www.tomshardware.com/2004/11/19/usi..._raid_5_happen/ Modifying the files and inserting them manually into the system works fine. I have now tried two different ways of integrating the files on the CD: 1. Replacing the original files on the disc. a. I used makecab to create dmboot.sy_ dmconfig.dl_ dmadmin.ex_ b. Then I replace them in the I386 folder. c. Then, during textmode setup, I get an error message: "The file dmadmin.exe was not copied correctly". In addition the file is claimed not to be a "valid Windows XP system image" (see attached screenshot for details). The other two files do not create a problem. 2. Putting the files into $OEM$\$$\system32 and $OEM$\$$\system32\drivers (just like in the live system) In this case, the original files are still there after the installation completes. I had thought that the contents of the system32 folder was copied during textmode setup before the oem folder was processed. This behavior suggests the contrary. Searching the forums for "dmadmin" didn't reveal anything regarding this. I still hope anybody has any idea what this could be or how it is solved. It seems to be that there are some basic issues with file replacement and copying behind this which I don't know about.

Nice to see some increased activity in this thread. I would just like to point out once more that all I am doing is adding hotfixes through nLite. No addons, no other update packs like Ryan's, etc. So I have a hard time seeing that this could be a compatibility issue.

To be sure, I added framedyn.dll in the keep box and copied it into $$\system32 in the $OEM$ directory. After installing, the file is actually there (although I have not found out why since I made two changes at once). However, the error still occurs (so my guess is that it's just copied from the $OEM$ directory but not really registered). For reference, here's my session.ini file: [Main] Env = 1.3 - 2.0.50727.42.Microsoft Windows NT 5.1.2600 Service Pack 1 Target = Windows XP Professional SP:2 - 5.1.2600.2180 - English (United States) [Tasks] Remove Components Hotfixes and Update Packs Options [Components] ;# Compatibility # [KeepFiles] msconfig.exe framedyn.dll logoff.exe [RemoveFiles] [Options] CABNoHigh ProfilesDir = "%SystemDrive%\Documents and Settings" TargetPath = "WINDOWS" temp_dir = %USERPROFILE%\Local Settings\Temp [Patches] [Services2] [Tweaks] [Unattended] ComputerType = Default MaximumDataStorePercentOfDisk = 12 RestorePointLife = 30 DesktopTheme = Default|| AutoUDay = 5 AutoUHour = 15 ProgFilesPath = "\Program Files" [NetAdapter1] connname = "" macaddress = "" ipaddress = "192.168.0.1" subnetmask = "255.255.255.0" defaultgateway = "" dnsserver1 = "" dnsserver2 = "" winsserver = "" netbiossetting = "0" ipxnetworknumber = "00000000" ipxnetworkframetype = "0xFF" [GuiRunOnce] [Drivers] [Hotfixes] F:\os\nLite Integrable Hotfixes\windowsxp-kb924667-x86-enu_9016dbabca407c3278219baba256111e131330a3.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb834707-x86-enu_6cf07c9c17963993b56d3e7502fac060123e3181.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb873339-x86-enu_fd28098f5f0e8e629e5b7f64e5cd6b6b722a35a7.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb885835-x86-enu_920ecebf9cd90610ec67a305820f98e4186ca748.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb885836-x86-enu_f87074f42947ee275445bdd34dda472871ed3b41.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb890175-x86-enu_7ba9247b3c47f90ac07fcc4c3227b9a48c8366b0.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb888302-x86-enu_5c4ef905021d66aa78d9f5f112e5d05c40b1a909.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb890047-x86-enu_b11cd51a47917fb48a3ff5ea232a11076d37875e.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb887472-x86-enu_5edc4ccc759d65f4afba8542435172ed54515135.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb885250-x86-enu_1ad483d726bd6ecbf5dbf2cec4720e737a7f7f67.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb873333-x86-enu_3d9a08de2dea62e11a96e38b5b0c43c802f4858b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb891781-x86-enu_32b11076df0189adeb0f36ce3bf7baa01cff1c29.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb867282-x86-enu_d7820c84f525a3eb3699a7f1d6b3ed84ff24b91d.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb888113-x86-enu_b003447509dec5510e25366e2e02eae477ded11a.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb893086-x86-enu_a2e913a0520492a1013d8653626eae6fa05fac7c.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb890923-x86-enu_c373b614a40a2ce85af9e795ad8955e585609301.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb890859-x86-enu_813f47d987b772bacae20e7dec9b5f6f16079303.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb890046-x86-enu_432bf46f62aeaecc0e519af31d74723096f9b201.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896358-x86-enu_42b05278a6f2ee006072af8830c103eab2ce045f.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896422-x86-enu_4151843be8f1d81514b35bd5480232544f4787ba.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896428-x86-enu_24f66bc1e3b8107ec580ba2c53148a69dbc606a0.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb883939-x86-enu_59c2da5550bdbb6696552ef5bab50ff05939e962.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb893066-v2-x86-enu_3d2029a4300c0b7943b20c1287c8143087045d52.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb901214-x86-enu_2838831de819dad80ea0edaf5fb1e0bfb3c026c0.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb903235-x86-enu_4759bc9ceeb4c84401264cd925a037e9e00f4e60.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896727-x86-enu_d7e428a183c8a82e7d9ce2b80858e66b05e2854c.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb899588-x86-enu_4942c9ff7c7fe8af13ff202c234496ce91635ae1.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb893756-x86-enu_0fff59c5188cc15ec8f138fda97cb8be1e22da66.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb899591-x86-enu_3022d995581878f4017098b693b4ba35f99dee5c.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb899587-x86-enu_95ef03f0da9761b044b9a98d445af90266777ea8.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896423-x86-enu_baba29a9d96e44e3f55045f749cc82cfa4038f0b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896688-x86-enu_746342fe31abfc7a4fb3ea180cf08dc65c2c6a95.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb902400-x86-enu_a51d743a1925dd0216160daaf9fc4c7a42a27e53.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb899589-x86-enu_4a281c5b3b826b3ae76e502cbeae6410f0407651.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb900725-x86-enu_21b409882b7f51a9d09c32bd698504fadb9fc433.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb901017-x86-enu_04c459695f9018fd31c762bb0a8250cb0506061b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb905749-x86-enu_3f44b68f7e0a0e6332dd18997e134beab1027c73.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb905414-x86-enu_9e8fa8909332653de951edcfdb691f2aa148eb1b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb896424-x86-enu_bc0a35c5dd2dded71405dab707d0c61831b2a58f.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb905915-x86-enu_b7a56a560ef3192731696c3288e6ba974c9529ee.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb904706-v2-x86-enu_ec909ee2bab6b15d7d3545a1eaf07bbb066e038b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb912919-x86-enu_a4b4638c85d74c1d9ceaf63189ad46aa34f60293.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb908519-x86-enu_ea7ea742f9a3632f1090eab8c66b3fe7735c084f.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb913446-x86-enu_b41b0b8eb6e36b74499a588fb5e6a88a2c5e6317.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb911927-x86-enu_db8cbad537f3f0453deac488f8eb629b3c3a832b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb901190-x86-enu_2497a4e9957ddf13e2343858608f89ef6132efb2.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb911567-x86-enu_3322015f70b63fd2c82af81148ed88055a6f7e5b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb911562-x86-enu_7d16ad9701607a354e0ca2602a3fef485c8d9929.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb913580-x86-enu_f57aa2fdaf623d8b0231fc928c00ad8498d37c76.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb912812-x86-enu_6f395a56db4853c26daaad24fd992497278fba82.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb908531-v2-x86-enu_0f04352bbc21b3c173cc8dd8c9e63c082b34b676.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb917344-x86-enu_9c0c688c3e5c11a1b2ce0666117dc193823367b0.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb914389-x86-enu_8c44336e9e4f287891ac384bee0219e9c2224523.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb917537-x86-enu_a4dbb2338b97e63f46d45f1d69aa6a7908269b13.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb917953-x86-enu_a1c66e00d1a487f25ca16af5a7f858858136c228.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb917159-x86-enu_5ed838e18ceae61a8d94f8c4be2462a8e19212d7.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb916281-x86-enu_db93384fa2f9b7b1c8b93456381fa7b654636ae0.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb914388-x86-enu_21992f2ad7f7fd8ab28e854ce364ebc4f8baf810.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb918439-x86-enu_056bf5d0c049e0e8e799593b3508627ee8557dc1.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb911280-v2-x86-enu_3a49ae105416eb7b37dbbaccbedc9c20069ef1d9.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb921883-x86-enu_80bd35bdac09cbe1974111ee623b36f016b639be.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb917422-x86-enu_8a32d9119235c80bc6a82793403e0e5443c36789.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb922616-x86-enu_cf1ee106a318c1fe135978f94ec0867312cea73b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb920670-x86-enu_a71ac163b276057101fe92739c06c6e6d143ccf8.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb920683-x86-enu_ef1482c5b88557e56563dace9b7549ebf6d7f9c7.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb921398-x86-enu_47a6965d63200295eb57c1d7a5440d26c43d90d1.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb920214-x86-enu_3f16a756fc5763565e1f824f8519690fa18012a5.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb918899-x86-enu_c0d1d367b24bd3fe6f2068a5459d5483bb35ba39.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb920685-x86-enu_be0e9cea96e2ad48394aebe90d48edcc36ac38d5.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb919007-x86-enu_dc2307d635a64c87bbf1f216442104ef4b4ada0b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb925486-x86-enu_b23791745d2206a9333cf2da9e683c3366b067ce.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb922760-x86-enu_07543630cd9b3013862a2d79a95cf0e1e51803ca.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb922819-x86-enu_e4dceecdd4a72e5ad91cc78fe5f4572f91ee5db0.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb924496-x86-enu_f1e2421551a739eae947590735fb3f4abec82c22.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb923191-x86-enu_9d2cfed124f1f50804c20a6e8a881f84c266745f.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb924191-x86-enu_5e3ee7c5954da4cd38a5121623c05d617e547951.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb923414-x86-enu_ed2b1047badbd832a971a76ca7ef4519d1a444f4.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb920213-x86-enu_02cb394147b09e8926b4f8334feeff4b8fa4b33b.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb923980-x86-enu_1f04bf1859d5ba3761e482dbbd48f3795001e391.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb924270-x86-enu_3b1af30dc7a2f51f60a415eaf2cc01f9bf779dab.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb926436-x86-enu_98f46d49f189f01c14a7d5360d794da20edae885.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb923694-x86-enu_2b3f0e26ab0560c97bd33ea33022161268342a5d.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb926247-x86-enu_f465277dda6008156bb6f81bc77c72253a91d303.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb926255-x86-enu_1737b8dde544dbbc79dddd6f123291b781313c04.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb925454-x86-enu_968e709977724060e4d290bece1b6e67f5a078c1.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb923689-x86-enu_056c15e845cdf1027b2ea920e97ab8f4319c4bc6.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb929969-x86-enu_1237547f1cb90f54269bdb73c9985f263e85d48c.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb928255-x86-enu_d29dfbbe228e49f746a947eeb4880e980b76d53d.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb928090-x86-enu_3b58f59e0ee806789746335bfdab293a0d5f5b88.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb928843-x86-enu_80eb8779856aefa25bceab8926940fbdebabdc23.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb927802-x86-enu_94703f4083a9d9d6633d9134d0d0a85bfc405f3a.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb931836-x86-enu_88800ae7ce66933f34a490ba2e58d51822078c6d.exe F:\os\nLite Integrable Hotfixes\windowsxp-kb927779-x86-enu_ec7986f2b0afe9cc7f53a48b6582169a77d9515e.exe

I have been having this problem (among other things missing) for some time now, and searching the forum only revealed other people having the same problem, lots of advice and ideas - but no solution. In my case, I also just have slipstreamed SP2 into a copy of my original medium. Then I use nLite to integrate the hotfixes, nothing more. Still, it seems nLite removes the dll (and logoff.exe) for some reason. I even tried to just select hotfix integration but not actually add any hotfix - same result. Currently, I am experimenting with simply adding framedyn.dll to the keep list (along with logoff.exe), but it's beyond me why that should be necessary in the first place if I don't do any space-optimization.

All my searches so far revealed that using dxsetup.exe /silent will result in a silent installtion of DirectX 9.0c after extracting the original redistribution archive. This works fine for me after the installation, but if I execute this statement atT-13, DX9 is not installed. Not appearing as an installed program anyway I use dxdiag.exe to determine the state of the installation. After a successful installation, there are a whole lot of new files listed in the files tab of dxdiag, all bearing the current date. When I try to do this a T-13, these files are simply not there. With the first release of DirectX 9.0c this worked perfectly - only it became unnecessary after SP2 for a short while since DX9 is included. As mentioned above, searching for this in connection with problems at T-13 didn't bring up anything in this forum, otherwise I wouldn't have posted. I only find the same answer over and over. So maybe somebody has any idea what the problem could be.

I have the very same problem, but only if the data size on the disc exceeds a certain amount. With 2.8GB it works, with 4.4GB it freezes. I have also copied bootfont.bin from the German version; when everything works, the screenmode is switched and the other font is used; in case it freezes, it freezes in the regular text mode. Maybe this is useful information? I have not used any of the tools mentioned but created everything manually or with command line tools (for the creation of the floppy disk boot images). I use the very same files, only that I leave two Linux distributions away for it to work. For me, this is also new behavior on the real machine. I think it must be related to the data size, although I have no clue how that can be. @syster: So, just out of curiosity, maybe try to made a multi-boot disc but only with one Windows on it. This behavior is so strange that I have no idea where to start looking. Searching the form only revealed this post to me as being related to the problem.

I successfully move the My Documents folder for each user to a specific directory by importing a REG_EXPAND_SZ value at T-12 as described in this post: http://www.msfn.org/board/index.php?showto...7339&hl=cusrmgr At the end of that post, an ACL problem is mentioned when reinstalling Windows because new user IDs are generated. Other posts I've read seem to content themselves with moving folders and do not even mention any ACL problems. However, I do not even get that far. The folders that are created provide full access to the Everybody group and to that group alone. The corresponding user isn't even listed. This happens, although the folders - are residing on an NTFS drive - are being created by Windows itself during the first logon of each user (so Windows should know which user it creates the folder for and hence be able to set the access rights properly) In addition, it would of course be nice to know how to get rid of the "ghost" user IDs during a reinstall, but for now I would be happy if anybody could help me with my current problem. Every user being able to manupulate every other user's files is of course inacceptable. I wonder why Microsoft enables custom placements of these folders without setting the access rights accordingly. For any serious application this is unusable - but then again, you'd probably use a domain and a server hosted profile anyway for a "serious" application. One thing I could imagine to be the reason is that access rights are inherited from the parent folder, i.e. the profiles directory. So if I move My Documents, there is no folder there to inherit the rights from. Again: Where's the sense in being able to move the folder then? I am not familiar enough with ACLs to verify this hypothesis, but I thought I'd still mention it.

Since HKLM contains settings for the entire machine, users could not have their indivual quick launch configurations. Even if you want all users to have the same quick launch settings by importing the setting at T-12 through the current (default) user, in general of course each user should be able to decide indvidually how the quick launch bar should be configured. That's not possible with a machine key.

I have the very same problem. After trying out the "/silent" command line parameter and the setup.inf modification the GUI window still pops up.