UPDATE: As per my experience here, no one responded. If I do not hear back from TechNet forum members about it, I will post a bounty here, if it makes a difference.

I have banged my head against a wall for what seems like all week. I am going to explain my simple procedure, and how none of it, absolutely none, seems to work afterword despite few alternatives and everyone on the internet telling assuming this is how to do it.

Diskpart Commands to Create FS Structure

REM Select the disk targeted for deployment.
REM NOTE: Usually disk 0, but drive failure can make it external USB
REM media. This will erase the drive regardless!
select disk 0    
REM Remove previous formatting.
REM Create System Reserved partition bootloader and files.
create partition primary size=100
REM Format the volume
format fs=ntfs label="System Reserved" quick override noerr
REM Assign the System Reserved partition the D: mount for now
assign letter=C
REM The main system partition, size not specified to occupy whole drive.
create partition primary
REM Format the volume
format fs=ntfs quick override noerr
REM Assign the OS partition the D: mount for now
assign letter=D
REM Make this the active/bootable partition.
sel disk 0
sel partition 1
REM Close out the diskpart session.

Now, I thought this was madness, but it turns out the System Reserved partition and standard "System Partition" (C:, commonly both the boot and system volumes where you find the Windows directory AND the bootmgr/ntldr hardware files, this is where Windows 7 diverges) as mounted in the Windows PE session where I run these commands do not matter. See reference here. Since this needs to be BitLocker-ready, enter this crappy System Reserved partition that is separate 100MB of awesome that goes before the regular boot volume. I do this, then I proceed to the next step.

Deploy System Reserved and Normal System Images

REM C is still the "System Reserved Partition", and the image is just like it sounds.
imagex /apply G:\images\systemreserved.wim 1 C: 

REM D is now what will be the C: system partition on reboot, supposedly.
imagex /apply G:\images\testimage.wim 1 D:

Reboot the system

Now, the images I just captured should look good. This is not even sysprepped, but reapplying the same fscking image I prepared on the same reference workstation hours before. Problem is I get 0xc000000e could not detect the accessible boot device \Windows\system32\winload.exe or different kinds of nonsense revolving around being able to find the boot volume with all the right files. I try different variations of things, now none of them work. I tried repairs with bcdboot, with a fresh System Reserved partition or not, bootrec, and maually editing the damn BCD store with bcdedit. I tried finalizing the above process with and without bootsect /nt60 C: /force. I need to wrap up and automate this procedure. What am I doing wrong that does not make the image happy, but really just miserable.

  • 1
    May I ask why you must have the system reserved partition? – Aaron Mason Sep 26 '13 at 6:57

I fully sympathise with your pain. This has been driving me crazy for several weeks. What's most annoying is that bcdboot isn't on any of my Windows Server 2008 boxes, despite every guide online saying it should be.

My situation is that we are unable to run a PXE server (long story) so have to manually apply the Windows image with WinPE. The image appears to apply OK, but when rebooting I get error "BOOTMGR is missing".

I tried booting into WinPE and replacing my Boot Configuration with the Boot Configuration Data Store Editor by running:

bcdedit /import X:\Windows\System32\config\BCD-Template

But this didn't work.

However, I am happy to say that I have now resolved this problem!

It's not terribly easy; you will need a working machine running the OS you are trying to install (either Windows 7 or Server 2008), as well as a remote server to copy the Boot Sector information to and from.

First off boot into the working machine with a winpe disk.


net use Z: \REMOTEMACHINE\Share



Now log on to the machine you want to build with a winpe disk.

Then run your excellently notated script above to create a 100Mb active partition and another partition which takes up the remainder of the disk.

Depending how you are installing the image you will either map a drive or access a CD, then apply the image with IMAGEX (I'm not going to go over this here, as it is covered extensively elsewhere) to apply the image to the D:.

We now need to get the BOOTMGR partition onto the 100Mb acive partition.


net use Z: \REMOTEMACHINE\Share


This will copy the BOOTMGR information across, but there will be some information missing (not sure why this is).

Now run

bcdedit /set {bootmgr} device partition=C:

run bcdedit /set {default} device partition=D:

run bcdedit /set {default} osdevice partition=D:

Reboot the box and you should be in Windows!

  • I guess this might solve the problem, but I think it is a variation of one the alternatives I tried. Truth be told, having given up a while back, I discovered in research that there is a unique GUID for identifying the drive. If you wipe and forget that GUID (or do not backup appropriately like you had), it is essentially game over. Oh well. – songei2f Sep 15 '11 at 9:44

You're mounting the system reserved partition as "C:" and the OS partition as "D:" per that diskpart script. I'd grab a copy of bcdboot.exe and run bcdboot d:\windows /S C: after you've applied the image and see what it gets you.

  • Sorry, one of the things I explicitly tried. But thanks for playing, haha. I get basically the same error, either modifying the applied System Reserved partition image or erasing, create a brand new partition, and letting bcdboot create the same BCD store settings over again. – songei2f Jun 9 '11 at 17:55
  • 1
    This actually works for me. Before I capture the image, I use bcdedit to delete all of the entries in the boot config. Then, I capture the image. As part of my apply image script, I set up the partitions, apply the image, then use bcdboot /s to create the boot config, then restart. Works flawlessly. Note, I have not tried it on a non-sysprepped image, but it should also work. – Mike Christiansen Jun 17 '12 at 6:22

If you wipe the disk, you have to use sysprep.

Vista and 7 both tie themselves to the volume serial number, which AFAIK, gets re-created when you do a clean or delete the volume.

Sysprepping should solve the issue you're having.

  • You read the question right: the point is to have a reference image before I sysprep, so I can tweak it/mod it, then re-seal with sysprep. This had been painless with NT5 (XP/2003), but because of what you describe it now seems impossible. In the past, I used virtual machines at a previous employer's office specifically to avoid this problem since we designed many customized images off a reference point image. I am not sure of the official procedure in the event you do not have/can afford VM infrastructure in MSFT's eyes, hence the question. – songei2f Sep 16 '11 at 15:55
  • @alharaka: you can sysprep a Win7 image 3 or 5 times before it won't allow sysprepping it again – Hubert Kario Jan 20 '13 at 21:51
  • If this is still an active issue, try audit mode. You'll run sysprep, with generalize and audit mode. Then you'll boot into audit mode, capture an image. This is your 'before sysprep' image. Then, once complete, you'll run it again, with oobe. Thats your 'after sysprep' image. – Mike Christiansen Jan 22 '13 at 23:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.