SureBackup - DC is OK but Exchange Server gives IP error

[plarge@pfh.ie]

I'm using SureBackup to check Exchange Backups. We have a private internal IP address range so I have had to configure the Virtual Lab for Advanced (Manual Configuration). I think this is configured OK.

When I run the SureBackup job the Domain Controller starts up and passes all tests and is given an IP address on the network range that I selected in the Virtual Lab.

The Exchange Server then starts but gives the error "Unable to find destination network for address ....." When I check via Virtual Centre, the VMtools are loaded OK, but the server has been given its original IP address rather than an address on the Virtual Lab network and is shut down by the SureBackup job.

[Gostev]

What exactly gives this error? It is not clear where you see that.

The server should keep the original address of course, so this is normal. Fenced-off environment uses different VLAN, but all IP settings on the servers remain absolutely the same as in production.

[larry]

I had this on two VM's. Both had issue http://support.microsoft.com/kb/269155

To see if your issue is this, in VC where the VM IP addresses are listed click see all, I had a IP addreese listed that was wrong. The wrong IP address didn't show up in network properties of the server, the above doc has the fix and it worked for me.

[plarge@pfh.ie]

The Sessions tab shows the error. I'm new to Virtual Labs, but the DC starts and is assigned an IP address from the Masquerade IP range and is pingable from the live IP network. All the script tests pass and then the Exchange Server powers on. It gets to the login screen and sits there for a while, the VMware Tools shows as running with an IP address from the live network and after a minute or two the virtual lab environment shuts down. The Sessions log shows the error "Unable to find destination IP address for network 190.10.1.23".

The live IP range is 190.10.0.0 and the masquerade IP range is 190.210.0.0.

When the dc starts, its original IP was 190.10.10.1 but it now gets an IP address of 190.210.0.1 (from the masquerade network). I check in the vm and it has updated DNS and everything looks good.

Then the second server starts (I have now tried this for an Exchange and SQL server), but this comes up with its original IP address (190.10.0.x). I managed to logon to the SQL box before the virtual lab was brought down and it can ping itself, but cannot ping the dc ir its default gateway.

I must be missing something regarding the Virtual Lab environment!

I thought Larry had something as the Exchange server did have a hidden network card (leftover from P2V process). However, I have fixed that and rerun the backup with same issue. The SQL server did not have the hidden network card, but also exhibits the same behaviour

[larry]

I had one that after deleteing the hidden nic I needed to change the name of Loacl Area Connection 3 back to Local Area Connect 2, that fixed that one server.

[rbrambley]

This sounds like you are mixing Instant VM Recovery with Virtual Labs?

IVMR is "out in the wild" and therefore on your production vSwitch and portgroups. In this mode any VM configured for DHCP will get a production ip, and possibly a new one. VMs with static IPs will keep their original config - it is a backup after all.

VMs in Virtual Labs come up behind the Veeam proxy and are therefore fenced in. In the vLab config you specify a mapping of each production port group to a vLab port group and then you configure an internal interface (NIC) of the Veeam proxy. This interface should be the ip address of the production gateway. I know this can be confusing and scary, but reality is that it is in the fenced environment, on an isolated, new vSwicth that has no physical ESX NICs, so nothing really gets to the prod networks.

To me, it sounds like your Exchange server's problem is that it can't find it's gateway (and therefore the DC and GC) in the vLab. Or, you've configured DHCP inside the vLab too and that is where the new ip address is coming from because of your hidden network adapter mix up?

More importantly, the way you start the VMs in the virtual labs is via a Surebackup Job. To do that you create Application groups with your VMs, and then make a job that combines the vLab with the App groups. Did you add your DC with your Exchange VM in your Exchange application group? The list of VMs specifies the order they boot in the vLab too. You also specify the time to wait for VMs to boot in the App group config. If the VMs can't talk to each other in the configured time to waits then the vLab shuts down. Annoying IMO, but it will hopefully change soon.

FYI - the masquerade ip address is auto assigned and available only from the desktop of the Veeam BaR server. You can map other available prod ip addresses to the vLab VMs via the vLab configuration, however. These mapped prod ips end up being tied to the external ip of the Veeam vLab Proxy VM.

[plarge@pfh.ie]

Thanks all - the problem was my misunderstanding of the masquerade network. I was not setting the proxy server to use the same IP address as the live network but was instead assigning the masquerade address here. I have now set the proxy to the same IP address as the prodcution router and things are much better.

The DC comes up with its production IP address and passes all tests. The Exchange server then starts up OK, passes vmtools test but is failing ping tests. It is Windows 2008 R1 with the firewall on, so I need to try to sort this out. Also fails the Mail script test - If I have mailbox role on one server and cas/hub transport server on another server, do I need to bring both up? Where do I run the mail script against - the cas / hub transport?

[rbrambley]

If I have mailbox role on one server and cas/hub transport server on another server, do I need to bring both up? Where do I run the mail script against - the cas / hub transport?

When you click a role it invokes a port checker tool (mail = 25), so use it on VM(s) that you would expect a response on port 25 from. Uncheck it on those VMs that would not repsond on that port.

If your testing the restore of your entire Exchange application and environment, bring up everthing that lets Exchange operate normally in the vlab. You might need to write your own script to fully automate testing (log on to a mailbox, check a service, etc) or make your own roles to test other ports, and then hook that up with the application group settings for your own thorough, testing.