What is the Best PXE Environment: WinPE, BartPE, Linux, or DOS?
Filed under:
Deployment Solution
Automation, UNIX/Linux, Best Practices, Imaging
Submitted by MyersW on Mon, 2008-05-05 10:53.
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.
(48 votes)
- Login or register to post comments
- 2343 reads
- Printer-friendly version
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?
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.
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.
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.
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)
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.
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.
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
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.
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.
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.
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...