Siginet

I have been trying to figure out how to do this but I have had no luck. Is there any way to use NTFS4DOS without having to type "YES"? I tried to find the pay version... but could not find where to buy it. So basically if I boot regular dos first then launch ntfs4dos with a usb dos driver I should be able to see my usb drive (Formated with NTFS) and somehow have it autolaunch a batch script to copy the needed files to the correct place. If someone can at least make me a dos bootable img file that is completely automated to see my ntfs usb stick and point me in the right direction for automatically making it launch a batch file that would be great. Then I will create a batch file that will copy the needed files for converting between different Windows XP OSes. Thanks, Chris

You need to use a program that will compile your iso with optimization. Basically it will make the disk look like it has many files on it but any files that are the same are only written to the toc once and pointed to multiple places. Using a method like this you can fit every different version of Windows XP on 1 CD! Windows XP PowerPacker can simplify this process for you.

flyakites site is perfect. If you are having troubles you may want to try my program "Windows XP PowerPacker". It will allow you to multiboot all versions of windows xp. It may get you started on your road to figuring out what may have went wrong.

I didn't think autoit3 files worked during the pre setup phase. In the past I tried creating a much better setup.exe based on pyrons method. But I was very dissapointed to find out it wouldn't work with autoit3 files. I almost thought you found a workaround. I hopefully will get some time to test out your mini iso idea later this week. I am very eager to try my idea with multiple mini ISO files.

Now that is a great idea too.

That sounds very cool! Could you give me an example of your presetup.cmd file? Now it's got me thinking. Would something like this be possible... Could we create our mini ISO's with the needed files and edits you have above. Plus add only the needed files which are different between different versions of XP. Like XP Pro OEM / VLK / Retail. So that when setup is performed those files are placed into the setup? This way we could simply have the entire disk from XP Pro OEM on the USB Stick. Plus mini iso's of the others. XPPROVLK.ISO, XPPRORTL.ISO. During setup all of the XP Pro OEM files would be placed onto the drive through txtmode setup. But the files for VLK or Retail would overwrite the OEM files just before Guimode. I'm really curious if it would work. As you know. Thats exactly what I have been looking to do for a long time now. I'll test out your new method sometime later tommorrow if I get a chance. Thanks!

If you know the name of the server you may be able to get the ip by doing a simple ping to the server. As long as they don't block pings. cmd.exe: ping [servername] If you have rights to chaange your IP information on your computer go ahead aand see what your IP info is. Look at what is listed for DNS. If they look like internal IP addresses then maybe swapping the dns's around will do the trick. But be very careful when changing IP info. You don't want to make an ip conflict.

There are a lot of reasons for the delay. Roaming Profiles is one. Basically it needs to download the users Desktop/My Documents and so on to the computer each time it logs in. So it could cause logins to take quite a long time if you have a lot of files. I am personally not a fan of Roaming Profiles. Another big reason it can take a lot longer to login could be an incorrect DNS setting. If the dns is incorrect it can take much longer to login. For instance let's say your IP of the computer is like this: IP Address: 192.168.1.101 Sub Net: 255.255.255.0 Gateway: 192.168.1.1 DNS1: 192.168.1.1 DNS2: 192.168.1.2 In this example DNS2 represents your Servers Ip Address which handles the DNS for your local network. DNS1 is the IP of your Internet Router. The problem with the example is that DNS1 is the internet and DNS2 is the server. So in this case when a user logs into their computer the computer thinks it is supposed to authenticate through the Internet IP. So it goes to the internet looking for its authentication server for a while. Until it times out and goes to DNS2 and authenticates rather quickly on the server. So the way to fix this is to swap the IP's so that 192.168.1.2 is DNS1 and 192.168.1.1 is DNS2. This was an exact issue I had on one of the first networks I setup and I think is a very common issue. It can also make many things on the computers connected to the network to have delays. To fix this you just have to go to the device that is handing out DHCP and make sure it hands it out correctly. Or you can input the computers IP info in statically on each computer. Hope this helps.

