What is the most efficient, native way to image a Windows partition?

Question 1

What is the most efficient, native way to image a Windows partition?

Is the native method generally the best method for most users?
How does the native method differ from conventional cloning?
What are the pros and cons of native versus third-party tools?

How do I configure system partitions on a new drive for applying an image?

Annotation:

Many have taken issue with the "image" nomenclature, and it is the correct terminology
- It's not up to an individual to change a developer's nomenclature since arbitrarily doing so would only sow confusion when referencing Windows' man pages [Microsoft Learn]
While I can't definitively point to any specific Windows whitepaper, Windows' "image" nomenclature likely comes from how Windows is referred to from a servicing standpoint, which is as an "image", and is why DISM has the /Online and /Image parameters:
- Online image servicing deals with a %SystemDrive% while booted to it
- Offline image servicing deals with a non-booted to %SystemDrive%
- Image management deals with the topic of this question

Question 2

"Why is the native method generally the best method for most users?" - that's not really an honest, non-biased question.

Question 3

@gronostaj More to the point, rather than what it isn't, we can say that it is a loaded question .

Question 4

@gronostaj While I had in mind precisely what I wanted to address in the answer, the questions are both thoughtful & pertinent.

Question 5

@J... As to loaded, not at all, as there's only one native way to image partitions in Windows for the last ~20yrs. I became exasperated continually addressing parts of these in comments and as answers on cloning issues questions, so I wanted to create a Q and A that addressed them in-depth, hoping to also squash misnomers & factually inaccurate info along the way (appears to be harder than it really should be since many aren't bothering to read the source links).

Question 6

@JW0914 All that's fine, but it's still a loaded question. It presupposes that the native method is, in fact, generally the best method in asking why.

Question 7

What is the most efficient, native way to image a Windows partition?

For the majority of users, capturing an image of a partition via DISM (XP ≤ 7: ImageX) is generally the best and most efficient method, while also not causing the common configuration issues with third-party tools or Windows Image Backup and Backup and Restore (Windows 7)

Win XP ≥ 10 has always natively supported imaging of partitions and filesystems:
- Imaging the OS partition is slightly different than other partitions, as it can only be imaged from WinPE/WinRE
- Microsoft's Windows Imaging File Format whitepaper explains the WIM format
  - WIMs [Windows IMage] can capture an entire partition or individual folders/files
  - ESDs [Encrypted Software Distribution] can only capture an OS partition and must use /Compress:Recovery (algorithm is ~33% more efficient than /Compress:Max)
    - Windows ≥ 10: Can only be used for PBR [Push-Button Reset] exported images
      Windows ≤ 8.1: Only a bootable Windows install can be captured as an ESD
All WinPE/WinRE WIMs have DISM included within them (Win XP ≤ 7: ImageX):
- WinPE: Windows Preinstallation Environment
  (Windows Setup boot media: SHIFT+F10 to access terminal)
- WinRE: Windows Recovery Environment
  (WinRE is a WinPE image containing extra WinPE Optional Components vital to recovery)
```
# Once booted to WinRE: Advanced → Troubleshoot → Command Prompt
# To boot to WinRE:
 Shutdown /f /r /o /t 0
```

Annotation:

Many have taken issue with the "image" nomenclature, and it is the correct terminology
- It's not up to an individual to change a developer's nomenclature since arbitrarily doing so would only sow confusion when referencing Windows' man pages [Microsoft Learn]
While I can't definitively point to any specific Windows whitepaper, Windows' "image" nomenclature likely comes from how Windows is referred to from a servicing standpoint, which is as an "image", and is why DISM has the /Online and /Image parameters:
- Online image servicing deals with a %SystemDrive% while booted to it
- Offline image servicing deals with a non-booted to %SystemDrive%
- Image management deals with the topic of this answer

Imaging

_{(Powershell cmdlet)}

Specify exclusions or exceptions by creating a WimScript.ini config file, with /ScratchDir being required in WinPE since it only has 32MB of scratch [temp] space by default:

Even though /CheckIntegrity (ImageX: /Check) and Verify extend processing time, they should always be used since they prevent corruption from occurring within the WIM/ESD

Either Capture or Append an image:

Capture Image:

# Windows ≥8: DISM
 Dism /Capture-Image /ImageFile:"Z:\Base.wim" /CaptureDir:"C:" /Name:"Windows Backup" /Description:"Base Image 2020年08月29日 @ 11:30" /Compress:Max /CheckIntegrity /Verify /ScratchDir:"Z:"
# Windows XP ≤ 7: ImageX
 ImageX /Capture "C:" "Z:\Base.esd" "Windows Backup" "Base Image 2020年08月29日 @ 11:30" /Compress:Recovery /Check /Verify /ScratchDir:"Z:\"

If saving the image to a mechanical HDD, compression takes longer, so if wanting to use /Compress:Max or /Compress:Recovery and time is an issue, it'll be more efficient to use /Compress:Fast, exporting the image later using Max or Recovery
For managing size constraints, images can be split into multiple read-only .swm files via /Split-Image

Append Image:

# Windows ≥8: DISM
 Dism /Append-Image /ImageFile:"Z:\Base.wim" /CaptureDir:"C:" /Name:"Windows Backup" /Description:"Base Image 2020年08月29日 @ 11:30" /CheckIntegrity /Verify /ScratchDir:"Z:"
# Windows XP ≤ 7: ImageX
 ImageX /Append "C:" "Z:\Base.esd" "Windows Backup" "Base Image 2020年08月29日 @ 11:30" /Compress:Recovery /Check /Verify /ScratchDir:"Z:\"

Compression is locked to the value set when the base image was captured
Individual indexes can be deleted via /Delete-Image or exported to their own image via /Export-Image

Apply Image:

# Windows ≥8: DISM
 Dism /Apply-Image /ImageFile:"Z:\Base.wim" /Index:1 /ApplyDir:"C:" /CheckIntegrity /Verify /ScratchDir:"Z:"
# Windows XP ≤ 7: ImageX
 ImageX /Apply "Z:\Base.wim" 1 "C:" /Check /Verify /ScratchDir:"Z:\"

Prior to applying, get Image Info, ensuring correct index [image] is being applied:
```
Dism /Get-ImageInfo /ImageFile:"Z:\Base.wim"
```

