Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

What is the Best PXE Environment: WinPE, BartPE, Linux, or DOS?

Updated: 05 May 2008 | 14 comments
MyersW's picture
+1 1 Vote
Login to vote

So the debate went through our office about what is the best pre-image environment... WinPE, BartPE, Linux or DOS. Consequently, we tried to do a complete analysis of many of the factors and determine what is really the fastest route to take. In the end, it all comes down to how quick we can get our imaging done and move on to other projects.

We took an older Compaq D5M as workstation to image and ran it through some tests. The workstation has a 10/100 MB NIC and was imaged from a server across a LAN link. All networking equipment in the link was at least 10/100 MB. We first pulled down a 4.5 GB image using each of the pre-image environments. What we found was...

Environment Time Approx. Avg. Speed
DOS 20:29 10-15 Megs
BartPE 11:46 60 Megs
WinPE 11:44 60 Megs
Linux 15:42 45 Megs

The associated load times for each pre-image environment is...

Environment Time
DOS 11 sec.
BartPE approximately the same as WinPE
WinPE 1 min 48 sec.
Linux 24 sec.
Caution! You may need to read this first - How to Manually Run the Deployment Toolkit Tools in Automation. This is what we had to learn the hard way. When imaging with both WinPE and Linux you may need to assign a Wait Job to the computer before booting to that pre-image environment.

Conclusion:

Although Linux did not have the fastest pull down time it does have some other considerations that made it a direction that we wanted to take for certain applications. For example, with WinPE and BartPE we had to worry about drivers which are sometimes harder to find for those environments than the Linux. We also have the consideration that many times we need to PXE boot computers across a WAN link and thus the pre-image load times become inflated by 3 to 5 times their value within the LAN.

So in most cases, we prefer a WinPE/BartPE environment but in outlying sites we use the Linux environment because of the stated increase in PXE boot times. Overall, moving to a 32 bit environment is an important step in efficiently deploying tens to hundreds to thousands of computers!

Automation:

The next question was how do we get these images to deploy without having to physically touch each machine in a linux?

We were able to set each of the PXE environments to map to a network drive then command-line the imaging but that still meant that we had to touch each machine. Our conclusion was that if we could command-line the code we should be able to automate it. For a large percent of us, vb programing is not as hard as Linux programming, but after a couple of trial and error misses. One of my co-workers, came up with the Unix scripting for automating the job...

Create a new deployment job and select 'Run Script.' Under 'Run this Script:'

sleep 1
/mnt/ds/rdeployt -md -f /mnt/ds/filepath/file.exe

Next select the radio button next to Automation pre-boot environment and select your Linux PXE boot option.

Side note: We are not Linux administrators so there is probably an even more efficient way to do this but it worked for us. It took us awhile to put all these pieces together but hopefully this will make life a little easier for you! Thanks go to Glenn Acheson and Adam Jefferson for all their hard work on this extensive project.

Comments

eorme's picture
05
May
2008
0 Votes 0
Login to vote

Why do it manually?

I'm curious why you chose to do a run script task and manually script the call to rdeploy. Why not just do a "Distribute Disk Image" task in DS and select the linux preboot?

MyersW's picture
07
May
2008
0 Votes 0
Login to vote

Remote Servers

The reason is that DS will only allow you to pull images off the main deployment server and we wanted to pull images off any share that is connected to the network and is within the local LAN instead of pulling across a WAN link at excruciating download/imaging speeds.

chi-user's picture
18
Aug
2008
0 Votes 0
Login to vote

Linux PXE rdeploy

Not true. You can deploy images from anything that is mounted. We use PXE redirection (set up in the PXE Config Manager) to point machines at each site to a site-customized Linux image that mounts the image share on that site's package server. You can make these customized images easily with the Altiris Boot Disk Creator. We run DS 6.8sp2

Swami's picture
06
May
2008
0 Votes 0
Login to vote

Good Info

Hi,

You have made a good info. May be for corporate users, this may be the best. But for individual users (Home) with stand alone PC, I bet DOS is the best with the plain old ghost. Last to last week, I have recovered my friends PC in less than 3 minutes of time after a nasty spy ware mess up. The image was stored in a DVD and the same has been kept on the hard disk too for quick remedy.

Regards,
Swami.

eorme's picture
06
May
2008
0 Votes 0
Login to vote

Makes sense.

Ok, I see what you're going for. DS is not a product for home users. Personally when I back up my home system I use system rescue CD which does the job, but if you're in a corporate environment there's nothing better than DS.

