This caught me by surprise. I am working on an article about doing scripting in Veeam Availability Orchestrator. Pretty interesting stuff – passing parameters through to the script that is executing inside a VM during a failover. However, I found an odd error. I was tweaking a script and loading it into VAO and doing a test failover. I had done it over and over a few time. I was on test 5. So during a failover I got an error – not with my script but with connecting to the replica.
So my guess is that I need to do another replication. So I am doing some Windows updates in the VM, and will manually replicate outside of the schedule. While the updates occur, I make sure I can log into the source VM with no issues.
So the replication worked. Not sure exactly why, but I thought it would. And glad I can get back to the script testing!
This actually occurred in the test, when VAO reached out to the VM to execute the script. The issue was that I had left the AD Domain Controller – which was part of the virtual lab – running for a fair number of days. So some sort of AD timeout caused the error. I powered off the virtual lab, and did a manual sync of the DC, and tried the test again and all worked fine. The reason I left the virtual lab running was to make the tests run faster.
I am sharing this as it may occur to you when you are running a lot of tests, over and over in VAO.
Don’t forget that you can find all of the VAO tech articles using this tag.
- 12/4/17 – so the morale of this story is to leave the virtual lab running for a day or two while you are doing a lot of testing but then turn it off. This allows replications to occur, and that helps minimize AD issues, but the fact is the VL running helps speed up your labs, and makes it more like a real test of a real failover.
- 12/3/17 – I solved a symptom. Which is not so useful. But I also figured out the real problem.
- 12/3/17 – looks like other things can cause this too. Investigating.
- 12/3/17 – published.
=== END ===