If applying an OS image, the following must be run prior to exiting WinPE/WinRE:

BIOS:

BootRec /FixMBR && BootRec /FixBoot && BootRec /RebuildBCD

UEFI:

::# With existing bootable EFI partition:
 BootRec /FixMBR && BootRec /RebuildBCD
::# Without existing bootable EFI partition:
 ::# Create EFI directories and enter:
 MkDir "Y:\EFI\Microsoft\Boot"
 Cd /d "Y:\EFI\Microsoft\Boot"
 ::# Create EFI boot structure:
 BootRec /Fixboot
 ::# If Access Denied error occurs (C: is applied image):
 BcdBoot C:\Windows /s Y: /f UEFI
 ::# Resolve any other boot issues:
 BootRec /FixMBR && BootRec /RebuildBCD

Accessing data within a WIM or ESD

Read-only:

Mount Image: (as /ReadOnly)

# Windows ≥8: DISM
 Dism /Mount-Image /ImageFile:"Z:\Base.wim" /Index:2 /MountDir:"C:\Mount" /Optimize /CheckIntegrity /ReadOnly
# Windows XP ≤ 7: ImageX
 ImageX /Mount "Z:\Base.wim" 2 "C:\Mount" /Check

In lieu of this, I prefer opening the ESD/WIM within the 7zip GUI

Unmount Image: (/discard changes)

# Windows ≥8: DISM
 Dism /Unmount-Image /MountDir:"C:\Mount" /CheckIntegrity /Discard
# Windows XP ≤ 7: ImageX
 ImageX /Unmount "C:\Mount"

Make changes, or add data, to an image [index]:

Mount Image:

# Windows ≥8: DISM
 Dism /Mount-Image /ImageFile:"Z:\Base.wim" /Index:2 /MountDir:"C:\Mount" /Optimize /CheckIntegrity
# Windows XP ≤ 7: ImageX
 ImageX /MountRW "Z:\Base.wim" 2 "C:\Mount" /Check

Unmount Image: (/Commit changes)

# Windows ≥8: DISM
 Dism /Unmount-Image /MountDir:"C:\Mount" /CheckIntegrity /Commit
# Windows XP ≤ 7: ImageX
 ImageX /Unmount "C:\Mount" /Commit

If using DISM, to save changes as a new appended image, add /Append

Is the native method generally the best method for most users?

With the native method [WIMs/ESDs], no additional imaging tools or boot media is required since support is natively built-in to WinPE and Windows
Its impossible for WIMs/ESDs to become corrupted, provided /CheckIntegrity (ImageX: /Check) & /Verify are always used
Capturing and applying an ESD/WIM is not the best solution for all imaging [cloning] use cases, but is for most:
- Capturing an ESD/WIM requires a storage medium to house the captured image (partition not being imaged, USB drive, network share, etc.), serving the dual purpose of also being an actual backup base image
- Additional backups of the same partition can be appended to the base image with minimal [relative] file size increase, and while data from multiple partitions can be appended to the same base image, the smart compression feature benefits WIMs provide would be lost

WIMs/ESDs are smart compression image formats and therefore storage efficient:

Only changed files are added to an ESD/WIM when a new image [index] is appended to it; newly appended images utilize the same copy of unchanged files already contained within the image from the previous image(s) (hash verified) , allowing for an image to remain small in relation to the data within

Appended image example:

# Note Base.wim size compared to each index and sum of all data therein:
 PS $ ls -File
 Length Name
 --------------- -------------
 95,019,530,773B Base.wim
 568B Dism.cmd
 97B WimScript.ini
 PS $ Dism /Get-ImageInfo /ImageFile:Base.wim
 Details for image : Base.wim
 Index : 1
 Name : Alienware 18: Windows 10
 Description : v1803: Base (Drivers Only)
 Size : 22,710,283,446 bytes
 Index : 2
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (No Customizations)
 Size : 45,591,850,754 bytes
 Index : 3
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (Customized)
 Size : 94,958,267,312 bytes
 Index : 4
 Name : Alienware 18: Windows 10
 Description : v1809: Updated Applications
 Size : 114,959,954,040 bytes

PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:1
 Details for image : Base.wim
 Index : 1
 Name : Alienware 18: Windows 10
 Description : v1803: Base (Drivers Only)
 Size : 22,710,283,446 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17134
 ServicePack Build : 1
 ServicePack Level : 1
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 24288
 Files : 112665
 Created : 2018年05月05日 - 13:56:47
 Modified : 2018年05月05日 - 13:56:47
 Languages : en-US (Default)
PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:2
 Details for image : Base.wim
 Index : 2
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (No Customizations)
 Size : 45,591,850,754 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17134
 ServicePack Build : 1
 ServicePack Level : 1
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 45803
 Files : 203058
 Created : 2018年05月06日 - 01:55:47
 Modified : 2018年05月06日 - 01:55:48
 Languages : en-US (Default)
PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:3
 Details for image : Base.wim
 Index : 3
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (Customized)
 Size : 94,958,267,312 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17134
 ServicePack Build : 1
 ServicePack Level : 81
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 62409
 Files : 350446
 Created : 2018年06月01日 - 19:09:51
 Modified : 2018年06月19日 - 21:26:18
 Languages : en-US (Default)
PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:4
 Details for image : Base.wim
 Index : 4
 Name : Alienware 18: Windows 10
 Description : v1809: Updated Applications
 Size : 114,959,954,040 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17763
 ServicePack Build : 195
 ServicePack Level : 0
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 87659
 Files : 452028
 Created : 2018年12月24日 - 04:27:13
 Modified : 2018年12月24日 - 04:27:15
 Languages : en-US (Default)

In contrast to WIMs/ESDs, Windows Image Backup and Backup and Restore (Windows 7) create a VHD image while booted to the OS using the Volume Shadow Copy Service [VSS], being no different than creating a VHD and using RoboCopy to copy all data, maintaining ACLs, to the VHD from the OS partition, and has:

little to no compression (storage inefficient)
no parity (lacks data verification)

total reliance on a myriad of external config, catalog, and binary files residing outside of the VHD to work correctly (in contrast to a self-contained WIM/ESD image), and if these become corrupted/modified or moved/deleted, a restore isn't possible and will fail:

