Every know and then the discussion about using offline servicing vs. build and capture for your reference images comes up, so I figured it was about time to write a post about it.
There are essentially two techniques available for creating reference images:
- Offline Servicing. This is when you use DISM or PowerShell to inject Windows updates and regular files (desktop application installs can not be serviced offline). This process can easily be automated since it's command line utilities or PowerShell cmdlets.
- Build and Capture. This is when you use a MDT task sequence to install Windows to a VM, including updates, settings, desktop applications etc. and then sysprep and capture to a WIM Image. This process can (and should) be automated via PowerShell. A concept referred to as an image factory
Note: Obviously you can also install updates, settings and applications at deployment time, and skip creating reference images all together. It's all about network efficiency and deployment time really.
If you only add the latest Cumulative Update (CU) to your Windows 10 image, the resulting image size, when comparing offline servicing to a build and capture, is almost identical. It's typically only a 0.05 GB difference assuming you also have your task sequence run the Windows cleanup operations before capturing. The boot up time is almost the same too, the build and capture image is about 30 seconds faster than an image serviced offline, so it really doesn't matter.
Build and capture processes is typically interesting when you add more things. Like apps / runtimes etc., components that cannot be serviced offline into the image, or when you're having issue with offline servicing (think of the W7, IE, .NET and LPs combination).
Note: The only thing missing is a way to update the Windows 10 compatibility database to make Inplace upgrades work better.
Hybrid or Thick Images
For Hybrid or Thick images you don't have a choice, you can't use offline servicing, and you simply have to use a build and capture process.
#1: For really thin images, without any runtimes etc. only latest CU, just schedule a tiny PowerShell script that exports the right index from the VLSC media, does the offline servicing, and spits out a production WIM image. Or run through a build and capture in your image factory. In my testing build and capture works great with images that are used for bare metal deployments, and media serviced offline works best for In-Place upgrade scenarios.
#2: For thicker images, or images that cannot be serviced offline, just schedule a longer PowerShell script (image factory) that does the complete build and capture, and spits out a production WIM image. Fully automated.
Bottom line: Ok, sure, Microsoft haven't got their images story quite right, but with a smidge of PowerShell the problem is solved.
Happy Deployment / Johan