iamtheky

i suppose you could also: set programfiles(x86) = "%systemdrive%\program files (x86)" at the top of setupcomplete, and then proceed as you were (so that its logical for future additions). But i would certainly do a dry run where it echoes everything with the new variable you create for confirmation. There is also the registry recommendation here: http://911cd.net/forums//lofiversion/index.php/t804.html

That is awesome, in my experience with Dell in the US I just get a return label in the box to ship back the old one.

How did this move from a call where they send a new HDD, to one where a tech comes and installs windows 7 on the new drive, then a few days later returns for the old drive? That is some **** serious RMA service in India.

I agree, the only issue here should be joining it to the domain. The following are questions and have not been attempted by myself, if anyone tries this I would like to know the results. 1) Load RSAT (KB958830) into the PE that drives your unattended install. 2) Run NetDom commands from setupcomplete.cmd to join the machine to the domain.

if you put anything in setupcomplete.cmd does it fire (or is it just this specifically that is failing)? If no: is there something in winpeshl.ini? If yes: Does it work from runonce?

like this *this is assuming windows 7 and these drivers are signed.

inferences of gratefulness aside, still stands that i believe OP is looking for another finished product, without a solid grasp of what is occurring within.

You dont have to attend anything and dont use Hirens because its warez. Just use a legit PE of your choosing and automate the diskpart then execute your install.

Assuming you have autoit and Scite already downloaded: I would recommend copying chipsers script and going line by line hitting F1 until you understand what its doing. If you have questions about anything in particular I am sure you will get plenty of help (but I am very cynical and beginning to think you did not write nor completely understand the batch in the original post as you keep asking for the same thing in different forms like it matters).

indeed, i seem to have let imposed requirements appear as my opinion as all of our approved wiping software still uses the 7 pass method. After reading more, that is probably an arbitrary requirement.

sdelete with a couple of passes or DBAN the drive. I wouldnt focus on the fastest way so much as the most effective, or youre not really focused on security.

i would assume so, though none of my boot.wim(s) are exactly standard but we use startnet to verify the system and initiate our custom deployments since its the first thing to fire.

what about making it the first thing done in startnet.cmd, then calling your install from there?

That was never the accusation, I promise. Just asking if it was the MS or a GPL version. you can go get one from FreeDos at the link below (you are not legally supposed to distribute the Microsoft file from my understanding). http://www.freedos.org/software/?prog=choice and put a text document in the zip with that link and the link below. http://www.gnu.org/licenses/lgpl.html That would be proper, imho.

MS vs GPL not so much MS vs his own If its MS then it shouldnt be distro'd... and that attachment should be removed?

thanks. My concerns about choice.exe still stand.

I think I may be missing why you want MDT in the mix... ...But we do absolutely no manipulation of our XP wims once they are captured, I see that your screenshots have one wide open in the toolkit. So a few lines to deploy the image in startnet is all we need in the XP deploy boot.wim that is offered from WDS (net use i:\blah , imagex /apply i:\blah\xp.wim 1 c:) Unless you have ridiculous amount of XP images to maintain for many different systems. I would certainly like to know you reasons for wanting MDT to handle them in case I can improve our process. *making it a bit more legible, instead of the stream of thought it was initially

the user in post #5 does it just fine while their may be limitations for MDT (idk cause we dont use it), WDS serves XP images just fine. I dont see why you would want to do anything but the most basic of push and pulls for a .wim you will be unable to service, and is HAL dependent. You could make a boot.wim for each of the hardware with commands hardcoded in the startnet, and let XP clients use the boot menu to select which one they want. Or even a single boot.wim to detect the system programatically and auto deploy without much effort.

Sure, but how is that advantageous over doing this in setupcomplete.cmd with 1) an install command 2) reg add/ reg del command 3) and a del command or copy and del command for the shortcut file It seems that I have to write that stuff out multiple places, then make sure all this stuff is in the right place -VS- just writing once in setupcomplete.cmd which works on both architectures. And the au3 looks like it could be a much tighter loop, what is Send("!{}"), because it looks like send ALT + nothing, or send ALT + left squiggly bracket then right squiggly bracket, both seem odd.

There are far more simpler and even native ways to accomplish what I believe I have understood this script does (which is just install some apps). Maybe you can clarify if this facilitates something that I am not understanding. And if this is the GNU licensed version of choice.exe you should point to the source and the hash to be verified. And if its not, you might not want to be distributing that.

that sounds very close to, if not exactly my symptoms (completely empty context menus). Fully functional, Many thanks Iceman

That may be what got me last time, I think I threw them all in sys32, rather than their respective folders, I'll retry this week. Thanks IceMan, I got distracted with other issues and this nicety fell by the wayside.

we do it with our WDS. It serves up the boot image, which in this case is just standard with a starnet.cmd that A ) maps a drive to a folder on the WDS itself with the net use command. Lets call that i:\images. B ) Then runs " imagex /capture c: i:\images\XPtest.wim 1 " then subsequently any drives that need appended to that wim. --running this line manually should verbosely function or fail -- then i would go back to automating it. **Of course you get HAL with this method and it will only go back onto the same or very similar machines.

ghostscript with ghostgum GSView

I assume some are older just based on the variety and type of Dells (maybe not, just our optiplexs are 5 years old). Nonetheless, if you have not given uniextract or 7-zip a chance to extract those .exes, I would do so and see if you get lucky. Additionally I would check on the original systems to see if the driver being used is signed. You could very well spend time getting the correct driver files, only to find out they still do not play nicely during an unattended install (we only had to do that 3 or 4 times before we opted for some after install actions).