# VM: EFI boot with clean install of Windows 11
 # Note VHD size versus ESD/WIM images of the same VM:
 # VHD (20.76GB)
 # WIM (9.23GB)
 # ESD (6.92GB)
PS $ ls -file
 Length Name
 --------------- -------------
 20,761,804,800B 87a69c87-81dd-4b7f-95a1-1bff3144b638.vhdx
 6,921,506,902B vm.esd
 9,238,800,695B vm.wim
PS $ tree -f
 | MediaID.bin
 | vm.esd
 | vm.wim
 |
 └─VM
 │ MediaID.bin
 |
 └─Backup Set 2024年03月19日 060426
 ├─Backup Files 2024年03月19日 060426
 │ Backup files 1.zip
 │ Backup files 2.zip
 │ Backup files 3.zip
 │ Backup files 4.zip
 │ Backup files 5.zip
 │ Backup files 6.zip
 │ Backup files 7.zip
 │ Backup files 8.zip
 │ Backup files 9.zip
 │ Backup files 10.zip
 │ Backup files 11.zip
 │ Backup files 12.zip
 │ Backup files 13.zip
 │ Backup files 14.zip
 │ Backup files 15.zip
 │ Backup files 16.zip
 │ Backup files 17.zip
 │ Backup files 18.zip
 │ Backup files 19.zip
 │ Backup files 20.zip
 │ Backup files 21.zip
 │ Backup files 22.zip
 │ Backup files 23.zip
 │ Backup files 24.zip
 │ Backup files 25.zip
 │ Backup files 26.zip
 │ Backup files 27.zip
 │ Backup files 28.zip
 │ Backup files 29.zip
 │ Backup files 30.zip
 |
 ├─Catalogs
 │ GlobalCatalog.wbcat
 |
 └─WindowsImageBackup
 └─VM
 │ MediaId
 |
 ├─Backup 2024年03月19日 130431
 │ 127dbd44-5431-4b1c-9500-426293266794.vhdx
 │ 87a69c87-81dd-4b7f-95a1-1bff3144b638.vhdx
 │ BackupSpecs.xml
 │ Esp.vhdx
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Components.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_RegistryExcludes.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writere8132975-6f93-4464-a53e-1050253ae220.xml
 |
 ├─Catalog
 │ BackupGlobalCatalog
 │ GlobalCatalog
 |
 ├─Logs
 |
 ├─SPPMetadataCache
 │ {f714635b-5a6a-4163-9695-33ae3fa712a6}

How does the native method differ from conventional cloning?

The vast majority of Windows users have no need for partition-level or disk-level images:

