jaclaz

Just for the sake of a little polemics, from the link you gave (which is aimed to solve another problem that some version of FDISK have, and where the issue about multiple primary partitions is not at all considered) : (bolding is mine) Not very different from my simplified "YOU ARE ON YOUR OWN". Moreover, from a pure lexical standpoint, if I tell you that to drive a nail into a wooden plank you can use a Third Party tool called "hammer", it does not mean that I suggest the use of the tool "hammer" to hit your fingers, although the suggested tool is perfectly capable of doing that. The problem, besides the cases you described, could happen if any app is used that writes to disk using "hardcoded" paths, like D:\, E:\ , etc. if a shift or however a change happened in letter assignments, I am thinking about scheduled jobs like backups or "saving settings", but it could be any similar job, set with a certain existing "drive mapping" that could overwrite something when run once a different "drive mapping" has become effective. Moreover there is "user" error possibility, I mean, if the nth partition is given "E:" if booted from DOS/9.x and "F:" when booted from NT/2X/XP, there is a probability that the user will once delete something from "E:" thinking he is deleting it from "F:".... Of course this can be easily worked around by using on the DOS/9.x "side" Letter Assigner and from the NT/2k/XP one manual drive letter assignment to have same lettering in both boot scenarios. jaclaz

Well, in my experience, error messages, with a particular emphasis on those generated by "microsoft Office related apps" tend to be so deceiving to be in a large number of occasions of no practical use. You will find much sooner what you are missing analizing the running processes with monitor tools as already mentioned and running tools like "Dependency Walker" or similar ones to make a quick list of .dll's required by Outlook. After having run Dependency Walker on the Outlook .exe and .dlll files, you could have some "basic" missing files that you can try adding to the install (those "hard referenced" in the .exe's). Than you fire up Filemon and Regmon filtering out all the .exe's you have running but those you presume create the error and see what they are looking for when running and add any component found missing. For Registry entries you might want to have a "parallel" build (working and with Outlook Express installed) to peek into it's Registry and copy the keys found missing on the "experimental" build. The removal files linked to can be however a good reference for making an "inversed" .inf file, i.e. one that only installs the required files and Registry entries of Outlook Express. Most probably you will need a batch, an Auto-it or VBS script to manage those Registry entries that are generated "on the spot" by the standard MS installer on a "per-machine" basis. Also, for the little I know about WINFLP, since it is a somewhat "limited" version, maybe it is better if you do the experimental work in a full XP (so to be sure that none of the possible WINFLP limits "get in the way") and only later test your partial installer on WINFLP, doing, if necessary the needed adjustements. jaclaz

Cannot say if this is of any help, but here: http://koti.mbnet.fi/digitale/throwoutoe/ is a "stand-alone" OE uninstaller. Since it is in the form of a batch file it is very easy to modify it. Maybe if you monitor with tools like Regmon, Procmon and Filemon from Sysinternals an install with both Outlook and OE, you could determine what parts of OE need to be kept to mantain the functionality you need (and thus you remove the corresponding line from the batch). Fred Vork has a similar (said to be more thoroughful) PE uninstall in the form of an .inf file here: http://www.vorck.com/ie-cleanup.html#oe If you are not familiar with .inf files, here is a VERY good start: http://www.boot-land.net/forums/Useful-inf...-inf-t1966.html I guess starting with either of this bases it should be a matter of a few attempts. jaclaz

If you are really sure those files need to be deleted you can try: http://www.dougknox.com/xp/tips/xp_undeletable_file.htm the above and some more ways: http://xona.com/2004/08/19.html This one links to some specific utilities: http://www.pchell.com/support/undeletablefiles.shtml jaclaz

As a general advice to all, a good idea is to ALWAYS, ALWAYS, and I mean ALWAYS make a backup of MBR and (possibly) bootrecords of all partitions. A very simple GUI utility for this, apart MBRFIX/MBRWIZARD, is Dimio's HDHACKER: http://dimio.altervista.org/eng/ A MBR or bootrecord will take 512 bytes of disk space on a NTFS partition and as much as 64 Kbytes on a HUGE FAT16 partition, you can even zip them together, don't come to me saying you cannot afford the disk space or the no-more-than-five-minutes needed to perform this simple preventive step.... ...and you will thank me for this, should disaster happen! jaclaz

