Virtual Lab Domain Controller Reboot

[tbrownfield]

I have a lab that includes a domain controller and I've selected the tests for domain controller, global catalog and DNS. I have the OS timeout set to 2100 seconds and the application timeout set to 600 seconds. It's hit and miss whether I can get the lab to stay up without being automatically destroyed because Veeam will try to run the application tests just as the lab domain controller does a reboot to repair active directory (which I finally figured out from the lively thread here: http://forums.veeam.com/veeam-backup-re ... 00-60.html.) Even though I see an entry of "Note: Will proceed to the next step at 9/10/2014 3:59:23 PM or earlier" it never waits the full amount of time and goes with the "or earlier" option. It sometimes only waits a few minutes then moves on to the application testing just as the domain controller starts shutting down services to reboot. The tests fail and the lab gets burned. My workaround right now is to just try it again and cross my fingers that the DC will be up and running at the point in time the app tests run, which works sometimes. What am I missing? How can I ensure that it will wait long enough for the automatic reboot to complete before trying the tests? Thanks!

[veremin]

So, you're saying that a surebackup job never takes the specified application timeout into account, right? Thanks.

[tbrownfield]

The OS maximum allowed boot time is set to 2100 seconds but it doesn't wait that long before running the application test scripts. Even though it's set to allow 35 minutes to boot, it only waits just over 10 minutes usually before starting the app tests. It takes a really long time for this DC to come up in the lab so it reboots right around this time causing everything to fail. My workaround right now is to just keep retrying the job until it hits it just right where the reboot and testing don't coincide so it stays up.

[nefes]

Algorithm of SureBackup job should wait some time after VM reported it's IP to avoid the situation you have.
Usually it works, but in your case it seems that storage is quite slow so VM prepares to reboot too long, and job thinks that it will not reboot.
Please open support case so our engineers could help you to set up correct settings to the job, to make it wait longer for reboot.

[tbrownfield]

Will do. Thanks!