A conventional partition-level or disk-level image (contains offset, alignment, block size, etc.):
- Lacks native Windows support and therefore requires non-standard boot media (boot media that's not WinPE/WinRE) and third-party programs
- Often lacks compression by default, one of the main advantages of the WIM/ESD smart compression image format
- Locks the user to that specific partition or drive layout (offset, alignment, block size, etc.)
- Often has no data verification and is therefore subject to data corruption
DISM/ImageX creates a filesystem image, not a partition partition-level or disk-level image:
(Win ≥ XP uses NTFS as the default filesystem)
- When pointed at the root of a partition [C:\], DISM/ImageX captures an image of all data on that partition, but not the structure of the partition/drive itself (offset, alignment, block size, etc.), bypassing the inconvenience a conventional partition/drive image creates, as only filesystem data is contained within a ESD/WIM, allowing it to be applied to any partition, regardless of size difference or whether there is existing data on the partition.

What are the pros and cons of native versus 3rd party?

Third-party tools will almost always fall into one of two categories, Linux-based or Windows-based via DISM/ImageX/Powershell, with many resulting in configuration issues, and the latter sometimes encompassing developers who use proprietary image file formats and custom boot environments (many of which are Linux-based).

There's a minute number of posts on StackExchange (or Spiceworks) regarding imaging issues arising from using Windows' native DISM (Win XP ≤ 7: ImageX), however thousands of questions, answers, and comments exist for issues arising from third-party imaging tools:
- Windows cloning issue (2,751 results)
  Windows cloning problem (3,838 results)
- DISM:
  - Windows Dism /Capture-Image issue (60 results)
    Windows Dism /Capture-Image problem (44 results)
  - Windows Dism /Append-Image issue (20 results)
    Windows Dism /Append-Image problem (12 results)
  - Windows Dism /Apply-Image issue (85 results)
    Windows Dism /Apply-Image problem (93 results)
- ImageX:
  - Windows ImageX /Capture issue (19 results)
    Windows ImageX /Capture problem (20 results)
  - Windows ImageX /Append issue (10 results)
    Windows ImageX /Append problem (5 results)
  - Windows ImageX /Apply issue (15 results)
    Windows ImageX /Apply problem (12 results)
I have the perspective it's unacceptable for a Windows user to receive advice to use Linux tools to image Windows, as that's inefficient, forcing the user to rely on not only a non-native boot environment unsupported by Windows, but also on an image format unsupported by Windows, both of which over-complicate imaging.

Ever come across advice telling a BSD or Linux user to boot to Windows or use Wine to back up their data? For example, ntfsclone (part of ntfs-3g) is a popular Linux utility, with the following from it's man page:

Windows Cloning

If you want to copy, move or restore a system or boot partition to another computer, to a different disk, partition... or to a different disk sector offset, then you will need to take extra care.

Usually, Windows will not be able to boot, unless you copy, move or restore NTFS to the same partition which starts at the same sector on the same type of disk having the same BIOS legacy cylinder setting as the original partition and disk had.

The ntfsclone utility guarantees to make an exact copy of NTFS, but it won't deal with booting issues. This is by design: ntfsclone is a filesystem, not system utility; its aim is only NTFS cloning, not Windows cloning. Hereby ntfsclone can be used as a very fast and reliable build block for Windows cloning but [it] itself it's not enough.

WIMs/ESDs don't have these issues since they only contain filesystem information (files and directories), not partition/drive level data, allowing them to be applied to any partition, regardless of size difference or whether there is existing data.

Native Pros

WIMs/ESDs are natively supported by all Windows editions ≥ XP
- WIMs/ESDs are versatile and can be captured, applied, or modified when booted to WinPE (Windows install media), WinRE (Windows Recovery), or the OS
- WIMs/ESDs do not require additional tools or boot media since all required tools are built-in to all three environments
WIMs/ESDs are smart compression image formats, able to contain multiple images, backups or otherwise, within a relatively small single image file
Its impossible for WIMs/ESDs to become corrupted, provided /CheckIntegrity (ImageX: /Check) & /Verify are always used
WIMs/ESDs can be deployed remotely via PXE, even to a machine without an OS installed

Native Cons

Requires a storage medium for the captured image (another partition, USB drive, network share, etc.)
- If saving the image to a mechanical HDD, compression takes longer, so if wanting to use /Compress:Max or /Compress:Recovery, it's more efficient to use /Compress:Fast, exporting the image later using Max or Recovery
Capturing, Appending, Applying, or Exporting an image is resource-intensive
- Even though /CheckIntegrity (ImageX: /Check) and Verify do extend the image processing time, they should always be used

How do I configure system partitions on a new drive for applying an image?

Use DiskPart:

DiskPart
::# List disks:
 Lis Dis
::# Select OS drive # the image is being applied to:
 Sel Dis #
::# Wipe partition table (assumes no data on drive is being preserved)
 Clean

UEFI:

Convert gpt

Create boot partition:

BIOS:

Cre Par Pri Offset=1024 Size=100
Format Quick Fs=NTFS Label="Boot"
Active

UEFI:

Cre Par EFI Offset=1024 Size=100
Format Quick Fs=FAT32 Label="EFI"
Assign Letter=Y
Cre Par Msr Size=16

Create OS partition:
- Rest of the drive as the OS partition:
  If C: can't be assigned, change 3 & 5 to another letter
  BIOS:
```
Cre Par Pri
Format Quick Fs=NTFS Label="System"
```
  UEFI:
```
Cre Par Pri Id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Format Quick Fs=NTFS Label="System"
Assign Letter=C
```
- Additional partitions after the [200GB] OS partition:
  If storing User Data directories on a partition other than C:\ (recommended), max size required is ~300GB (multiply size wanted by 1024: 200*1024=204800)
  BIOS:
```
Cre Par Pri Size=204800
Format Quick Fs=NTFS Label="System"
```
  UEFI:
```
Cre Par Pri Size=204800 Id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Format Quick Fs=NTFS Label="System"
Assign Letter=C
```

Create WinRE partition: (should have minimum 320MB free for future WIM size increases)

BIOS:

Shrink Desired=1024 Minimum=1024
Cre Par Pri id=27
Format Quick Fs=NTFS Label="WinRE"

UEFI:

Shrink Desired=1024 Minimum=1024
Cre Par Pri Id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
Format Quick Fs=NTFS Label="WinRE"
Gpt Attributes=0x8000000000000001

Resolve any boot issues: (after WIM has been applied via Step 2 at TOP of answer)

BIOS:

BootRec /FixMBR && BootRec /FixBoot && BootRec /RebuildBCD

UEFI:

::# With existing bootable EFI partition:
 BootRec /FixMBR && BootRec /RebuildBCD
::# Without existing bootable EFI partition:
 ::# Create EFI directories and enter:
 MkDir "Y:\EFI\Microsoft\Boot"
 Cd /d "Y:\EFI\Microsoft\Boot"
 ::# Create EFI boot structure:
 BootRec /Fixboot
 ::# If Access Denied error occurs (C: is applied image):
 BcdBoot C:\Windows /s Y: /f UEFI
 ::# Resolve any other boot issues:
 BootRec /FixMBR && BootRec /RebuildBCD

Remove EFI mountpoint (if applicable) and Reboot
UEFI:
```
DiskPart
 Sel Vol Y
 Remove
 Exit
```

Question 8

"Windows has always natively supported imaging of partitions or individual directories" is vast hyperbole. Windows was around long before Longhorn/Vista (which introduced ImageX, the predecessor to dism). Further, neither ImageX nor dismmeets the Question's demand for a "native way to image a Windows partition", since both image the filesystem on a partition. This is not merely semantics.

Question 9

@JW0914 : "always", emphasis mine, is incorrect, as is your claim "Windows is installed via a WIM or ESD image". Windows 1, 2, 3.0-WfW 3.12, NT 3.5.0-4.1, 95, 98, 98SE all precede WIM, ESD, ImageX, and dism. I still install Win98SE from time to time; it, like many of the Windows I listed, is installed from CAB files. The WIM/ESD/ImageX/dism ecosystem didn't exist prior to Longhorn/Vista and I note that the Question doesn't specify a version or range of versions of Windows in text or in tags, so you have, at best, given a partial answer, incorrectly claiming universal scope.

Question 10

It seems pretty misleading to call the stuff described in this answer an "image" at all. It's a file archive created by means of copying the files into a completely different filesystem, and nothing is ever imaged.

Question 11

MS being flat out wrong in word usage is definitely nothing new, and goes back more than 20 years :)

Question 12

@AlexS: wimlib allow read/write access to WIM —and probably ESD— archives since about 2013; interoperability with Microsoft ("native") tools is not perfect, so as always please backup first, but it can achieve useful things.

Question 13

What is the most efficient, native way to image a Windows partition?

There isn't one any more since Windows Backup is being phased out (probably because this was a bad product to start with).

Only DISM is left, but it only does file backup, not partition image backup. Its new Full Flash Update (FFU) images takes a sector-by-sector image of the entire disk, which unfortunately also includes unused sectors, so not at all efficient.

Why is the native method generally the best method for most users?

It isn't for Windows, as above. Microsoft has left the field in favor of third-party products.

How does the native method differ from conventional cloning?

DISM does not do cloning at all.

What are the pros and cons of native versus third-party tools?

The pros of third-party tools is that they work well and efficiently. Most are also free to use.

Example products are AOMEI Backupper, Clonezilla, Macrium Reflect, EaseUS ToDo BackUp. YMMV.

Historical note: DISM was conceived by Microsoft decades ago in an ancient version of Windows (Vista), using the Windows Imaging Format (WIM), which is a file-based disk image format, used mostly for software distribution. For backup, Microsoft has created Windows Backup, of which a limited version is still available in Windows 10 as "Back up and Restore (Windows 7)", but without its problematic image backup feature. The use of DISM as a backup utility is very strongly not recommended.