Yes, it is : http://www.msfn.org/board/Fit_Vista_single_CD_t96980.html Basically you need to remove EVERYTHING or very nearly to everything to fit onto 650÷700 Mb. Don't take the following as an offence, and you seem like having used a wise approach to vlite but I see this is your first post, so a few points might be of help, as with vlite I am seeing exactly the same trend that has been on the board for nlite, I don't want to "scare" you, but: 1) nlite and vlite have the goal to remove UNWANTED stuff, once the staff has been removed IT IS GONE (a large number of users first thing remove everything, then post something like "this or that does not work in the build, how can I re-add this or that" ) 2) There is NO practical way to re-add something to nlited/vlited installs, though it is possible, it is very hard to do, and best option is to REBUILD with more appropriate settings. 3) There is NO fail-safe settings (unless you choose not to remove ANYTHING) these very good programs cannot read the mind of the user and warn him he is removing something he will later need. 4) the reduced size of install files is a SIDE EFFECT of the removal procedure, to fit into a certain amount of space you will need to remove LOTS of things. The more things you remove quite obviously, the more it is probable that something will be missing. 5) There is an initial rather steep learning curve, you'll have to make several attempts before finding out which settings are the right ones for your custom build. WRITE DOWN your settings or SAVE the build logs, so that you can review them and (hopefully) find out what you missed in your previous failed attempt. 6) Do browse the board in the appropriate section, even posts seemingly unrelated to your problem can offer a small hint about what could have gone wrong. 7) Take your time, but don't be afraid of testing your customized settings, with today's PC speed it is a matter of minutes to rebuild and test, possibly in a VM like Qemu or VirtualBox, if you are lucky (and you are not going trying to reduce to the minimum the size) you might be able to get what you want in a few attempts. Usually a step by step approach, progressively increasing the number of removed components is the one that "pays" the better. As soon as the new build under test is found missing something you need, you check the differences against last working one, and usually, with some common sense, it is possible to determine which of the few components you added to removal list could be the culprit. Looking for it in a list of tens of removed components can be, again quite obviously, really daunting. 9) Don't give up, maybe you are just one little tickbox away from your "perfect" build 8) But do control yourself, "liting" an OS can become an addictive habit 10) Have fun, that's the main thing. jaclaz

"better" is a very difficult definition, sure it is faster! : don't take my word for it, read Mdgx's take on the topic: http://www.mdgx.com/98-5.htm#WDIW The only possible (unconfirmed) exception could be if you use a German system AND MS money 99: http://www.msfn.org/board/Note_WinME_Defra...y99_t92956.html I guess that this, even IF definitely confirmed, can be solved or however affects 0.01% of users.... also, check #16 here: http://smallvoid.com/tweak/win9x/tweak.html and "MAP THE CACHE" here: http://www.mdgx.com/98-3.htm and, ONLY if you like taking risks AND have less than 64 Mb memory, this: http://www.mdgx.com/98-1.htm#98FAS jaclaz

Are you sure? When did it happen? I have downloaded programs from Microsoft servers through WGA not later than one week ago or so. jaclaz

You mean you tried editing a Registry hive in Notepad? jaclaz

According to their site: http://www.irfanview.com/history_old.htm awd is supported, since version 3.99, though I have doubts that it is the "same" AWD. First app linked to should work, it is the "fax" .awd format: http://www.pictview.com/importWin.htm jaclaz

Why not? Did you EVER build a BartPE? It is not difficult at all. jaclaz

Since a CD-ROM (and the .iso file is mounted as CD-ROM) is READ ONLY, I think that the reason is rather obvious. You need to re-build the .iso with pebuilder with a modified registration number in the Registry. Other options include hexediting the .iso file (tricky) Or extracting from the .iso the Registry Hive, modify it after having mounted it on running Registry, then unload it and write it back to the .iso, you will need a Comercial program like Ultraiso, Isobuster or similar ones to be able to edit the .iso, though. jaclaz