With Windows XP PowerPacker you can put all versions of windows xp onto 1 disk and select which one you wish to install from the boot menu.

I'll be palying it online with my Xbox360.

Wow Happy B-Day Boss man! Everyone have a Virtual Beer on my tab!

Sounds like wherever you bought the computer from installed the computer with a corp disk. It tends to happen at some computer shops that aren't very smart. Does the computer have a product key sticker on it? If so then what type of OEM is it? If it is a dell computer and you have your dell disk then you can reinstall the computer with that disk and it will preactivate just fine. Another method you can use is to convert the installed OS to an OEM with "XP License Changer Kit" or XLIC for short. It is actually an unsupported way to do this. Not many people have heard of it. But it does work. Once you have converted to OEM then you can use a Key Changer Program to change your product key to the one on your sticker. Or you can type this into the Run box: "%WINDIR%\System32\oobe\msoobe.exe" /a This will try to activate... then fail. Then gives you the chance to change the product key. Good luck. I hope this bit of info helps you.

I am pretty positive that the repair method is exactly the same for XP Pro and MCE. All you do is use a windows XP MCE install disk that does not have a winnt.sif file. Boot the the MCE disk as if you are going to install windows. The first repair option is for the Recovery console. Do not select it. Select the next Repair option that comes later. Now it will do a repair install. It looks just like a regular install of windows but all of your files, settings and programs aare sved. But this does not allways work well. Sometimes it will mess up some of your programs and force you to reinstall them. It's baasically a last resort before Formatting and reinstalling the computer. Good luck. Hopefully all goes well.

Here's a few questions I have: 1. If I loaded an iso to ram... and then loaded a second iso to RAM again... would existing files be overwritten? The reason I ask is this. We know that all different editions of XP Pro use the same exact files... except a small amount of files are different. If we could load an ISO of XP Pro Corp to RAM... and then load another small ISO on top of it which only contained the different files for XP Pro OEM... would it actually change the ram install into XP Pro OEM? 2. Also... can I mount an ISO onto a HD instead of into RAM? for instance if we could... then we could create a normal USB XP install stick with XP Pro Corp... and then mount a small iso with the different files for XP Pro OEM conversion. Which would overwrite the ones on the hd. 3. And my last question... Is there any way possible to use a cd/dvd... and somehow mount that small iso into RAM in a way that would map those files to trick windows setup into thinking the files in ram where the files on the disk. Since CD/DVD ROM's are not writeable... this would be really cool if we could utalize the memory to make it look like the drive is writeable. I doubt this is possible right now. But it would be something cool to think about for those who have created drivers like this which allows us to do things we normally couldn't do in the past.

You know what... I feel so dumb. The unattended answer files I was using were blank. LOL! So I guess this just hasn't been my week. I've been troubleshooting creating a USB Bootable RAM ISO all week and most of my issues were my own fault. If someone wants to remove my useless posts in this thread it's fine by me. I feel so embarressed that I'd even let the simplest things like this slide by me. LOL! This is what I get for being out of the loop for so long. Guess it's time for me to start coding something again.

The HD swap trick worked: map (hd0) (hd1) map (hd1) (hd0) So now setup boots into guimode as normally. But this means most of the computers I want to install will be incorrect right? If so... I have an idea... Couldn't we have it so that before the iso is mounted there is a 3 second option to input the swap trick? If there is no user interaction it just uses the regular method. My sencond problem is still not working yet though. I tried putting the w*.sif files on the floppy img but it still doesn't recognize them. I'll try some other stuff and see if I can figure it out and I'll keep you posted.

BTW I just thought of some more important info that may lead to the reason for my incorrect boot.ini. My computer did have Windows 7 installed before I wiped it out to install XP from the RAM ISO boot method. Windows 7 creates a hidden Partition and then a second patition where it installs Windows. I remember when I was at the portion of setup to Partition the drives I noticed that Windows Setup had reccognized the Hidden Partition as the C: drive and the Windows 7 partition as a different letter. I deleted both partitions and then continued with the XP install. Maybe this can lead to a clue as to what happened. I will attempt to install windows XP again now that there is only one partition and see if it installs correctlly.