Question 14

Comments are not for extended discussion; this conversation has been moved to chat.

Question 15

This answer would have been useful if it actually explained the pitfalls of using DISM for partition imaging/cloning purposes, instead of just opinionating against its use. I have one reason for not relying on DISM for partition cloning: it can't handle not-downloaded OneDrive file pointers. Otherwise, it always did it's job for an off-the-shelf tool.

JW0914 9,3018 gold badges36 silver badges55 bronze badges · Answer 1 · 2020-08-30 15:59:58Z

What is the most efficient, native way to image a Windows partition?

For the majority of users, capturing an image of a partition via DISM (XP ≤ 7: ImageX) is generally the best and most efficient method, while also not causing the common configuration issues with third-party tools or Windows Image Backup and Backup and Restore (Windows 7)

Win XP ≥ 10 has always natively supported imaging of partitions and filesystems:
- Imaging the OS partition is slightly different than other partitions, as it can only be imaged from WinPE/WinRE
- Microsoft's Windows Imaging File Format whitepaper explains the WIM format
  - WIMs [Windows IMage] can capture an entire partition or individual folders/files
  - ESDs [Encrypted Software Distribution] can only capture an OS partition and must use /Compress:Recovery (algorithm is ~33% more efficient than /Compress:Max)
    - Windows ≥ 10: Can only be used for PBR [Push-Button Reset] exported images
      Windows ≤ 8.1: Only a bootable Windows install can be captured as an ESD
All WinPE/WinRE WIMs have DISM included within them (Win XP ≤ 7: ImageX):
- WinPE: Windows Preinstallation Environment
  (Windows Setup boot media: SHIFT+F10 to access terminal)
- WinRE: Windows Recovery Environment
  (WinRE is a WinPE image containing extra WinPE Optional Components vital to recovery)
```
# Once booted to WinRE: Advanced → Troubleshoot → Command Prompt
# To boot to WinRE:
 Shutdown /f /r /o /t 0
```

Annotation:

Many have taken issue with the "image" nomenclature, and it is the correct terminology
- It's not up to an individual to change a developer's nomenclature since arbitrarily doing so would only sow confusion when referencing Windows' man pages [Microsoft Learn]
While I can't definitively point to any specific Windows whitepaper, Windows' "image" nomenclature likely comes from how Windows is referred to from a servicing standpoint, which is as an "image", and is why DISM has the /Online and /Image parameters:
- Online image servicing deals with a %SystemDrive% while booted to it
- Offline image servicing deals with a non-booted to %SystemDrive%
- Image management deals with the topic of this answer

Imaging

_{(Powershell cmdlet)}

Specify exclusions or exceptions by creating a WimScript.ini config file, with /ScratchDir being required in WinPE since it only has 32MB of scratch [temp] space by default:

Even though /CheckIntegrity (ImageX: /Check) and Verify extend processing time, they should always be used since they prevent corruption from occurring within the WIM/ESD

Either Capture or Append an image:

Capture Image:

# Windows ≥8: DISM
 Dism /Capture-Image /ImageFile:"Z:\Base.wim" /CaptureDir:"C:" /Name:"Windows Backup" /Description:"Base Image 2020年08月29日 @ 11:30" /Compress:Max /CheckIntegrity /Verify /ScratchDir:"Z:"
# Windows XP ≤ 7: ImageX
 ImageX /Capture "C:" "Z:\Base.esd" "Windows Backup" "Base Image 2020年08月29日 @ 11:30" /Compress:Recovery /Check /Verify /ScratchDir:"Z:\"

If saving the image to a mechanical HDD, compression takes longer, so if wanting to use /Compress:Max or /Compress:Recovery and time is an issue, it'll be more efficient to use /Compress:Fast, exporting the image later using Max or Recovery
For managing size constraints, images can be split into multiple read-only .swm files via /Split-Image

Append Image:

# Windows ≥8: DISM
 Dism /Append-Image /ImageFile:"Z:\Base.wim" /CaptureDir:"C:" /Name:"Windows Backup" /Description:"Base Image 2020年08月29日 @ 11:30" /CheckIntegrity /Verify /ScratchDir:"Z:"
# Windows XP ≤ 7: ImageX
 ImageX /Append "C:" "Z:\Base.esd" "Windows Backup" "Base Image 2020年08月29日 @ 11:30" /Compress:Recovery /Check /Verify /ScratchDir:"Z:\"

Compression is locked to the value set when the base image was captured
Individual indexes can be deleted via /Delete-Image or exported to their own image via /Export-Image

Apply Image:

# Windows ≥8: DISM
 Dism /Apply-Image /ImageFile:"Z:\Base.wim" /Index:1 /ApplyDir:"C:" /CheckIntegrity /Verify /ScratchDir:"Z:"
# Windows XP ≤ 7: ImageX
 ImageX /Apply "Z:\Base.wim" 1 "C:" /Check /Verify /ScratchDir:"Z:\"

Prior to applying, get Image Info, ensuring correct index [image] is being applied:
```
Dism /Get-ImageInfo /ImageFile:"Z:\Base.wim"
```

If applying an OS image, the following must be run prior to exiting WinPE/WinRE:

BIOS:

BootRec /FixMBR && BootRec /FixBoot && BootRec /RebuildBCD

UEFI:

::# With existing bootable EFI partition:
 BootRec /FixMBR && BootRec /RebuildBCD
::# Without existing bootable EFI partition:
 ::# Create EFI directories and enter:
 MkDir "Y:\EFI\Microsoft\Boot"
 Cd /d "Y:\EFI\Microsoft\Boot"
 ::# Create EFI boot structure:
 BootRec /Fixboot
 ::# If Access Denied error occurs (C: is applied image):
 BcdBoot C:\Windows /s Y: /f UEFI
 ::# Resolve any other boot issues:
 BootRec /FixMBR && BootRec /RebuildBCD

Accessing data within a WIM or ESD

Read-only:

Mount Image: (as /ReadOnly)

# Windows ≥8: DISM
 Dism /Mount-Image /ImageFile:"Z:\Base.wim" /Index:2 /MountDir:"C:\Mount" /Optimize /CheckIntegrity /ReadOnly