As far as PXE environments, in my opinion, DOS just doesn't cut it anymore. Just give me Linux, and I'd take bash over VBScript any day.

Nebster's picture
06
May
2008
0 Votes 0
Login to vote

Linux is better for Home as well usually

Swami -
Well, I use Linux for home as well. It really is a great OS (much better than Windows at least) but isn't supported as much and is a bit like DOS (very command-line orientated)

MyersW's picture
07
May
2008
1 Vote +1
Login to vote

Actual you can use rdeployt.exe at home too....

I actually backup my home computer to a USB hard drive using rdployt.exe. First you will need to copy rdeployt.exe from your DS server eXpress share onto the root of your hard drive. Then by booting into BartPE and calling the executable you are able to backup and pull down the image just as you would otherwise in DS.

This is similar to the process that we use in remote sites that have low bandwidth but need imaging capabilities that don't take an hour or two. First we pixie boot to the NAS in either WinPE or Linux(preferably) and then call either rdeployt.exe or rdeployt. With a NAS we are able to pull down images in 15 to 20 minutes on a 10/100 Meg network or 7 to 8 minutes in a Gig network.

dfrancis's picture
06
May
2008
0 Votes 0
Login to vote

I've always preferred Linux

I've always preferred Linux automation, but without having really much of any Linux background at all, support is a bit of a challenge. We had to move to WinPE about 4 months ago due to some driver incompatibilities concerning newer hardware with Linux automation, but I've been told those issues have been taken care of since then -- haven't had the time to move back.

We have remote PXE servers that also function as image stores due to slow connections between the remote sites and the DS, so we were able to easily do a lot of scripting within Linux to quickly figure out which subnet the machine was on and automatically map a share to the appropriate image store and pull the image from there.

Converting my scripts to WinPE took a relatively small Linux script into some rather ugly VBScript to achieve the same thing.

--Dave

If a forum post solves your problem, please flag it as a solution. If you like an article, blog post or download vote it up.

Nebster's picture
06
May
2008
0 Votes 0
Login to vote

Linux is usually better

Yeah, Linux is much more advanced in this sense. Also, if that doesn't work, there's nearly always a C++ compiler installed ready to use which can do virtually anything

MyersW's picture
07
May
2008
0 Votes 0
Login to vote

Love to see...

I would be interested in seeing your script for that! Or at least if you could point me in the right direction.

Pikoshi's picture
08
May
2008
0 Votes 0
Login to vote

Why not use PXE redirection?

Why would you need scripts to direct a remote PXE server to point to a different image store when you can have the PXE server do it for you? We have our shared PXE profile then a profile for each remote PXE server that maps a drive to the local image store. Works really well without having to have scripts.

If your question was answered, mark the anwser as the solution
Give thumbs up if you found a post helpful

Chubbs79's picture
06
May
2008
0 Votes 0
Login to vote

RE: 'I've always preferred Linux' by dfrancis

Try using netmask ordering in DNS instead of scripting for subnet issues. That way you can map to the same share and you will connect to the local IP.

Matt S's picture
08
May
2008
0 Votes 0
Login to vote

When it comes to deploying

When it comes to deploying an image using the distribute task, you can easily use an alternate path. You can do one of 2 things.

1. map(mount) the extra share using a script prior to deploying the image.

2. Modify the PXE boot image to mount the additional share. This works if it is fairly static.

Once it is mounted, when you distribute the image, just give it the full path to the image and uncheck the box to verify the image path.

It would get around your 'odd' delay issues...

Pascal.KOTTE at BECHTLE's picture
06
Mar
2009
0 Votes 0
Login to vote

THE choice is: WinPE + GHOST

Hi, we are using WinPE in preference for most site. From 50 to 1500 PCs. But we are using DFS instead of REDIRECTION when possible. We were using Linux also, but more & more drivers problem:

  • because machine too "young": so you have to search & compile the linux drivers...
  • because machine too "old": so you have to search & compile the old linux drivers not any more in the latest Default Linux Altirisi preboot !!!

As long the client are wunning Windows, best choice is to use WinPE, because of the drivers already there... Less work to do, all the same longest preboot image to load.

And now with the "Hot imaging" option, Ghost is the best choice. Moreover: it is the Symantec strategic designated choice.

~Pascal @ Bechtle~ Do you speak French? Et utilisez Altiris: venez nous rejoindre sur le GUASF&l