KACE Product Support Question

K2000: BOOTMGR missing on 64-bit images

09/26/2013 8081 views

Our K2100 is on version 3.5.80613.  We've been successfully deploying 32-bit images for a long time, but I went to do a 64-bit one for Win7 Ent SP1 and when the system reboots after deployment I get "BOOTMGR missing".  I can use the original Microsoft disk to do a repair and it says "boot manager missing or corrupt" and it does its thing and it's all fine.

I'm using a 64-bit KBE created with the "latest" version of the AIK and the A08 driver pack.  My deployment looks like this, which is identical to my 32-bit deployment except where noted:



     select disk 0
     create partition primary size=10000
     format quick fs=ntfs label="Recovery"
     create partition primary
     format quick fs=ntfs label="Windows"

INSTALL VISTA/2008/7/8/2012 MBR
     bootsect.exe /NT60 c:





As mentioned above, that's all the same process and the same steps I use for the 32-bit deploys which work just fine.  Is there something specific to 64-bit that I'm missing?

3 Comments   [ + ] Show comments


  • Are you deploying a syspreped image?
  • Yes. I think I've figured it out and am currently testing that theory. When I built my original image, I wasn't paying any particular attention to the partitions on that disk. Going back and looking at it, it has four partitions and we normally deploy with just 2. I'm thinking it's possible that BOOTMGR is on a different partition on that source installation. Stand by.
  • I am having the same problem as the original poster. I only captured drive c:\ so am not dealing with the recovery partition. I have successfully deploy this image before so I don't know what might have changed.

All Answers


The only thing I have different I format the drive prior to MBR.

Answered 09/27/2013 by: SMal.tmcc
Red Belt


I remember KACE releasing a kb article involving the windows 7 recovery partition. I followed it back when I wanted to keep the recovery partition. I have since changed my mind but Lets see....

Pay close attention to post install task that is created. The issue is most liekly as nheyne suggests the WinPE is improperlly assigning letters to your drive.


Answered 09/27/2013 by: RandomITPro
4th Degree Black Belt


You need to specifiy partition letters (recovery will be C) and which partition Windows is on by using a midlevel bat script. The recovery partition is recognized as C: in KBE, and is also where the bcd is stored. As an aside, if possible I would strongly recommend scrapping the recovery partition and going with a single partition as it cuts out this sort of confusion and the KBE command line has all of the functionality of the Windows recovery tools.

bcdedit /store C:\boot\bcd /set {bootmgr} device partition=C:
bcdedit /store C:\boot\bcd /set {default} device partition=D:
bcdedit /store C:\boot\bcd /set {default} OSdevice partition=D:
Answered 09/30/2013 by: mpace
Red Belt


Turns out, at least in my situation, the problem wasn't with the deployment side - it was with the image capture side.  As shown above, normally we deploy with two partitions, the recovery (unneeded, but nonetheless present) and the OS.  When I was building my image source system, I just grabbed whatever disk was laying around and replaced the existing Windows install with my new install.  THAT disk turned out to have four partitions on it.  Why, I don't know, because we don't ever do any dual-boot or anything like that.  At any rate, the BOOTMGR must have been on another partition and therefore not included in the image I captured.  My solution (more of a workaround, I suppose) was to deploy the image to a "properly" partitioned disk, then use the OEM Windows disk to do a repair, and then capture a new image from THAT disk.  I now have a functioning image.  Thanks to all for their suggestions!

Answered 10/01/2013 by: toddhobdey
Yellow Belt


It's probably because you're not assigning letters to the two drives you're partitioning.  Diskpart is probably assigning the letter C to your Recovery partition so you're installing the boot record to that partition instead of the one containing your image.  Run your diskpart commands in a command prompt and then see what letters are assigned to which partitions.

Of course that doesn't explain why it would work in 32-bit, but it really seems like this is the issue.

Answered 09/27/2013 by: nheyne
Red Belt

  • Just curious, why are you installing a recovery partition?
    • Honestly? I don't have a good answer for that. We started out trying to replicate the partitioning and diagnostics, etc, that Dell ships on new systems. And ideally we were trying to figure out a way to have the base image stored in a partition so that a machine could be recovered at one of our remote sites instead of being sent back to corporate for reimaging. But that whole thing was something we never had the time to finish up, and we removed the "OEM" partition from our imaging plan and never really finished doing anything else with that part of it.
      • If you're using WIM imaging, that is probably as fast if not faster than using a recovery solution in my experience. And it makes partitioning simpler. Well, of course if you don't count relocating the physical machine to image.
      • I knew that a recovery partition wasn't really worth the hassle to deal with, but I did like an OEM partition because it included the DELL diagnostics that my techs were required to run. I ended up writing a script that utilized diskpart to detect OEM partitions if present and install, partition accordingly. I could share if you'd like.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