# Windows XP ≤ 7: ImageX
 ImageX /Mount "Z:\Base.wim" 2 "C:\Mount" /Check

In lieu of this, I prefer opening the ESD/WIM within the 7zip GUI

Unmount Image: (/discard changes)

# Windows ≥8: DISM
 Dism /Unmount-Image /MountDir:"C:\Mount" /CheckIntegrity /Discard
# Windows XP ≤ 7: ImageX
 ImageX /Unmount "C:\Mount"

Make changes, or add data, to an image [index]:

Mount Image:

# Windows ≥8: DISM
 Dism /Mount-Image /ImageFile:"Z:\Base.wim" /Index:2 /MountDir:"C:\Mount" /Optimize /CheckIntegrity
# Windows XP ≤ 7: ImageX
 ImageX /MountRW "Z:\Base.wim" 2 "C:\Mount" /Check

Unmount Image: (/Commit changes)

# Windows ≥8: DISM
 Dism /Unmount-Image /MountDir:"C:\Mount" /CheckIntegrity /Commit
# Windows XP ≤ 7: ImageX
 ImageX /Unmount "C:\Mount" /Commit

If using DISM, to save changes as a new appended image, add /Append

Is the native method generally the best method for most users?

With the native method [WIMs/ESDs], no additional imaging tools or boot media is required since support is natively built-in to WinPE and Windows
Its impossible for WIMs/ESDs to become corrupted, provided /CheckIntegrity (ImageX: /Check) & /Verify are always used
Capturing and applying an ESD/WIM is not the best solution for all imaging [cloning] use cases, but is for most:
- Capturing an ESD/WIM requires a storage medium to house the captured image (partition not being imaged, USB drive, network share, etc.), serving the dual purpose of also being an actual backup base image
- Additional backups of the same partition can be appended to the base image with minimal [relative] file size increase, and while data from multiple partitions can be appended to the same base image, the smart compression feature benefits WIMs provide would be lost

WIMs/ESDs are smart compression image formats and therefore storage efficient:

Only changed files are added to an ESD/WIM when a new image [index] is appended to it; newly appended images utilize the same copy of unchanged files already contained within the image from the previous image(s) (hash verified) , allowing for an image to remain small in relation to the data within

Appended image example:

# Note Base.wim size compared to each index and sum of all data therein:
 PS $ ls -File
 Length Name
 --------------- -------------
 95,019,530,773B Base.wim
 568B Dism.cmd
 97B WimScript.ini
 PS $ Dism /Get-ImageInfo /ImageFile:Base.wim
 Details for image : Base.wim
 Index : 1
 Name : Alienware 18: Windows 10
 Description : v1803: Base (Drivers Only)
 Size : 22,710,283,446 bytes
 Index : 2
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (No Customizations)
 Size : 45,591,850,754 bytes
 Index : 3
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (Customized)
 Size : 94,958,267,312 bytes
 Index : 4
 Name : Alienware 18: Windows 10
 Description : v1809: Updated Applications
 Size : 114,959,954,040 bytes

PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:1
 Details for image : Base.wim
 Index : 1
 Name : Alienware 18: Windows 10
 Description : v1803: Base (Drivers Only)
 Size : 22,710,283,446 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17134
 ServicePack Build : 1
 ServicePack Level : 1
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 24288
 Files : 112665
 Created : 2018年05月05日 - 13:56:47
 Modified : 2018年05月05日 - 13:56:47
 Languages : en-US (Default)
PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:2
 Details for image : Base.wim
 Index : 2
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (No Customizations)
 Size : 45,591,850,754 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17134
 ServicePack Build : 1
 ServicePack Level : 1
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 45803
 Files : 203058
 Created : 2018年05月06日 - 01:55:47
 Modified : 2018年05月06日 - 01:55:48
 Languages : en-US (Default)
PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:3
 Details for image : Base.wim
 Index : 3
 Name : Alienware 18: Windows 10
 Description : v1803: Software Installed (Customized)
 Size : 94,958,267,312 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17134
 ServicePack Build : 1
 ServicePack Level : 81
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 62409
 Files : 350446
 Created : 2018年06月01日 - 19:09:51
 Modified : 2018年06月19日 - 21:26:18
 Languages : en-US (Default)
PS $ Dism /Get-ImageInfo /ImageFile:Base.wim /Index:4
 Details for image : Base.wim
 Index : 4
 Name : Alienware 18: Windows 10
 Description : v1809: Updated Applications
 Size : 114,959,954,040 bytes
 WIM Bootable : No
 Architecture : x64
 Hal : acpiapic
 Version : 10.0.17763
 ServicePack Build : 195
 ServicePack Level : 0
 Edition : Professional
 Installation : Client
 ProductType : WinNT
 ProductSuite : Terminal Server
 System Root : WINDOWS
 Directories : 87659
 Files : 452028
 Created : 2018年12月24日 - 04:27:13
 Modified : 2018年12月24日 - 04:27:15
 Languages : en-US (Default)

In contrast to WIMs/ESDs, Windows Image Backup and Backup and Restore (Windows 7) create a VHD image while booted to the OS using the Volume Shadow Copy Service [VSS], being no different than creating a VHD and using RoboCopy to copy all data, maintaining ACLs, to the VHD from the OS partition, and has:

little to no compression (storage inefficient)
no parity (lacks data verification)

total reliance on a myriad of external config, catalog, and binary files residing outside of the VHD to work correctly (in contrast to a self-contained WIM/ESD image), and if these become corrupted/modified or moved/deleted, a restore isn't possible and will fail:

# VM: EFI boot with clean install of Windows 11
 # Note VHD size versus ESD/WIM images of the same VM:
 # VHD (20.76GB)
 # WIM (9.23GB)
 # ESD (6.92GB)
PS $ ls -file
 Length Name
 --------------- -------------
 20,761,804,800B 87a69c87-81dd-4b7f-95a1-1bff3144b638.vhdx
 6,921,506,902B vm.esd
 9,238,800,695B vm.wim
