B&R on a Test Enviro mirror of production

[Zew]

I wasn't sure what to title this cause it's a bit weird!

I have a Production cluster of VM's. To test out new stuff I have created a replica of our production but put them in a separate vSwitch called Test with the same IP's and everything in our production, including other test vSwitches when required.

I had opened up a Case revolving around another issue KB1299 (Veeam can't find the VM when restoring files). Turns out all the suggested casues and fixes didn't work. I'm still waiting to hear if there is way to manually determine the FEDID of a VM and change a backup set to know that. (How it changed is beyond me, I didn't vMotion, shutdown, rename or do anything to that specific VM.) Anyway Back to what this post is about.

I was testing Guest processing on this VM, and noticed some strange things:

1) when specifying a Domain Admin account (given local admin rights via the group being added to the local Administrators group) When specifying the account in Veeam as Domain\DomainAdminUserAccount
- RPC would Pass
- VIX would fail
2) when specifying a Domain Admin account in Veeam as (DomainAdminUserAccount)
- RPC Fails
- VIX fails
3) When Specifying a local Administrator account in Veeam as (Administrator)
- RPC Pass
- VIX Pass

Now here's the funny thing, I ran the same test on a VM that's in this test enviro that was new (New Hostname, New IP that doesn't exist in our production) and came up with the follow results:

1) when specifying a Domain Admin account (given local admin rights via the group being added to the local Administrators group) When specifying the account in Veeam as Domain\DomainAdminUserAccount
- RPC would fail
- VIX would fail
2) when specifying a Domain Admin account in Veeam as (DomainAdminUserAccount)
- RPC Fails
- VIX fails
3) When Specifying a local Administrator account in Veeam as (Administrator)
- RPC fail
- VIX Pass

As you can see RPC fails, this is making me believe that Veeam is querying the VM for it's IP, and since there is a production version of that IP that Veeam can connect to it says Pass (But it's connecting to the wrong VM, the production VM and not the Test VM)

I'm not exactly sure how one could get around this, but a recovery in this case might attempt to restore a file via RPC for it to be restored to the wrong VM ( I'm going to test this out right now and report my findings)

This is a bit of a two part question, my next question is, how can I get VIX to work with a domain based admin account, or am I going to have to specify and use the local admin account for every VIX based restore?

[Zew]

I just tested this, and Yeeap, it restored a file in my production VM, instead of my Test VM...

At this point I'm assuming one has to disable RPC on that particular Backup and restore job to prevent this?

[Zew]

Since no-one has mentioned anything here, and considering that if anyone else is testing Veeam with a test environment that similar/identical to their production this RPC issue should really be addressed by someone.

I have a case open on a another issue that became apparent, and that's when you do a full restore on a VM via Veeam, the Ref-ID of the VM changes and the backup file you initially used to restore that VM becomes useless to that VM, its bazar!
which means after your do a full recovery of the VM direct Granule Recovery to that VM with the backup set you just used to recover it, won't work, you'll get a VM not found error, when attempting to do a file restore.

The Tech on my case was kind enough to shed some light on this issue, at least to some degree, as for the VIX failures it due to the following:

"
As to your forum post, VIX fundamentally does not work with generic admin accounts if UAC is enabled. This involves a VMware limitation we have not been able to work around. You can either use an account with SID ending in -500, disable UAC, or not use VIX.
It is a known limitation of guest processing that Veeam cannot distinguish between two VMs with the same IP address. At present the only workaround is to ensure VIX works and then either block network access to the relevant VMs, or to globally set Veeam to try VIX first and then RPC.
http://www.veeam.com/kb1788 describes troubleshooting for VIX.
http://www.veeam.com/kb1230 lists the registry change to try VIX first instead of RPC (The test tries both regardless, so you'll still get strange results when running the test).
"

So this covers everything in this forum post, From the failing VIX testing, to the RPC communication to the wrong Machine, I have to configure to use VIX first, and simply block any communication form my Veeam server to the production side VM.

I really want to push for granule VIX over RPC and vice versa as a per job option when creating a job, versus it having to be a global setting. How was this missed?