LOL! Ok... now I was able to make a multiboot ISO that worked. I had a couple of problems though. 1. It seems that after txtmode setup Windows Guimode setup was unable to start because the boot.ini was incorrect. It was: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect I had to correct it like this: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect once I changed it then guimode was able to boot successfully. 2. My second issue I think may have something to do with me patching setupldr.bin files to use different winnt.sif files. Because when guimode setup was running it ran as if there was no unattended answer file. Here some extra info on how my powerpack install disk is setup: In the boot folder "XPPC" which is on the root of the disk you will find all of the "boot files" (Just like in the normal method). In there is the default setupldr.bin patched with "i386" to "XPPC". Plus a copy of setupldr.bin which is named "XPPC.bin" the XPPC.bin file is patched with "i386" to "XPPC" plus all instances of "winnt.sif" are patched to "wXPPC.sif" There is a wXPPC.sif file also in the Boot folder. This is the Unattended Answer file that should be used. On a regular multiboot disk this works fine. But in the RAM ISO boot method it doesn't seem to work. Any ideas?

Woops... I can put my foot in my mouth now. I just realized I was using a test version of PowerPacker... and the patching of setupldr.bin was broken. The release that is online for everyone to download is working fine... but the version I was using is broken. Guess that explains why I never released it. Sorry for the trouble everybody. I have it sorted now. I guess it would have been smaart to take jaclaz advise when he said wouldn't it be easy to just check the file in aa hex editor? I was certain that wasn't my problem... but it was. All instances of i386 were not changed to XPPC.

I did... but my setupldr.bin file is from sp3 which is much different then the one from sp2. I allready know that i386 is to be changed. Which is also done in powerpacker. What I mean is... is there an area that needs to be specifically patched like is done to 2003 SP1 files. At 0x2060 "74 03"needs to be changed to "EB 1A" on 2k3 sp1 setupldr.bin files. But on my xp sp3 setupldr.bin file it does not need to be patch like this in any way and it works just fine on a cd/dvd. But for some reason does not work using the iso ram boot method used in here. So I have narrowed down it is not an error with powerpacker per say... but if there is a patch for xp sp3 setupldr.bin files that is needed differently then the way I do it in powerpacker I am curious to know it.

I'm pretty sure powerpacker does patch the files. It's been a long time since I have coded powerpacker. But I remember I had to patch setupldr.bin files. PowerPacker actually uses multiple setupldr.bin files in its boot directories. And it patches them so that each one can use a different winnt.sif file. So basically a setupldr.bin file renamed to xppc.bin could use a winnt.sif file named wxppc.sif and another setupldr.bin file would be named xopc.bin and use wxopc.sif and so on. You guys may be right though. It could be possible that in the later versions of powerpacker I did not need to patch the setupldr.bin files. But I am almost positive it does. Guess I gotta look into the code. Edit: OK... I have confirmed that PowerPacker does not need to patch the Windows XP x86 setupldr.bin file. But it does patch 2003 SP1 setupldr.bin files. But I could not find any information on how to patch Windows XP SP3 setupldr.bin files. So is there a place to patch these files? When I use my XP SP2 setupldr.bin file it does work. But is there a file hack available for SP3 setupldr.bin files? As far as I can find the XP setupldr.bin files only need to have i386 changed to another 4 characters plus winnt.sif changed if you wish to use other answer files. I can just use my SP2 setupldr.bin files for now... but I would like to use SP3 setupldr.bin files. Are you guys using SP3 setupldr.bin files in your tests? If so... I'd like to compair my setupldr.bin files with someone's who is working. Thanks!

