Scheduled tasks brick client hard drive?

[apmt]

Last year I had captured an image of a server (Windows 2000 5.00.2195 Service Pack 4) via scheduled task that had completed successfully and had no adverse effect on the client.

A few days ago that server that wouldn’t boot into Windows. POST/BIOS were fine but the OS complained about registry corruption.

I swapped to a new drive and deployed the image through the FOG dashboard via a scheduled task but this caused the server to fail POST. The server would not get past the initial boot message screen.

I confirmed the other hardware components were fine by mounting a (second) new drive and confirming PXE boot into FOG. I tried deploying the image again but ran into the same issue with POST failing.

Later, I used an Acronis image and Acronis TrueImage to restore a drive successfully. I confirmed that this drive was bootable.

I assumed that the image I had taken with FOG was corrupted so I captured a new image with this drive through the FOG dashboard (scheduled task) but after the task completed the drive was no longer bootable. For some reason even capturing an image bricked the hard drive.

Logs on the server don’t seem to capture anything relevant and I haven’t seen any error messages.

Has anyone experienced client drive corruption after running tasks? Any help would be greatly appreciated.
Thanks in advance.

[lukebarone]

@apmt Can you confirm for me that when you say the POST is failing that you are, in fact, talking about the POST process through the motherboard starting up, and not about Windows attempting to start up?

Have you ran a memory test on this system?

[Tom Elliott]

@apmt FOG makes not configuration changes to your motherboard, just to the HDD.

While there is potential “corruption” available in the form of shrinking/re-expanding the hard drive, this wouldn’t cause the system to not POST which leads me to believe what you’re experiencing is indeed a corruption of the captured (then) and deployed image, not an effect directly from FOG.

Acronis, and many other imaging systems, use a 1:1 copy, whether using file transfer or block copy system. You can do the same thing with FOG by choosing a non-resizable image.

With that said, I guess it’s potential possible the images on your FOG server could be corrupted, with say a SMART issue on the drive that’s containing your images that only seems to rear its head for this particular image.

Just wanting to gather details. The fact that you can image other machines fine (from what I can tell, or have been able to in the past) seems to indicate an issue that’s shown up relatively recently and could be at the FOG Server, but not (in the sense I think you’re thinking) a direct cause of FOG as a software.

[Tom Elliott]

@apmt I should also add, scheduled Tasks simply queue tasks just like anything else does. It does nothing to your physical system, that’s all handled by the task itself. Scheduled Tasks, just schedule things on the UI/backend, not actually configuring things within your BIOS, unless you have scheduled a snapin that might make changes as you’ve configured them to do.

[apmt]

@tom-elliott Thank you so much for the info. I will attempt to take a raw image of the drive and deploy it. I will report back soon.

Just wanting to gather details. The fact that you can image other machines fine (from what I can tell, or have been able to in the past) seems to indicate an issue that’s shown up relatively recently and could be at the FOG Server, but not (in the sense I think you’re thinking) a direct cause of FOG as a software.

Unfortunately, this is the first time we have actually deployed an image so I cant confirm that.
But is there a way I can log the imaging process (capturing and/or deploying an image) to see potential errors? I have made sure there is full access between the server and client (disabled the firewall, etc.) and confirmed there are no snap-ins.

Thanks again.

[apmt]

@lukebarone Thanks for looking into this.

Can you confirm for me that when you say the POST is failing that you are, in fact, talking about the POST process through the motherboard starting up, and not about Windows attempting to start up?

Yes. When the server powers on it hangs on a “hardware summary” screen. I am unable to even enter the BIOS setup menu (I hit F2 and it continues to hang).

Have you ran a memory test on this system?

I have run a memory test which passed with no errors reported.

I’m going to attempt to take and deploy a raw image and see if that makes a difference.