I've had success with Sysinternals Process Explorer. With this, you can search to find what process(es) have a file open, and you can use it to close the handle(s) if you want. Of course, it is safer to close the whole process. Exercise caution and judgement.
To find a specific file, use the menu option Find->Find Handle or DLL... Type in part of the path to the file. The list of processes will appear below.
If you prefer command line, Sysinternals suite includes command line tool Handle, that lists open handles.
Examples
c:\Program Files\SysinternalsSuite>handle.exe |findstr /i "e:\" (finds all files opened from drive e:\"c:\Program Files\SysinternalsSuite>handle.exe |findstr /i "file-or-path-in-question"
Unfortunately this question only just showed up today in my RSS reader, so even though it's a couple years old I thought I'd offer what is probably the right answer for future readers.
I'm not familiar with the particular model you describe as affected, but this does sound rather similar to a problem which occurred in certain models of ThinkPad (my memory says T60) which used a non-standard multisector MBR that occupied several sectors of the boot track rather than the usual one, with the results being identical to what you describe.
Ghost's classic imaging format prior to the introduction of the -IB switch stored only the original single MBR sector; this means that images of systems which actually have nonstandard, multisector boot track content only have half of the necessary boot code in them.
In almost all situations where the source image was not taken with the -IB switch, if Ghost detects boot code in the target disk you are restoring to, it tends to leave the original boot code intact and just manipulates the partition table within the boot sector. This is by design to deal with systems that did use special boot code (such as those with boot-sector hooks to replace the BIOS), and means that in most cases if the target system needed such custom boot code it would be left alone and would continue to boot.
However, if the target disk is completely blank, Ghost will use the boot code from the image for the MBR sector. If, as with the ThinkPad case we found in our QA labs, you have taken the image with no extra switches then the sector it restores tries to load the rest of itself from later sectors in the boot track that by default Ghost leaves alone.
So, you have several options; you can use gdisk /mbr after restoring to force the use of a standard "safe" MBR instead of a manufacturer custom MBR, or you can use the -IB switch with Ghost when capturing the source image to force Ghost to image all the sectors in the boot track rather than just the MBR.
The above is what we discovered in our labs in Auckland where we developed Ghost (until 2009, when Symantec closed the site and cancelled development of the Ghost Solution Suite product); Krish Jayaratne who was our QA manager discovered this and did the main investigation as to the workarounds and it just then took a little inspection to confirm the presence of the extra boot code.
While your situation may not be the same, it certainly sounds exactly like that case and I suspect the resolution should be the same. I did walk customers through this a couple of times on the official Symantec forums and it was documented fairly thoroughly, but since the Ghost Solution Suite product was cancelled Symantec lost most of the institutional knowledge around this stuff.
Edit to add: as I noted above, Ghost on restore by default for "normal" images leaves boot code in the MBR totally alone if an existing MBR is present. However, if the -IB switch was used to capture an image that fact is recorded as part of the image file meta-data (in fact, this is true of quite a lot of the switches; part of the obfuscated file header has a big 'ol bit array in it populated from the global variables - yes, really - that the argument parser extracts the command-line switches into). So not only do images taken with -IB have a subtly different structure to accomodate the extra boot sectors, the restore side of the process "knows" that -IB was used to take the image.
My recollection of the process (although I don't have the source code any more to confirm it) is that if -IB was used to capture an image, by default the boot code and extra boot sectors would then always be restored, making the restore process have the opposite default handling of boot code to the regular images. Part of the logic behind that is that the restore UI doesn't have the boot code stored in the image in a selectable container - you don't have a way of expressing the choice of whether to restore it or not easily (adding that would be a bit of a usability complication; UI is never "free" if people don't grasp what it means). The other is that some of the most important users of Ghost were computer manufacturers who licensed it for their OEM restore disks; if a computer manufacturer's factory restore image contained custom boot code for some reason, then normally by default they'd want it put back and having -IB also imply that slight difference in behaviour on restore seemed like the "right" default.
It was always a delicate balancing act with these fancy special cases deciding whether to make the fiendishly complicated command line even more complicated or adding a new piece of UI to make things more explicit, versus trying to do the "Right Thing" by default for most people and not making the default UI complicated. There's no argument that we didn't always choose right, but we did always agonize over that balance, especially since we had millions of customers with scripts that we wanted not to break.
Best Answer
You are far better off using MDT to build your deployment. It looks like none of your steps create boot partitions.