That's a great question, and one that we hear a lot unfortunately. The worst part is, there's not a simple answer. Here's a list of some of the most common answers:
- The machine is taking longer than the 30 minute maximum timeout to fully boot
- The hard-coded resources provided to the test VM aren't sufficient
- There are driver issues with the VM
- The hypervisor you're using is supported by SPX VirtualBoot, but not by ImageManager
- The VM is booting to the Lock Screen, which then turns off the virtual display in 1 minute, resulting in a blank screenshot
- Mercury is in retrograde
- A butterfly flapped it's wings on the other side of the world
Obviously, I'm exaggerating a bit, but the unfortunate truth is that there are so many things that can go wrong with the automatic screenshot verification process, and most of them have nothing to do with the ability to actually VirtualBoot or restore your customers backups. That's why Servosity does not recommend using the Screenshot Verification feature, but suggests that you set up the automatic Volume Integrity Checking instead. It's a much more stable feature, and more reliable as well, for several reasons:
- It validates the data integrity on the entire drive, not just the OS files and boot configuration.
- It will verify all volumes, not just the boot volume.
- It uses the Microsoft Chkdsk tool to verify a mounted image, so no Hypervisor or virtualization is required.
- It can be run in a Single-Server environment, directly on the machine being backed up.
- An automated Virtualboot is less reliable than a manual one, offers no configuration options, and nearly all boot errors are easily repairable so long as the data is intact, which the chkdsk will ensure.
If you'd like to know more about what the "Check Volume Integrity" option does, and how to enable it, check out this KB article: Setting up ImageManager automatic Volume Integrity Checking