PS $ tree -f
 | MediaID.bin
 | vm.esd
 | vm.wim
 |
 └─VM
 │ MediaID.bin
 |
 └─Backup Set 2024年03月19日 060426
 ├─Backup Files 2024年03月19日 060426
 │ Backup files 1.zip
 │ Backup files 2.zip
 │ Backup files 3.zip
 │ Backup files 4.zip
 │ Backup files 5.zip
 │ Backup files 6.zip
 │ Backup files 7.zip
 │ Backup files 8.zip
 │ Backup files 9.zip
 │ Backup files 10.zip
 │ Backup files 11.zip
 │ Backup files 12.zip
 │ Backup files 13.zip
 │ Backup files 14.zip
 │ Backup files 15.zip
 │ Backup files 16.zip
 │ Backup files 17.zip
 │ Backup files 18.zip
 │ Backup files 19.zip
 │ Backup files 20.zip
 │ Backup files 21.zip
 │ Backup files 22.zip
 │ Backup files 23.zip
 │ Backup files 24.zip
 │ Backup files 25.zip
 │ Backup files 26.zip
 │ Backup files 27.zip
 │ Backup files 28.zip
 │ Backup files 29.zip
 │ Backup files 30.zip
 |
 ├─Catalogs
 │ GlobalCatalog.wbcat
 |
 └─WindowsImageBackup
 └─VM
 │ MediaId
 |
 ├─Backup 2024年03月19日 130431
 │ 127dbd44-5431-4b1c-9500-426293266794.vhdx
 │ 87a69c87-81dd-4b7f-95a1-1bff3144b638.vhdx
 │ BackupSpecs.xml
 │ Esp.vhdx
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Components.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_RegistryExcludes.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml
 │ f714635b-5a6a-4163-9695-33ae3fa712a6_Writere8132975-6f93-4464-a53e-1050253ae220.xml
 |
 ├─Catalog
 │ BackupGlobalCatalog
 │ GlobalCatalog
 |
 ├─Logs
 |
 ├─SPPMetadataCache
 │ {f714635b-5a6a-4163-9695-33ae3fa712a6}

How does the native method differ from conventional cloning?

The vast majority of Windows users have no need for partition-level or disk-level images:

