This was caused by the Lenovo Rescue and Recovery software update (4.2) altering the MBR.
Couldn't find a way to image and deploy with it installed so did factory install and removed the RnR software - we can do without it.
Tried wiping the drive first with Lenovo cleandrv.exe (as in RnR deployment guide) but the RnR update brings back the problem.
They do that sometimes, regrettably.
The only way in these scenarios that I know works, is pretty much wiping out the MBR itself, so that ANY traces of the RnR partition is gone, and to "just" deploy an OS image there.
Never figured out why it "sometimes just flat out won't work" ... just one of those things that keeps us in our jobs I think :(.
LANDesk EMEA Technical Lead.
For anyone who comes upon this post later, as I did, I've encountered the same issues attempting to reimage a Lenovo T61, which is, as far as I know, a pretty similar model. I was actually able to come up with a solution for reimaging these machines and maintaining the Lenovo RnR partition (which we needed, in our environment), but it took a bit of doing. Apparently the MBR gets mangled by the Lenovo partition, and it seems like something in the partition table is messed with too.
Lenovo has a tool to create a Rescue and Recovery Repair floppy disc (only a disc, not a CD, sadly; you'll need a USB floppy drive handy) which includes a tool to recreate the MBR. It allows for repairing the existing MBR, but that didn't work for me. However, even if you recreate the MBR, it still won't boot. The trick I worked with at that point was to redeploy only the Windows partition, and leave the Lenovo RnR completely untouched. Make sure to also comment out the rmvol.txt, wipedisk0.txt, and assvol.txt diskpart commands in the script, or they'll put you right back where you were. (Actually, it's safe to leave the assvol.txt in, but make sure you change the previous line to partition=2 to make sure the right partition gets marked as active.) After *both* recreating the MBR and reimaging the Windows partition, I was able to get the machine to load fine, sysprepped and all.
As far as I was able to determine, ImageW supports partition imaging only through the GUI and not by commandline - it may do that, but I couldn't find a commandline switch to make it operate that way. I didn't try too hard though, admittedly, because I've been using Ghost32.exe to handle the imaging, which I found while working on this that for us does better compression than ImageW. For those that don't have Ghost licenses, though, ImageW's GUI allows deploy of partitions (I actually used it to redeploy the previously-dumped *01.IMG partition without any problems).