Instant recovery NIC default changed

[TitaniumCoder477]

It appears the "Connect VM to network" checkbox for the Instant VM recovery wizard has changed from "unchecked by default" to "checked by default" from 10.0.1.4854 to 11.0.0.837. We use Instant VM recovery for testing one off VMs, and I got burned by this so many times years back before the default was changed. I have never ceased to "be in the habit" of double checking this, and it saved me once again when I just upgraded and went to perform a test and found the checkbox marked. I sure hope this change of default was unintentionally or at least can be turned off somewhere. If not, I will have to tell our engineers over and over to watch for the final check box because otherwise there is a high chance they'll power up a backup server on network instead of sandbox by default.

(And please don't tell me that the production server should be off because that's nonsense. It's a perfectly legitimate use case to choose Restore Mode "Restore to a new location...", add a suffix "_testrestore" to the Restored VM name, and then power up in a sandbox. This makes a heck of a lot more sense than setting up an entire SureBackup Verification for just one off tests here and there.)

[Andreas Neufert]

Hallo James,

I checked in my lab as well and I can confirm that the checkboxes are enabled by default with latest version. I know as well that this was the case some years ago. A collegue of mine is checking with our QA what the situation with v10 was and why it was changed back to the original processing.

[Egor Yakovlev]

The main idea of Instant VM Recovery was always to bring dead servers back, as soon as possible, with least amount of administrative effort. With every release we are expanding Instant Recovery possibilities, adding new platforms to Instantly Recovery "to's" and "from's" with more and more people using it.
The change to connect VM to network by default was made to make recovery yet even more straight forward, because otherwise every time you run Instant Recovery to actually restore dead production server you need to check and tick that option. A stick with two ends it is...

I'll note down this case and see if that becomes popular enough to add a custom reg key switch in the future versions.

/Thanks!

[TitaniumCoder477]

The problem is that having the NIC connected by default is a potentially destructive situation which warrants the non-destructive action being the default. This is common sense UI design. We already have to be mindful of the restore type and making sure to add a prefix or suffix, but I recognize such cannot be avoided. But a simple checkbox? There's no reason to have that set by default to a potentially destructive choice. When someone is actually doing a DR, they are looking at every option carefully. They are not just moving as quickly through it as possible, like MSPs are when the are performing sandbox tests for individual assets for many clients. The potential for human error is low in the former (and non-destructive anyway because the worse thing you have to do is connect the NIC after the fact in the hypervisor) but high in the latter (and destructive under the presence default). Anyway, I have made my case.

If Veeam wants to set defaults like this, the least they can do is also give us an Options or Settings view where we can override this or customize this behavior. I would rather have to override this setting once for all our clients' BNR servers (which, if it was a Registry setting or a setting that could be modified through the PowerShell cmdlets, I could even automate) than try to make sure every engineer remembers to uncheck it for every sandbox test for every client.

[Andreas Neufert]

This is what Egor shared, his idea was to add a registry key to control the default.

A very important point is that without the network connection the restores do not process the needed recovery steps. For example an AD server will not be placed in Authorative restore mode, and exchange server will not process VSS recovery,...

You could argue in both ways here.

[TitaniumCoder477]

Any idea if/when we'll have a registry key? I can easily push that out to our clients via RMM to control the default behavior. We do more testing than we do actual restores (thank heavens!), so this change of default is more dangerous than it is helpful.

[Egor Yakovlev]

No clear ETA.
So far there is little to none feedback about this behavior from other sources.
/Thanks!

[TitaniumCoder477]

I suspect the lack of noise is more indicative of few people doing regular sandbox testing, rather than few people finding this to be a problem. And please don't mention SureBackup. I highly doubt many comparable MSPs are using that "feature" any more than we are. It's also a pretty dark topic for me at the moment, helped only by the reality that Gostev brought to light in my forum post regarding it. Bottom line--we test, 3-4 clients each month, using the IR + NIC disconnected to literally log into a server and examine it, documenting results for our clients in a template doc. Veeam has just made it MUCH easier to do a lot of damage by putting duplicate EHR, DB servers, or DCs on the network at the same time.

[soncscy]

OOC, why not just script it? Take a VM input, hard-code the NICsEnabled to $false, then there's no muss no fuss. I know you manually intervene, but a script for starting the process doesn't preclude that and instead just ensures that the option takes your preference.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Kind of seems like a simple way to remove a lot of clicking for your team and to have that assurance you're looking for.