A conventional partition-level or disk-level image (contains offset, alignment, block size, etc.):
- Lacks native Windows support and therefore requires non-standard boot media (boot media that's not WinPE/WinRE) and third-party programs
- Often lacks compression by default, one of the main advantages of the WIM/ESD smart compression image format
- Locks the user to that specific partition or drive layout (offset, alignment, block size, etc.)
- Often has no data verification and is therefore subject to data corruption
DISM/ImageX creates a filesystem image, not a partition partition-level or disk-level image:
(Win ≥ XP uses NTFS as the default filesystem)
- When pointed at the root of a partition [C:\], DISM/ImageX captures an image of all data on that partition, but not the structure of the partition/drive itself (offset, alignment, block size, etc.), bypassing the inconvenience a conventional partition/drive image creates, as only filesystem data is contained within a ESD/WIM, allowing it to be applied to any partition, regardless of size difference or whether there is existing data on the partition.

What are the pros and cons of native versus 3rd party?

Third-party tools will almost always fall into one of two categories, Linux-based or Windows-based via DISM/ImageX/Powershell, with many resulting in configuration issues, and the latter sometimes encompassing developers who use proprietary image file formats and custom boot environments (many of which are Linux-based).

There's a minute number of posts on StackExchange (or Spiceworks) regarding imaging issues arising from using Windows' native DISM (Win XP ≤ 7: ImageX), however thousands of questions, answers, and comments exist for issues arising from third-party imaging tools:
- Windows cloning issue (2,751 results)
  Windows cloning problem (3,838 results)
- DISM:
  - Windows Dism /Capture-Image issue (60 results)
    Windows Dism /Capture-Image problem (44 results)
  - Windows Dism /Append-Image issue (20 results)
    Windows Dism /Append-Image problem (12 results)
  - Windows Dism /Apply-Image issue (85 results)
    Windows Dism /Apply-Image problem (93 results)
- ImageX:
  - Windows ImageX /Capture issue (19 results)
    Windows ImageX /Capture problem (20 results)
  - Windows ImageX /Append issue (10 results)
    Windows ImageX /Append problem (5 results)
  - Windows ImageX /Apply issue (15 results)
    Windows ImageX /Apply problem (12 results)
I have the perspective it's unacceptable for a Windows user to receive advice to use Linux tools to image Windows, as that's inefficient, forcing the user to rely on not only a non-native boot environment unsupported by Windows, but also on an image format unsupported by Windows, both of which over-complicate imaging.

Ever come across advice telling a BSD or Linux user to boot to Windows or use Wine to back up their data? For example, ntfsclone (part of ntfs-3g) is a popular Linux utility, with the following from it's man page:

Windows Cloning

If you want to copy, move or restore a system or boot partition to another computer, to a different disk, partition... or to a different disk sector offset, then you will need to take extra care.

Usually, Windows will not be able to boot, unless you copy, move or restore NTFS to the same partition which starts at the same sector on the same type of disk having the same BIOS legacy cylinder setting as the original partition and disk had.

The ntfsclone utility guarantees to make an exact copy of NTFS, but it won't deal with booting issues. This is by design: ntfsclone is a filesystem, not system utility; its aim is only NTFS cloning, not Windows cloning. Hereby ntfsclone can be used as a very fast and reliable build block for Windows cloning but [it] itself it's not enough.

WIMs/ESDs don't have these issues since they only contain filesystem information (files and directories), not partition/drive level data, allowing them to be applied to any partition, regardless of size difference or whether there is existing data.

Native Pros

WIMs/ESDs are natively supported by all Windows editions ≥ XP
- WIMs/ESDs are versatile and can be captured, applied, or modified when booted to WinPE (Windows install media), WinRE (Windows Recovery), or the OS
- WIMs/ESDs do not require additional tools or boot media since all required tools are built-in to all three environments
WIMs/ESDs are smart compression image formats, able to contain multiple images, backups or otherwise, within a relatively small single image file
Its impossible for WIMs/ESDs to become corrupted, provided /CheckIntegrity (ImageX: /Check) & /Verify are always used
WIMs/ESDs can be deployed remotely via PXE, even to a machine without an OS installed

Native Cons

Requires a storage medium for the captured image (another partition, USB drive, network share, etc.)
- If saving the image to a mechanical HDD, compression takes longer, so if wanting to use /Compress:Max or /Compress:Recovery, it's more efficient to use /Compress:Fast, exporting the image later using Max or Recovery
Capturing, Appending, Applying, or Exporting an image is resource-intensive
- Even though /CheckIntegrity (ImageX: /Check) and Verify do extend the image processing time, they should always be used

How do I configure system partitions on a new drive for applying an image?

Use DiskPart:

DiskPart
::# List disks:
 Lis Dis
::# Select OS drive # the image is being applied to:
 Sel Dis #
::# Wipe partition table (assumes no data on drive is being preserved)
 Clean

UEFI:

Convert gpt

Create boot partition:

BIOS:

Cre Par Pri Offset=1024 Size=100
Format Quick Fs=NTFS Label="Boot"
Active

UEFI:

Cre Par EFI Offset=1024 Size=100
Format Quick Fs=FAT32 Label="EFI"
Assign Letter=Y
Cre Par Msr Size=16

Create OS partition:
- Rest of the drive as the OS partition:
  If C: can't be assigned, change 3 & 5 to another letter
  BIOS:
```
Cre Par Pri
Format Quick Fs=NTFS Label="System"
```
  UEFI:
```
Cre Par Pri Id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Format Quick Fs=NTFS Label="System"
Assign Letter=C
```
- Additional partitions after the [200GB] OS partition:
  If storing User Data directories on a partition other than C:\ (recommended), max size required is ~300GB (multiply size wanted by 1024: 200*1024=204800)
  BIOS:
```
Cre Par Pri Size=204800
Format Quick Fs=NTFS Label="System"
```
  UEFI:
```
Cre Par Pri Size=204800 Id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Format Quick Fs=NTFS Label="System"
Assign Letter=C
```

Create WinRE partition: (should have minimum 320MB free for future WIM size increases)

BIOS:

Shrink Desired=1024 Minimum=1024
Cre Par Pri id=27
Format Quick Fs=NTFS Label="WinRE"

UEFI:

Shrink Desired=1024 Minimum=1024
Cre Par Pri Id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
Format Quick Fs=NTFS Label="WinRE"
Gpt Attributes=0x8000000000000001

Resolve any boot issues: (after WIM has been applied via Step 2 at TOP of answer)

BIOS:

BootRec /FixMBR && BootRec /FixBoot && BootRec /RebuildBCD

UEFI:

::# With existing bootable EFI partition:
 BootRec /FixMBR && BootRec /RebuildBCD
::# Without existing bootable EFI partition:
 ::# Create EFI directories and enter:
 MkDir "Y:\EFI\Microsoft\Boot"
 Cd /d "Y:\EFI\Microsoft\Boot"
 ::# Create EFI boot structure:
 BootRec /Fixboot
 ::# If Access Denied error occurs (C: is applied image):
 BcdBoot C:\Windows /s Y: /f UEFI
 ::# Resolve any other boot issues:
 BootRec /FixMBR && BootRec /RebuildBCD

Remove EFI mountpoint (if applicable) and Reboot
UEFI:
```
DiskPart
 Sel Vol Y
 Remove
 Exit
```

"Windows has always natively supported imaging of partitions or individual directories" is vast hyperbole. Windows was around long before Longhorn/Vista (which introduced ImageX, the predecessor to dism). Further, neither ImageX nor dismmeets the Question's demand for a "native way to image a Windows partition", since both image the filesystem on a partition. This is not merely semantics.
@JW0914 : "always", emphasis mine, is incorrect, as is your claim "Windows is installed via a WIM or ESD image". Windows 1, 2, 3.0-WfW 3.12, NT 3.5.0-4.1, 95, 98, 98SE all precede WIM, ESD, ImageX, and dism. I still install Win98SE from time to time; it, like many of the Windows I listed, is installed from CAB files. The WIM/ESD/ImageX/dism ecosystem didn't exist prior to Longhorn/Vista and I note that the Question doesn't specify a version or range of versions of Windows in text or in tags, so you have, at best, given a partial answer, incorrectly claiming universal scope.
It seems pretty misleading to call the stuff described in this answer an "image" at all. It's a file archive created by means of copying the files into a completely different filesystem, and nothing is ever imaged.
MS being flat out wrong in word usage is definitely nothing new, and goes back more than 20 years :)
@AlexS: wimlib allow read/write access to WIM —and probably ESD— archives since about 2013; interoperability with Microsoft ("native") tools is not perfect, so as always please backup first, but it can achieve useful things.

harrymc 501k33 gold badges621 silver badges1k bronze badges · Answer 2 · 2020-08-30 18:58:34Z

What is the most efficient, native way to image a Windows partition?

There isn't one any more since Windows Backup is being phased out (probably because this was a bad product to start with).

Only DISM is left, but it only does file backup, not partition image backup. Its new Full Flash Update (FFU) images takes a sector-by-sector image of the entire disk, which unfortunately also includes unused sectors, so not at all efficient.

Why is the native method generally the best method for most users?

It isn't for Windows, as above. Microsoft has left the field in favor of third-party products.

How does the native method differ from conventional cloning?

DISM does not do cloning at all.

What are the pros and cons of native versus third-party tools?

The pros of third-party tools is that they work well and efficiently. Most are also free to use.

Example products are AOMEI Backupper, Clonezilla, Macrium Reflect, EaseUS ToDo BackUp. YMMV.

Historical note: DISM was conceived by Microsoft decades ago in an ancient version of Windows (Vista), using the Windows Imaging Format (WIM), which is a file-based disk image format, used mostly for software distribution. For backup, Microsoft has created Windows Backup, of which a limited version is still available in Windows 10 as "Back up and Restore (Windows 7)", but without its problematic image backup feature. The use of DISM as a backup utility is very strongly not recommended.

Comments are not for extended discussion; this conversation has been moved to chat.
This answer would have been useful if it actually explained the pitfalls of using DISM for partition imaging/cloning purposes, instead of just opinionating against its use. I have one reason for not relying on DISM for partition cloning: it can't handle not-downloaded OneDrive file pointers. Otherwise, it always did it's job for an off-the-shelf tool.

Stack Exchange Network

What is the most efficient, native way to image a Windows partition?

2 Answers 2