The proper way of building images these days involves using the Microsoft Deployment Toolkit or MDT for short. The latest version MDT 2013 came out last fall and is simply second to none. MDT builds, captures and deploys images for you. If you've built your images in a VM, MDT can also install the drivers for you in a Make \ Model Hirearchy that will allow you to build one 32-bit and one 64-bit image and simply install drivers, applications, and windows updates dynamically at deploy time. Windows Deployment Services will allow you to PXE boot and multicast the images, but WDS in and of itself it is not a true deployment solution.
Clonezilla is a joke, avoid it like the plague. It lacks offline servicing, driver injection, dynamic software provisioning, and a list of other features.
MDT is configured and controlled through a MMC snap-in called the Deployment Workbench. It’s here you will modify a series of files and folders called Deployment Shares to automate Windows and Office deployments. Ideally if you’re an IT Pro, you should have three shares, one just for building images, one for live production, and a third for testing. If you’re just getting started, just play with a basic share until you’re ready to start building any of those. You want to get comfortable pushing just the generic, stock, vanilla image from the CD and a few apps at deploy time before you even think about going into production. Learn to walk before you run.
Prelim: Install MDT 2013 & ADK
Install MDT 2012, and then install the Win ADK. ADK will install Win7 both and Win8 with no problems
Download & Install MDT 2013 Update 1
Download Win7SP1 ISOs
Windows 7 Professional SP1-U English x86: http://msft.digitalrivercontent.net/win/X17-59183.iso
Windows 7 Professional SP1-U English x64: http://msft.digitalrivercontent.net/win/X17-59186.iso
SP1 Update roll-ups
STEP 1: Create a Share
The first time you get into MDT, it’s a bit underwhelming, just create a new share, and start feeding it.
Name the share
Locate the share
- Make sure it’s gonna have room
Configure answer file
- The five check boxes will build your first customsettings.ini file.
STEP 2: Feed The Beast
- Start first with easy stuff, Firefox, Flash, Office. Worry about those apps that 10% of your users use later.
- Worry about other makes and models later. When getting started, focus on one model, we’ll add other drivers later.
- Import the install.wim file for now
STEP 3: Build The Task Sequence
Use a standard client task sequence, and configure your answer file
STEP 4: Configure your Share
Configure this file with the IP of the server if you’re in a network without local DNS. You can also do set an autologin for winpe here.
This is the real magic file here, many steps of the wizard are either configured or skipped outright here.
Turn on/off what platforms you’ll support here, set your scratch space and enable monitoring here.
STEP 5: Update Share
Update the share and build the boot media. Once you have a boot media, you're in business, boot to the USB or CD, and you're imaging like a real IT Pro!
Something here is key – Always, Always, Always, build your reference images in a Virtual Machine. It doesn’t matter if you use VMware, Hyper-V, or even Oracle’s Free VirualBox. Building reference images in a virtual enviroment allows it to be truly hardware independent. The days of building a separate image for every single make and/or model you support will be long gone once you stop building reference images on physical hardware. Worst case scenario is you’ll be supporting an x86 image and a x64 image, but even that’s unlikely, as x86 is effectively headed the way of DOS.
Build a good hybrid image. This could include Office, OS updates, and some other core/universal business apps. I advise to go this route. Keep firefox, adobe and flash out of your image, these update almost monthly, if not weekly and are very easy to install at deploy time. Just get the command line syntax needed to install apps silently at deploy time. The more you keep out of your image, the easier it is to maintain.