![ISO vs WIM](https://i.stack.imgur.com/fKBJ2.png)
Sector-based imaging is best used for quickly backing up (similar hardware) machines/disks (a limitation of cloning is that it doesn’t support simple updates to the images; any updates require a new clone image).
File-based imaging is for flexible, fast image deployments and easier updates in a mixed hardware environment. (can be deployed to any hardware resulting in a smaller image library that often leads to more efficient deployments)
ISO files contain WIM file (making it more portable & may be extracted to a single file if deployed in Windows environment) eg. Windows 10 ISO contains WIM file (BOOT.WIM, in Windows installation disks, contains a bootable version of Windows PE). Windows boot loader supports booting Windows from within a WIM file.
WIM images are engineered to perform optimally in Windows systems, but conversion to ISO will render the image more portable.
For operating systems that don't support WIM format, wim images may be converted to the more commonly used ISO image using the Windows Assessment and Deployment Kit (ADK).
Unlike sector-based formats (such as ISO or VHD), WIM is file-based: The fundamental unit of information in a WIM is a file. The primary advantages of being file-based is hardware independence and single-instance storage (prevent data duplication). Since the files are stored inside a single WIM file, the overhead of opening and closing many individual files is reduced. Also the cost of reading or writing files is eliminated by disk caching & sequential data access.
WIM files can contain multiple disk images, which are referenced either by their numerical index or by their unique name.
dism /Get-WimInfo /WimFile:"c:\path\install.wim"
Images may be extracted to a single file:
dism /Export-Image /SourceImageFile:"c:\path\install.wim" /SourceIndex:3 /DestinationImageFile: "c:\temp\install_3.wim"
Due to the use of single-instance storage, the more each successive disk image has in common with previous images added to the WIM file, the less new data will be added. A WIM can also be split (spanned) into multiple parts.
File-based cloning also results in defragmented drives (inherent benefit). Thus a drawback is that only one volume (formatted filesystem) can be cloned at a time, and the initial cloning will be slower, esp. on at/near capacity disks being cloned since file access requires the system to read the filesystem directory, process the location of the file, access the file, and then read it for cloning.
This overhead doesn't apply to sector-based cloning, which just reads & copies bytes on disk, resulting in a faster initial cloning. Another benefit of this method is that files that have been deleted, corrupted, or otherwise lost from the filesystem are also recoverable in the clone.
References:
https://en.wikipedia.org/wiki/Windows_Imaging_Format
https://www.smartdeploy.com/blog/the-difference-between-file-based-and-sector-based-imaging/
https://www.cnet.com/news/differences-between-file-level-and-block-level-cloning/
Best Answer
The simple answer : Use MDT 2012 Update 1, WAIK and WDS (John and Josh are Both right.)
MDT is free and it will build, capture, and deploy Windows 7 images. More than that though, it will update the systems at deploy time, name the systems, inject drivers, join to the domain, add local admin groups, you name it, MDT can do it.
Use WDS for PXE boot and multicasting if you have Server 2008 or above. Don't try to build and capture with WDS alone. WDS by itself is not a deployment solution. AIK by itself is not a deployment solution.
The beauty of MDT is that it uses task sequences to automate everything dynamically. Use it build your images, and then use it to deploy those same images. Build a share for both, one for builds, and one deploys.
Use a VM to build your reference, and you can build a "hardware independent" image that'll run on everything, laptops, desktops, Dell, HP, Lenovo, whatever. MDT can do the drivers later at deploy time. When combined w/ WDS, it's the only deployment solution you'll ever want to use again. As far as pitfalls are concerned, you should make sure you build a good image that has only the basic core applications, almost everything else can come later.
Download and Install:
Download & Install MDT 2012 http://www.microsoft.com/en-us/download/details.aspx?id=25175
Download & Install Win7 AIK http://www.microsoft.com/en-us/download/details.aspx?id=5753
Download Win7 AIK Supplement http://www.microsoft.com/en-us/download/details.aspx?id=5188
Download Win7SP1 digital river SP1 ISOs are listed on super user's FAQ
Overview of what to do in the MDT workbench:
Create Deployment Share http://www.youtube.com/watch?v=ciT_YqLdcgk
Import Drivers http://www.youtube.com/watch?v=bWdGBVyD1pM
Import a .wim file from your Windows install CD or a custom .wim file
Create a task sequence and point it your .wim file
You would then launch the Windows System Image Manager from the Task Sequence Properties OS Info Tab. to edit your unattended.xml file.
Update the deployment share
Burn the boot iso, boot to ISO (use this iso to upload and download images)
Optional Steps for WDS Integration: (For PXE Booting & Multicast)
Install WDS Role on Server
Upload Boot.wim from MDT Share
Configure PXE Boot
Enable multicast in MDT
Take Control of Drivers
Again, to ensure a reference image can run on both Laptops and Desktops, and across vendors, build it in a Virtual Environment. This way your reference image is truly hardware independent. Don't worry about drivers in your reference build, MDT can be configured to inject drivers dynamically into the image file at deploy time.
Look into a Driver Injection model known as "total control". The idea is simple, by segregating the drivers used in the workbench, you can ensure that only the right drivers are injected to the right systems. This is achieved by first creating a strictly organized set of folders within the workbench. At the very top of this we have the root folder Out of box Drivers. Inside this folder we have a folder for each OS we will be supporting. Next we sort in yet another pair of folders by Architecture, x86 vs. x64.
In the case of this example, we have two folders in the root of out of box drivers in the workbench, One for Windows 7, and another for Windows PE. Within both of these folders we will have a folder named after the Manufacturer as it would appear in WMI or system information. Then, finally within those folders we want to have folders named as the Model info, again exactly as it appears within system information.
For example, one would find the 64 bit Win7 drivers for the HP 8300 in: Windows 7\x64\Hewlett-Packard\HP Compaq Elite 8300 SFF. This may seem like overkill at first, but it pays off in dividends when we set the driver group variable in the customsettings.ini file.
DriverGroup Settings in MDT
Learning MDT is highly rewarding, even though it takes some time, but it really pays off. Once you really understand the system, you can have one baseline image, and apply all the apps and drivers dynamically on the fly. A well tuned MDT lite touch can install the OS, name the PC, inject drivers, join to the domain, install all needed apps, activate office, and reboot in less than an hour with almost no interaction required from the tech who is running the deployments.
Deployment Soup Video
http://technet.microsoft.com/en-us/windows/hh215959
Deploying Windows A - Z
http://www.microsoft.com/en-us/download/details.aspx?id=6157
Learning to use MDT litetouch
http://www.deploymentresearch.com/Videos/MDT2010LiteTouchUnleashedVideos.aspx