Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work at the help desk for students, faculty and staff at a large university. As part of our daily operations we see ourselves installing every version of windows (xp, vista, 7; both 32 and 64 bit of each) and we are trying to find a way to reduce the need to continually burn CD/DVD's, and automate the workflow of the process. Ideally we would be able to plug a laptop into our 24 port switch have it boot from the network ( I have two old IBM servers that can be completely dedicated to this) and then be given the option to select what operating system to install on the clients machine. Additionally, if at all possible we would be able to boot some diagnostic .iso's over the network as well ie, memtest, sea tools, live run ubuntu.

I've done quite a bit of reading on this and keep running into a couple of problems with the potential solutions out there. 1. The computers that come in for imaging are every make and model from every manufacturer you've ever heard of, meaning identifying all applicable drivers is going to be close to impossible. 2. The computers that come in arent part of our active directory and shouldn't be upon being imaged 3.The software that should be installed along side the os is likely going to very from install to install, is there a way to choose what additional programs get installed on a case by case basis?

I've looked into tftpd32 and microsoft deployment tools, but neither seam to be a proper solution to our problem because the first doesnt seam to be robust enough and the second seams to be geared more towards enterprise installations of a captured images to near identical machines. Is there anyone out there that has a similar use case and if so what did you use, or anyone that has any idea of what may work any input would be incredibly helpful.


locked by HopelessN00b Jan 21 '15 at 3:43

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as off-topic by HopelessN00b Jan 21 '15 at 3:43

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

Setup that we use.

  1. WDS (windows deployment services)

    • Use WDS to provide PXE boot. All laptops can boot via PXE into WDS server.
    • WDS will host MDT boot images
  2. MDT (Microsoft Deployment Tool)

    • Create task sequences to install Operating systems with default settings ( 7, XP, Vista)
    • Create task sequences to install Applications
    • Install generic drivers to cover most nework drivers
    • Install additional drivers as required

All of the above sits inside MDT boot images that is hosted within WDS. Thus during the boot into WDS server you are provided with all of these task sequences. AFter choosing a task sequence you can specify rules in two ways:

  • Specify the answer and don't even ask me
  • Specify the default answer, but give me the option to change upond every new deployment (helpful when you choosig between add to domain or not)

Further info on Rules

The beauty of MDT is that you have default RULES for all images, but then you also have RULES for individual deployment tasks. Using Windows XP as an example:

 **Unattend.txt** is used when you're deploying from an operating system that has been imported directly from the original Windows XP SP3 CD.
 **Sysprep.inf** is used when you're deploying using  a custom image of Windows XP or Windows Server 2003.

Anything specified within the Rules of your deployment share, overwrites the settings specified within sysprep.inf & unattend.txt. You can however specify to skip certain settings within Rules, so you don't get asked the question, but still allow yourself the option to specify this during the actual installation, by specifying this within the sysprep.inf and unattend.txt.

All in all, the rules of MDT and the accompanied rules provided by invidual Operating Systems are very very flexible.

Somes of the rules Available

  • Don't add to network domain, but workgroup instead.
  • Specify Prodcut Key
  • Give PC name
  • Choose which applications to install if any

Driver problem: If install generic drivers for msot common network card chips, you will at least be able to complete the process of imaging the machine, then you are left with finding the remainnig drivers for Video , Sound etc.... Depending on use.

Growing driver database: As you then start imaging more machines, you can start adding these drivers to yuor MDT installation for future deployments. MDT uses plug and play ID identification to only upload and install the required drivers during deployment. You should also go a step further and categorize your drivers, by Manufacturer & OS.

I have a good article that goes thruogh the various steps explaining all of this if you are interrested. Let me know I would be to hapy to send it over.


Part of the issue here is that if you do want an automated system then you will need to set some "rules" to automate against, whereas you seem to want a system that can take all things and do "whatever needs to be done".

This is possible - you can configure an automated deployment via something like Windows Deployment Services so that the computer doesn't join a domain at the end of the install, and you can also have a set of install scripts you can select by hand to load software onto a machine after the base windows install is complete.

Drivers are an issue - but then they'll be an issue no matter what you do.

Another issue you need to consider is licensing; if you're installing a windows image onto computers that are not owned by the college then how will you handle that - I don't think you can licence a volume licence install of windows to an OEM key.

At least with XP, you can't use volume license disks for OEM installs indeed. Whereas all OEM installs are "equal" - you can use Dell keys with Lenovo install disks. I believe this has changed with Windows Vista/7 where installation disks are "unified" and would accept any valid key - FPP, OEM or MAK/KMS. – the-wabbit Jan 23 '12 at 12:53

If you do have Windows / Active Directory servers, you probably need to take a look into Windows Deployment Services. Things are done quite differently for XP and Vista/7, but in both cases you get a complete setup process which you can script and modify with own drivers.

If you do not have an AD, XP installations can be bootstrapped using unattended - which is very similar to the way WDS is doing it. And Vista and later do have Windows PE installers, which can be bootstrapped (and scripted as well) via Windows PE which is capable of being PXE-booted out-of-the-box.

You would certainly need to familiarize yourself with unattended installation techniques for WinXP as well as Vista/7.

Additionally, if at all possible we would be able to boot some diagnostic .iso's over the network as well ie, memtest, sea tools, live run ubuntu.

PXELinux allows for this kind of stuff. You can boot live systems like LiveRescueCD, Seatools or DOS images. See the PXE deployment scripts project for working examples.

Edit: regarding your software installation question, there is an awful lot of work in scripting installers. You can take a look at OSS automation projects like WPKG which are mainly there to present a scriptable engine for package management (i.e. installation, updates and deinstallation), but even in your simplified case of "install and forget" you should be able to get a lot of useful information looking at the way how different manufacturer's installers are scripted.


I work for a non profit and we have all kinds of makes and models. In addition to WDS I would look into MDT. While it can be used to add product keys and join a domain these are not requirements. I would also look at the driverpacks available online. With a couple of the more common ones I rarely needed to add additional ones.

I would reccomend that you leave the software reinstall up to the user as much as possible.

It is possible to customize the boot process for WDS to first boot a pxelinux image thus allowing your diagnostic images to also be stored on your windows box. I personally keep a copy of gparted dban HP and dell diagnostic images.


Not the answer you're looking for? Browse other questions tagged or ask your own question.