Anyways...  made an enhanced version for the VM utile, and its truly portable. that is, all u need is VMware, to use it.
I am not saying it is the pinnacle of creation, but I do believe it is worth a glance ( if u made it reading this far)
http://www.ultimatedeployment.org/forum … &t=248

IDK you tell me...
dvds cost money you mean at 20 cents each that would break your budget? and a dvdrom is $10?
sounds like you need to stop working for free...

It just might... :-\
Going through a rough patch at the moment... been livin on Ramon noodles and haven't paid bills in 1 1/2 months so that I could get xmas gifts and not feel totally ashamed... but that is nobody's issue here...

I poke around rougespear's forum and see if I can come up with something.. and I know everyone is quite taxed out with other projects.

it sounds like a great idea check with rougespear and take a look at how he does RIS with autoimage.

dvds cost money you mean at 20 cents each that would break your budget? and a dvdrom is $10?
sounds like you need to stop working for free...

is there anyway to PXE boot... and then install windows from an ISO image?

Basically I'm pretty diverse. Sometimes I will be loading several system at once... While others only one at a time. CD's/DVD's cost $$ and can get lost/damaged quite frequently (and I don't happen to be a computer shop... so spare hardware is slim to come by). Anyways what I'm saying is that if there is an option that would allow me to make one windows image that could be installed from the network as well as a CD (without altering the code every time I decide to switch source)... that would be Ideal, however I don't know if that it is possible to somehow PXE boot and then mount/install from an ISO...

The whole point to remote installs is they are done remotely!

the normal driverpacks method works perfectly "out of the box" for local installs (scratches head in confusion)
Even if the stations have no floppys or CD/DVD you could hang one off the system long enough to install windows. This is faster easier and doesn't require you to spend hours reinventing the wheel. you could hang a dvdrom off a hundred machines in the same amount of time you have spent on this. (since you are AT the machine and not at a remote location) silly boy.

however... I was interesting in making any system install/run Python, BINL, TFTP32 as well as a network share from. this would be nice instead of taking a laptop with me everywhere... and also handy if the system doesn't support booting from USB...

you can load an iso image with a plugin for bartpe (see the ubcd4win forum) however it has a 512 meg limit on the iso. so you would not be able to do this directly you would need to boot to bartpe then launch setup.
(since a slipstreamed image would exceed 512 meg)

IE copy all UWXP files and an iso image that contains bartpe or some other PE that runs a setup that is not in the iso but also on the flash drive.

I'm assuming this makes use of the 'linkd' command available in windows (if the linkd file is extracted)

Seems so I didn't know about that command.

Found a way to do it: http://www.pearlmagik.com/winbolic/

I'm assuming this makes use of the 'linkd' command available in windows (if the linkd file is extracted)

OverFlow wrote:

hidden feature? you mean like mapping it that way? or useing subst command...

huh?

I was saying that from what I read, that nothing outside of the I386 folder is seen... however, ironically the "$OEM$" folder still works like normal... Why can we not move the OEM folder contents into the $OEM$ and process the driverpacks in that manner or the exe's to $OEM$ and the driverpacks to I386 so they can be 'seen'?

Overflow's response was meant for me; I wrote:

So.... 2nd copy of i386 then....? (since windows does not use Symlinks.... or is there a 'hidden' feature that allows it?)

As Overflow earlier wrote:

So in order to have 1 copy of i386.... it would be great to have something like the unix Symlink feature....

Found a way to do it: http://www.pearlmagik.com/winbolic/

hidden feature? you mean like mapping it that way? or useing subst command...

huh?

I was saying that from what I read, that nothing outside of the I386 folder is seen... however, ironically the "$OEM$" folder still works like normal... Why can we not move the OEM folder contents into the $OEM$ and process the driverpacks in that manner or the exe's to $OEM$ and the driverpacks to I386 so they can be 'seen'?