[mdt] Deploying to Dell Optiplex 3060

[IanN]

We have recently purchased a number of Dell Optiplex 3060 which are UEFI boot only devices for internal storage.

We are using MDT 8450 with ADK (for Win10) v1607

The image is pulled down to the new PC but for some reason the relevant UEFI partitions are not being created.

Does anyone have any suggestions on how to get this working?

Thanks

[JackCPickup]

Have you included the partitioning in the task sequence?

[IanN]

Have you included the partitioning in the task sequence?

Yes, there is a task for Formating and Partitioning for UEFI in the task sequence

[IanN]

Just had a conversation with Dell Technical Support, they are saying that MDT is currently incompatible with motherboards which take 7th and 8th gen processors.

Not sure whether that is true but if it is why I cannot find anything on the wider internet saying that is the case.

[Arthur]

Just had a conversation with Dell Technical Support, they are saying that MDT is currently incompatible with motherboards which take 7th and 8th gen processors.

The Windows PE version included with the 1607 ADK doesn't officially support 8th gen Intel processors so the first thing I would try is to update to the latest ADK (or at least the 1709 ADK) and regenerate your MDT boot images(s).

 

This may solve the issue you are having with your Dell PCs.

 

Windows Processor Requirements

 

Edited July 20, 2018 by Arthur

[IanN]

We've updated to Windows ADK 1803 but it has still not fixed the issue. We have forced the creation of the UEFI partitions by disabling the Task Format and Partition for BIOS and removing the IsUEFI check for the Task Format and Partition for UEFI but it is not adding the bootx64.efi into the partition.

Do we need to have built and captured a Windows 10 UEFI machine first?

[sted]

We've updated to Windows ADK 1803 but it has still not fixed the issue. We have forced the creation of the UEFI partitions by disabling the Task Format and Partition for BIOS and removing the IsUEFI check for the Task Format and Partition for UEFI but it is not adding the bootx64.efi into the partition.

Do we need to have built and captured a Windows 10 UEFI machine first?

 

did you do a complete regeneration of the boot file as i think thats the only way a new adk gets into the boot file

[Arthur]

did you do a complete regeneration of the boot file as i think thats the only way a new adk gets into the boot file

^ This! If the boot images weren't regenerated, just installing the ADK wouldn't have made any difference.

[Arthur]

Do we need to have built and captured a Windows 10 UEFI machine first?

No. IIRC, an image captured on a non-UEFI PC/VM will also work on a UEFI-based PC/VM.

 

How was your original image created? If it was from a physical PC (rather than a VM) that can also be an issue.

[IanN]

^ This! If the boot images weren't regenerated, just installing the ADK wouldn't have made any difference.

Yes, we regenerated the boot images.

 

- - - Updated - - -

 

No. IIRC, an image captured on a non-UEFI PC/VM will also work on a UEFI-based PC/VM.

 

How was your original image created? If it was from a physical PC (rather than a VM) that can also be an issue.

 

It was captured from a non-UEFI physical PC.

Edited July 23, 2018 by IanN

[Arthur]

It was captured from a non-UEFI physical PC.

I would recreate the image on a VM to rule out the physical PC being the cause (or better still use Microsoft's install.wim as is and make all of your changes through the task sequence).

 

https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/create-a-windows-10-reference-image

 

The reference image described in this documentation is designed primarily for deployment to physical machines. However, the reference image is created on a virtual platform, before being automatically run through the System Preparation (Sysprep) tool process and captured to a Windows Imaging (WIM) file. The reasons for creating the reference image on a virtual platform are the following:

 

• You reduce development time and can use snapshots to test different configurations quickly.
  
• You rule out hardware issues. You simply get the best possible image, and if you have a problem, it's not likely to be hardware related.
  
• It ensures that you won't have unwanted applications that could be installed as part of a driver install but not removed by the Sysprep process.
  
• It's easy to move between lab, test, and production.
  

[IanN]

So the answer to my problem was DHCP settings. We needed to get DHCP working for PXE booting over UEFI, we found the answer here:

https://www.coryfiala.com/using-dhcp-to-boot-wds-sccm-bios-and-uefi/