I set up a new virtual machine using Microsoft’s new scripts.

Then I captured an image from the virtual machine with FOG and multicast it to four computers, and they all UEFI booted fine.

The new CreatePartitions-UEFI.txt puts the system partition first, instead of the recovery tools partition. This supports @george1421’s theory that FOG was confused when it found the recovery tools in the first partition, instead of the EFI (“System”) partition.

Thank you for your help!

rem == CreatePartitions-UEFI.txt ==
rem == These commands are used with DiskPart to
rem    create four partitions
rem    for a UEFI/GPT-based PC.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
convert gpt
rem == 1. System partition =========================
create partition efi size=100
rem    ** NOTE: For Advanced Format 4Kn drives,
rem               change this value to size = 260 ** 
format quick fs=fat32 label="System"
assign letter="S"
rem == 2. Microsoft Reserved (MSR) partition =======
create partition msr size=16
rem == 3. Windows partition ========================
rem ==    a. Create the Windows partition ==========
create partition primary 
rem ==    b. Create space for the recovery tools ===
rem       ** Update this size to match the size of
rem          the recovery tools (winre.wim)
rem          plus some free space.
shrink minimum=500
rem ==    c. Prepare the Windows partition ========= 
format quick fs=ntfs label="Windows"
assign letter="W"
rem === 4. Recovery partition ======================
create partition primary
format quick fs=ntfs label="Recovery"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
list volume
exit

I set up a new virtual machine using Microsoft’s new scripts.

Then I captured an image from the virtual machine with FOG and multicast it to four computers, and they all UEFI booted fine.

The new CreatePartitions-UEFI.txt puts the system partition first, instead of the recovery tools partition. This supports @george1421’s theory that FOG was confused when it found the recovery tools in the first partition, instead of the EFI (“System”) partition.

Thank you for your help!

rem == CreatePartitions-UEFI.txt ==
rem == These commands are used with DiskPart to
rem    create four partitions
rem    for a UEFI/GPT-based PC.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
convert gpt
rem == 1. System partition =========================
create partition efi size=100
rem    ** NOTE: For Advanced Format 4Kn drives,
rem               change this value to size = 260 ** 
format quick fs=fat32 label="System"
assign letter="S"
rem == 2. Microsoft Reserved (MSR) partition =======
create partition msr size=16
rem == 3. Windows partition ========================
rem ==    a. Create the Windows partition ==========
create partition primary 
rem ==    b. Create space for the recovery tools ===
rem       ** Update this size to match the size of
rem          the recovery tools (winre.wim)
rem          plus some free space.
shrink minimum=500
rem ==    c. Prepare the Windows partition ========= 
format quick fs=ntfs label="Windows"
assign letter="W"
rem === 4. Recovery partition ======================
create partition primary
format quick fs=ntfs label="Recovery"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
list volume
exit

@george1421 said:

While this is a philosophical question, but is a recovery partition even necessary (today) if you have an imaging solution in place?

Unfortunately, yes. We ship the computers to people working remotely, and sometimes we need the recovery partition to resolve issues in the field without them having to ship the computer back to us.

I noticed that Microsoft’s scripts that we’re using have been updated since I last looked at them 5+ years ago, so I’ll try creating an image with the new scripts and see if that makes a difference.

@Sebastian-Roth, here’s a download link for d1.mbr.

Thanks so much for your help!

I’ll try running diskpart /s HideRecoveryPartitions-UEFI.txt (link) on the source machine and see if that prevents FOG from getting confused.

Prior to using FOG, we imaged computers individually from a USB drive. We booted to Win PE and ran diskpart /s CreatePartitions-UEFI.txt and ApplyImage-UEFI.bat Win10v1909.wim (source).

We used that process when setting up the source computer.

Here are the contents of CreatePartitions-UEFI.txt:

rem == CreatePartitions-UEFI.txt ==
rem == These commands are used with DiskPart to
rem    set up the drive and ecreate five partitions
rem    for a UEFI/GPT-based PC.
rem    Adjust the partition sizes to fill the drive
rem    as necessary. ==
select disk 0
clean
convert gpt
rem == 1. Windows RE tools partition ===============
create partition primary size=300
format quick fs=ntfs label="Windows RE tools"
assign letter="T"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
rem == 2. System partition =========================
create partition efi size=100
rem ** NOTE: For Advanced Format 4Kn drives,
rem          change this value to size = 260 **
format quick fs=fat32 label="System"
assign letter="S"
rem == 3. Microsoft Reserved (MSR) partition =======
create partition msr size=128
rem == 4. Windows partition ========================
rem ==    a. Create the Windows partition ==========
create partition primary 
rem ==    b. Create space for the recovery image ===
shrink minimum=15000
rem ==    c. Prepare the Windows partition ========= 
format quick fs=ntfs label="Windows"
assign letter="C"
rem === 5. Recovery image partition ================
create partition primary
format quick fs=ntfs label="Recovery image"
assign letter="R"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
gpt attributes=0x8000000000000001
list volume
exit

Thank you for the response.

Here are the contents of /images/Win10v1909/d1.partitions:

label: gpt
label-id: FF49A6C2-3C34-40F5-8F80-D56539F0A596
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 500118158

/dev/sda1 : start=        2048, size=      614400, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=0AB00D6D-C20F-4585-A4A8-0E38EB2D9A49, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=      616448, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=549668CE-D282-4FFD-9681-949F2CE71769, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=      821248, size=      262144, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=9DA83316-BE94-44B9-8FBF-785A19055ED1, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1083392, size=   468314112, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=F517EAB8-B856-4F95-9B98-77C985D2A4C1, name="Basic data partition"
/dev/sda5 : start=   469397504, size=    30720000, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=402020BF-E7B1-47AD-8B19-CBCF229B0331, name="Basic data partition", attrs="RequiredPartition GUID:63"

For what it’s worth, I’m using Fog version 1.5.8.

Here are the settings I used for the image:

Here are the settings I used for the target computers (“Hosts”):

Hello,

I used FOG to capture an image from a computer with a GPT-layout disk (GPT is needed to support UEFI boot).

I applied the image to seven computers using multicast, but after the deployment was done, the computers’ disks were all set up in MBR layout, instead of GPT. Consequently, I was unable to UEFI-boot these computers. Once I turned on Legacy Boot in the BIOS settings, the computers booted to Windows fine.

I booted the target computers to WinPE and used Mbr2Gpt to convert the disks to GPT layout:

mbr2gpt /validate /disk:0
mbr2gpt /convert /disk:0

Once that was done, I was able to UEFI-boot the target computers to Windows.

I assumed the disk image would include the disk layout (GPT or MBR) of the original disk, but it appears that is not the case.

Is there a way to get FOG to partition the disks with GPT layout instead of MBR layout so I don’t have to manually convert to GPT after deploying the image?