If you just formatted the partition, easier way out is using TESTDISK: http://www.cgsecurity.org/wiki/TestDisk It is STRONGLY advised to remove the drive from that PC and attach it to another one as "slave". If you need to perform a recovery of the files (as opposed to partition fixing needed for a wrong format operation with TESTDISK above), you should make a complete byte by byte copy of the drive to another one BEFORE attempting a recovery and perform the recovery on the copy, NOT on the original. AND, you will need enough free space on the "recovery machine" to save the recovered data. A suitable program is the companion of TESTDISK (PHOTOREC) or this program from CONWAY: http://www.pcinspector.de/file_recovery/UK/welcome.htm All the above are FREEWARE. There are severa other COMMERCIAL softwares that might do the job. Depending on the value you think your data has, you might however want to ask for a Professional service, an "easy" job like recovering partition data should be quoted around or below 100 US$, data recovery, depending on how much damage the filesystem has can range from a few hundred dollars to as much as several thousands. This is why it is so important to have a byte by byte copy, should your DYI job fail, you still have the ORIGINAL disk on which a professional can attempt ither methods. jaclaz

You need to edit TXTSETUP.SIF: http://www.msfn.org/board/Switches_TXTSETUPSIF_t14852.html jaclaz

@Ilko_t another question, how did you load the SATA drivers? 1) F6 + floppy 2) TEXTMODE folder: http://www.msfn.org/board/Unattended_insta...ppy_t13173.html 3) TXTSETUP.SIF ONLY: http://www.msfn.org/board/Add_slipstream_S...ion_t77999.html (maybe the last one could "trick" setup into thinking the SATA to be "native" like PATA?) jaclaz

You can use regedit and explore in the: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI Or (more simply) use SIW: http://www.gtopala.com/ or SIV: http://siv.mysite.wanadoo-members.co.uk/ jaclaz P.S.: Yes, but how the "signature number" is generated is not at all clear, not even Daniel B.Sedory, who appears one of the first people to document the feature has a clear take on it. It is possible that some form of "checksum" is generated thus signature on same system (but in subsequent installs) remains the same. However "normal" installs appear to change the disk signature ONLY if it is not already present (i.e. 00 00 00 00).

Doesn't this work ?: http://www.pictview.com/pvw.htm Also, Irfanview should be able to manage .awd files: http://www.irfanview.com/ jaclaz

