Operating system installation is one of the most basic and simple process done by sysadmins or help-desk people, yet it is one of the most expensive processes for any business, because it wastes IT staff time and employees time. Besides being expensive and time consuming, it is also very repetitive and prone to errors.
Let’s image the following, your business decided to build an onsite training center at work with capacity of 25 trainees. The new center needs a new machine for each trainee in the center. Moreover, these machines come without an operating system, because you already have an enterprise license from Microsoft. Accomplishing this task will keep the entire team busy for the entire day! By the end of the day, you will have a dead tired team who spent an entire day on a single task, and training team who were idling due to uninstalled machines.
The traditional way the team is doing this task is by grabbing an installation disc and fill the prompted instruction, until the end. During this process, the staff member must be next to the machine to answer the required questions. The actual process can take up to an hour per machine.
The biggest problem with operating system installation is not the time it consumes, but the IT team might have 25 machines with 25 different configurations. Such difference in configuration may lead into future problems in the future.
Such process can be enhanced by complying two main principles. First, Automating the processes as much as possible. Second, unifying all the hardware and software as much as possible. Operating system installation automation complies these principles.
In a nutshell, operating system installation is done using through running a PXE server, and creating a proper answer machine file which is used answer question asked during installation.
They are different solutions used for operating system automation. Microsoft suggests Microsoft Deployment Toolkit to automate their operating systems. Red Hat released Kickstart to automate its operating systems.
Cloning is also a solution, but I suggest not to use it. The master image of the clones needs to be up to date to have all the chnages. Also, SA needs to run sysprep to change GUID and SID of each clone. Finally, cloning hides the history of the process. As a result, the SA does not know installation history.