From the Wikipedia article on UEFI:
The UEFI specification explicitly requires support for FAT32 for system partitions, and FAT12/FAT16 for removable media; specific implementations may support other file systems.
Personally I've yet to encounter any motherboard manufacturer who has implemented NTFS boot support in their UEFI modules.
Update: As mentioned in the comments below, two years after I posted the above there are now at least a few motherboards available with UEFI NTFS modules.
On a normal hard disk installation of most any EFI-based OS, you'll have, at a minimum, one FAT EFI System Partition (ESP) and one partition for the OS itself. The ESP holds a boot loader for the OS, possibly along with files to support the boot loader (fonts, configuration files, drivers, etc.), and possibly even the OS's kernel. The OS partition holds more-or-less the same OS files you'd find on a BIOS-based installation of the same OS. Depending on the OS, you might have additional partitions, too -- data partitions, a swap partition, etc.
There can be exceptions to this rule, particularly for installation media or emergency disks. For instance, you could put the whole OS in the ESP. Also, most EFIs are happy to boot from partitions that are not ESPs, so you could just have one big non-ESP FAT partition, as you've got. This can work fine for an emergency disk, but I wouldn't recommend setting up a regular OS installation in this way; I'd use a separate ESP and OS partition.
Note that a standard EFI can read FAT, but cannot read NTFS, ext2/3/4fs, HFS+, or any other filesystem. (Apple's EFI can read HFS+, and so can read its boot loader from a Mac OS X root partition rather than from the ESP, but Apple's EFI is the exception rather than the rule. A few EFIs also have ISO-9660 filesystem drivers -- but again, they're exceptions to the rule.) Because FAT is the only filesystem that's guaranteed to be readable by EFI, an attempt to build a boot disk that does not include a FAT partition is doomed to failure, except of course when used on those unusual EFIs that support additional filesystems.
I can't provide a procedure to set up a Windows emergency disk to use separate EFI and Windows partitions, since I'm more of a Linux person than a Windows person. Unless you run into a specific problem with your approach, though, I'd just stick with it; at least you know it works.
Best Answer
You need to keep applications out of your image. If your .wim file is that big, you're doing it wrong. Use the Microsoft Deployment Toolkit 2013 to deploy a thin image and push all applications, drivers, and updates at deploy time, its actually pretty easy. MDT 2013 will even build a bootable iso file you can load to USB via Microsoft's iso to USB install tool. I suspect you're actually making this process more labor intensive than it needs to be.
Another option is to use a deployment share like I'm suggesting, but for now push these massive images across the network. Use multicast in Win2k8 if you can w/ WDS. But that's really a Band-Aid, I say you still just rebuild the image, but keep it as thin as possible and This way your image is kept lean, clean and mean. You can use always use MDT 2012 to install all apps at deploy time. If your image is way too "thick" try to keep images as lean as possible.
Always, Always, ALWAYS, build your images in VMs, to keep them hardware independent. MDT will do drivers at deploy time , so there's no need to put drivers in your image.
If you're really just trying to capture a modified OEM image, understand OEM licensing doesn't include "reimaging rights" while that's legal issue, technically, you may get away with building a capture task sequence in MDT that will do the capture for you, and you could get away with pushing that captured image with standard client deployment sequence.
First off, you need to get MDT 2012 Update1 and the Win8 ADK installed.
Create a VM. Next you need to set up a VM we can use to build the image in. I prefer HyperV, but if you’re broke and/or cheap, virtualbox will work just as well. Some of my earliest images were built using this. Regardless of how you build the VM, allocate 2 gigs if you can for the VM.
Find a copy of Windows8. You’ll obviously need a copy of Win8. As of now, you’ll need either a retail ISO or find the
wim
file somehow. If you have a TechNet subscription like me, you’re in business. In your case, see if you can find one in the recovery partition or recovery media.Build Your Share. A Standard Client Task Sequence is Fine. If you plan on putting office in the image, add Office into applications, and configure it for an unattended install if you can, if not you may get away with doing that when lite touch suspends.
Import the OS. In that share you import the
.wim
file into operating systems. You don’t needsetup.exe
files for Win8. DISM handles it.Build a task sequence. Set
capture=yes
in yourcustomsetting.ini
file and customize your unattended.xml file.Configure your share. Remember, if we’re building a reference image, we want it up to date, so turn on updates in the task sequence before and after applications.
Update the share. Right click the share in the left menu and select update. This takes some time, so go watch some lite touch unleashed in the meantime.
Load the
litetouch.iso
file in the boot folder to USB using the Microsoft tool. Boot to USB, and away you go!Check out my guide here : Build a Windows 8 Image in MDT 2012