I'm still a bit lost about it. The rewriting of the MBR on the stick only happens when a SATA drive is present, doesn't it? Can you use an utility like Dimio's HD hacker: http://dimio.altervista.org/eng/ (or any other similar one) to extract: 1) Stick MBR as formatted anew (before starting install) 2) Stick MBR modified by SETUP 3) HD MBR as written by SETUP and attach them in a .zip file so that I can have a look at them? And, sorry, I know I seem a bit tough, and maybe I'm becoming a nuisance but can you re-cap for me if: means that you are running the stick with GRUB MBR and not with the "standard" MBR + NTLDR + Boot.ini with entry C:\GRLDR? Did you try with the second one above (it is possible that SETUP finds a "strange" code (not geometry) in the MBR and replaces it, what happens if the code is ALREADY a Win2K/XP/2003 MBR? jaclaz P.S.: did you also try putting on the stick the appropriate SATA miniport driver renamed as NTBOOTDD.SYS? This might avoid the different order of enumeration of the drives...

Yes and no, it should remove the drivers from Registry (but of course it will keep the existing driver "database"). So yes, once you reboot the hardware will be re-detected and drivers will be re-installed. And no, you won't need to re-install "a large portion of your software", everything should work automatically, like on a normal install, with windows detecting devices and installing the corresponding drivers that are already on the hard disk. The situation is just like when you remove a device from Device Manager. At subsequent reboot the system will detect the device and re-install it's driver. The method, even without sysprepping has been used with success to move a Win2K install on new hardware, see solution #4 here: http://www.windowsreinstall.com/install/ot...board/win2k.htm Quite obviously, on first re-boot the system will take some time to perform the described re-detection, but you won't need to reinstall ANY "user" software. The procedure is better detailed in #8 on the previous link, remembering that the context in which the article is written is that of changing the hardware, somethig you are NOT going to do. An exception may be some proprietary software whose license serial number is linked to the PC SID, i.e. those softwares that when installing produce a "challenge code" that you have to send to the software manufacturer to get the corresponding "response code", but this kind of software will need to be re-installed and re-activated or whatever anyway if you just re-install the system. jaclaz

hmmm, I don't get it, you CANNOT copy a MBR from stick to hard disk, the partition entry will be invalid (due to different size and geometry of partition) AND disk signature will be duplicated, which has been proved in the past to be a NO-NO due to the problems it causes in drive letter assignments; can you better elaborate? I may be wrong, as often happens, expecially when guessing an undocumented or poorly documented feature, but I think the right approach could be to create a second migrate.inf entry for the SATA disk, linking it's first partition to C:, directly from scratch as per these posts of mine: http://www.911cd.net/forums//index.php?showtopic=19663 http://www.boot-land.net/forums/index.php?...c=2085&st=3 And find a way to write the signature to the SATA drive before starting install. Signature should not be altered by FDISK /MBR or whatever similar action setup does when booting to prepare the HD. This would probably lead (through a signature syntax boot.ini entry AND the appropriate SATA driver copied to root as NTBOOTDD.SYS) to make setup correctly attribute letter C: to the SATA drive. If you could experiment a bit in this direction manually, we will later see if and how it is possible to replicate the procedure automatically, though this would probably mean having grub4dos/grub.exe and some flavour of DOS on the stick, thus, alas, substantially back to square one of the original method 1) through DOS and WINNT.EXE. jaclaz

@wimb Happy to hear a story of success! This is a very interesting report, for two reasons: 1) it confirms that when booting Windows can use NTBOOTDD.SYS even if it is a ATAPI driver, not only SCSI and SATA, I am very interested in this as it is another little step on the road of using the possibility to use ANY driver, as long as it is a Miniport one, to boot. 2) it confirms that the signature sintax works perfectly, though with a delay What would be interesting, if you could make some tests and report, it would be to understand whether the delay is due to: a. the "sheer" presence of the signature syntax (hence the need to scan Hard Disk(s) MBR to check it b. the presence of the Miniport driver renamed as NTBOOTDD.SYS (maybe different timings in initialization that cause the delay) Proposed testing (given that you are familiar with procedures needed should the system become unbootable): 1. Only re-copy the NTBOOTDD.SYS to root of drive 2. Only re-add the signature syntax line in BOOT.INI 3. Both of the above I have not any SATA equipped hardware, but I don't think that what you suggest is feasible/useful, as when you run the WINNT32.EXE C: will be almost invariably the First Active Partition of your First Hard Disk, and NOT the USB stick, moreover, if I am not mistaken, executing such a command will modify your "resident" BOOT.INI to start install at next reboot of the PC.... Cheers, jaclaz

Well, basically once you have stripped the SID from the machine, at next reboot Windows won't (obviously) find one, and thus will re-detect hardware and ask for Product Key. For the intended use of the sysprep tool, which is: 1) Doing a complete install with all settings configured 2) Removing specific hardware/machine settings 3) Image (clone) the system 4) Deploy system to other computers 5) Boot the other computers to let the minisetup find the changes (including individual machine SID and Product Key) It is of course VITAL to make the image immediately after the stripping has been done, otherwise on next reboot the stripped info will be re-detected and re-applied, thus making the install once again "machine dependant". Since you don't need to deploy the system, you also do not need to image it after "sysprepping" it, on the contrary it would be a VERY GOOD idea to image the system BEFORE attempting using sysprep on it. jaclaz

Yes, you need to change the serial info on your current install. Unfortunately, unlike XP, there is no "simple" freeware solution I know of. You can use Sysprep to change SID and product key, but it is not a really straightforward chore: http://www.microsoft.com/downloads/details...;displaylang=en but of course, since you are not, at the moment, a "Genuine user" you will need to download it from another PC. The procedure should be this: Since you are not changing system, this should be enough: sysprep -reseal -quiet -mini But DO READ the docs of the utility and search some more info in it BEFORE attempting the above, here is a very well made guide: http://www.vernalex.com/guides/sysprep/index.shtml jaclaz

FYI, and for the record, 52 is valid as well, but it is ususally a CP/M one: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Are you sure it was 52 and not 42? besides being the answer to the Ultimate Question of Life, the Universe and Everything , 42 is a valid partition identifier, but it belongs to "Dynamic Disks" : I have seen systems on which (reportedly by "black magic", but most probably by a failed attempt at fiddling with Dynamic Disks), the partition type has been changed to 42. jaclaz

Well, it is a pleasure, and by the way that's the base of a tech forum like MSFN is, to exchange ideas and (hopefully) find solutions. Just as an example, at the time of the 911CD post I was convinced that to have NTFS one would need to complete install as FAT/FAT32 and later run convert.exe, now, if I get it right, you just pointed out and confirmed that Windows Setup can convert the filesystem to NTFS even if the source files are on it? jaclaz