This indicates: setupdlr.bin dosn't find ntdetect.com. Which bootloader do you use by default? Can you try grub4dos? Do you hexedit setupldr.bin? i386 --> XPPC I wonder, does some configurations require root (0xFF) ? Try root (0xFF) chainloader (0xFF)/XPPC/SETUPLDR.BIN Try the CD image bootloader too chainloader (0xFF) It works when I create a cd/dvd. If I remember correctly powerpacker uses bcdw for the boot menu. It references SETUPLDR.BIN files to launch each os. The only main difference with powerpacker and the normal method is powerpacker has no need for the XPPC.BIN files on the root of the disk. It launches directly from the setupldr.bin files. Just like grub4dos is. So I can't figure out what may be going wrong. I tried my old SP2 disk and it works fine. But whenever I try a powerpack disk it doesn't. Could someone else verify if they have the same prob with powerpacker? If it is a bug in powerpacker then I can fix it.

I'm having trouble getting a multiboot iso to work. I have created a multiboot ISO with XPPC and XOHO. which represent XP Pro Corp with DriverPacks and XP Home OEM without DriverPacks. Neither of them seem to be working. I get to the point where it mounts the ISO which seems like it is successful because it takes about a minute to do it. but then the computer just restarts and never goes into txtmode setup. Here is what I have done: I placed the floppy image on the USB stick: \Inst\XP_INST.IMA I placed my ISO here on the USB Stick: \Inst\XP_RAM.iso I uncommented this in the txtsetup.oem inside of \Inst\XP_INST.IMA: dll = setup, ISOimage.ini Here is my menu.lst: title Windows XP Multiboot ISO Setup root (hd0,0) configfile /XP_RAM.lst savedefault And here is my XP_RAM.lst: title XP PRO install - write /Inst/XP_RAM.ISO ls /Inst/XP_RAM.ISO || find --set-root /Inst/XP_RAM.ISO map --mem /Inst/XP_INST.IMA (fd0) #optional, (fd1) required at some BIOS #map --mem /Inst/XP_INST.IMA (fd1) map --mem /Inst/XP_RAM.ISO (0xFF) map --hook write --offset=0 (fd0)/setup/ISOimage.ini \\Inst\\XP_RAM.ISO\n;\n;\n; chainloader (0xFF)/XPPC/SETUPLDR.BIN title XP HOME install - write /Inst/XP_RAM.ISO ls /Inst/XP_RAM.ISO || find --set-root /Inst/XP_RAM.ISO map --mem /Inst/XP_INST.IMA (fd0) #optional, (fd1) required at some BIOS #map --mem /Inst/XP_INST.IMA (fd1) map --mem /Inst/XP_RAM.ISO (0xFF) map --hook write --offset=0 (fd0)/setup/ISOimage.ini \\Inst\\XP_RAM.ISO\n;\n;\n; chainloader (0xFF)/XOHO/SETUPLDR.BIN The ISO itself is only 680 MB. Any ideas? Edit: Further info... I created the multiboot structure using Windows XP PowerPacker. Which isn't much different in how it creates a multiboot disk then unattended.msfn.org

I'm not sure if nLite creates the OEM folder. But I can explain the differences. The $OEM$ folder is a folder you can use for special installation precedures built into the windows install prosedures. The OEM directory may have been created by integrating DriverPacks, Or OEMScan Addons. It does not have the same functionality as $OEM$. It is built into some of the other integration tools used with multiple tools found on msfn and other websites.

For those of you who use LogMeIn you may have noticed a lot of new changes with the software. Which seems like it is a great thing. The new system seems to be a lot better. With the new system they have allowed a 30 day trial of their Pro2 software. I noticed that there is an annoying bug in it though. I usually will click on the computers name when I wish to Remotely connect. But today whenever I do that I get DNS errors and I can not remotely connect. But if I use the icon to the right of the computer name it seems to log in fine. I just wanted to share my findings online for others who may come across this issue. Because I know for myself it is very important that I am able to remote into my PCs. hopefully this info is useful to someone.