Creating virtual lab for Exchange 2010

[joost1981]

Hi Guys,

I have installed version 5 yesterday. Again it looks great. I think version 4 was already a big breakthrough but this one is even bigger!
However I am having some difficulties understanding the "virtual labs".

We have two location with both their dedicated EMC SAN. Both location have a physical server (Win2003 Enterpise) with Veeam Backup installed.
We use both location as active-active, so we backup data on both sides. This means that the Domain Controller with the FSMO roles is at location A and that the Exchange 2010 server is on location B. This means that I can not use the Domain Controller with the FSMO roles because it is backupped at location A and the backup files are not accesible to the backup server at location B. Is there a workaround for this (something else than creating a mapped drive to the location B, and import the backup)?

So now I am trying to use the DC that is at location B (same location as the Exchange 2010 Server).

I have created an Application Group:
1 DomainController (has the DNS, Domain Controller and GC roles, not DHCP). Also this is not the DC that has the FSMO roles.
1 Exchange 2010 Server.

Both server are Windows 2008 R2 (English), and have fixed ip-addresses.The Domain Controller has ip-address 10.1.10.25/24, gateway is 10.1.10.1. The Exchange Server has ip-adress 10.1.10.150/24, same gateway.

I have created a Virtual Lab with a proxy appliance (Basic). Her are the settings:

Lab name: Exchange Recovery
ESX name: esxaureool07.roermond.lokaal
Datastore: aur-fc-r10
Appliance:
Name: Exchange_Recovery
Pool name: Exchange Recovery
Folder name: Exchange Recovery
IP: <Obtain automatically>
DNS: <Obtain automatically>
Network configuration type: Basic
Network options:
Isolated network: Exchange Recovery VLAN10
Masquerade IP: 10.255.0.0
Appliance IP: 10.1.1.1
DHCP: enabled
Network mapping:
VLAN10 --> Exchange Recovery VLAN10


I have created a job with the Virtual Lab and Application group included, No linked backup jobs.

When I start the job, the VMs are created in VirtualCenter and the first VM (in this case the DC) is powered on.
So far, so good. When I look at the console the DC is starting fine, but because the Network Adapter is new (Exchange Recovery VLAN10), it looks like Windows 2008 R2 is creating a new adapter and the ip settings are reset to DHCP. The DC gets an ip-adres 10.1.0.1 As you can imagine this causes problems. The heartbeat, ping and application tests work fine. The next server that starts is the Exchange 2010 Server, this one has exactly the same problem as the DC, it gets the ip-address 10.1.0.2, during first startup. Because of this problem the Exchange Information Store will not start.

Is this standard behaviour? any help will be appriciated.

Thank you in advance.

Joost Poulissen,
Gemeente Roermond
Netherlands

[Gostev]

Hi Joost, yes interesting problem, looks to be specific to 2008 R2... I do not see same behavior on all other Windows OS. We will investigate.

[joost1981]

Hi Gostev,

You are right. I have tested it with a Win2003 Enterprise Domain Controller. This works fine. Ip-adres is the same.
By the way, you were also right about the Virtual Lab, that was not configured correctly. I did not have the gateway 10.1.10.1 on the Virtual Router set as gateway. By default this was set tot 10.1.1.1 instead of 10.1.10.1.

Lets hope you find a solutions for the "Windows 2008 R2 detects new network card" problem.

Thank you for your assistance.

Joost Poulissen
Gemeente Roermond
The Netherlands

[Gostev]

Joost, can you please look up VNIC type on VMs in question, and let me know?

[NightBird]

Same problem here, VMXNET 3 virtual network adapter type.

[Gostev]

I will check which adapter our QC is using because they are not seeing this. I asked because accoring to one post on VMware Communities, network adapter reset is Windows 2008 R2 specific issue that is supposedly fixed by changing network adapter to VMXNET 3. Strangely enough, this is what you say you are using...

[NightBird]

I restore a full Windows 2008R2 VM in my test lab ESX, same problem, a new network adapter appear, so we loose initial network configuration.
Really annoying, but the problem was the same with Veeam 4.1, it's VMware or Windows 2008R2 related.

I will try later with E1000 vnic adapter instead of vmxnet3

[joergr]

Hi,

i tried to reproduce your error but without luck (it worked for me!) i use standard nic (e1000). could it be you are backing up an exchange 2010 machine which is a member of a dag cluster? In that case i´d judge the cluster network for this behaviour.

best regards,
Joerg

[NightBird]

It's a test Windows 2008R2 standalone server, no Exchange 2010 on it.

[joergr]

OK, I see. Hmmmmm....
Have you tried with e1000 in the meantime?

Best regards,
Joerg

[NightBird]

I will try with e1000

[joost1981]

Hi Guys,

Exchange server is not member of a DAG cluster.
I am using also VMXNET3 adapters in all of our VMs that are Windows 2008 R2.

I have found a workaround for the time being. Because there is a timeout of 2100 seconds (35 minutes) I get the time to manually set the ip-address back to what it was and restart the server. This way I at least can test functionality manually. Of course this is not ideally, but I am sure there will be a solution for this problem.

Regards,
Joost

[NightBird]

I tried with a Windows 2008R2 VM and 2 NIC, one e1000 and vmxnet3 => backup of the VM, delete of the VM from the inventory, restoring the VM => all is OK

But if you restore the VM in a test environnement (don't delete the source/production one) on the same datacenter/esx server (like SureBackup), changing NIC port group (test lan) powering on the VM, the ip address of the vmxnet3 adapter is lost (new network adapter) (e1000 is ok), I think it's related to mac address change (duplicate address detection of vsphere) and windows bring a new adapter for vmxnet3, not for e1000 strange behaviour.

annoying for SureBackup, as SureBackup launch the VM in a virtual lab with specific portgroup... => lose of ip address of vmxnet3 vnic !!!

Use of Surebackup with Windows 2008R2 paravirtual nic driver is simply not possible, may be with all Windows Guest with vmxnet3 paravirtual nic driver

[joost1981]

@NightBird

I think you are right. It has to do with the MAC-address that changes. Windows 2008 R2 just creates a new adapter. Maybe there is a setting in Windows 2008 R2 to prevent this from happening? Or maybe it has to do with the VMXNET3 driver? The last option seems more likely because the E1000 adapter is not recreating a new NIC.

[Gostev]

We will research for possible workaround. If there is a registry key in Windows, then it will be easy to implement in SureBackup engine.

[NightBird]

I think you use e1000 in your lab for testing
Do you check the adapter used in your QC ?

[Gostev]

This is possible. I will ask to retest based on all the findings posted above.

[Gostev]

We have done some further testing and it looks like this issue is specific to using VMXNET 3 adaptor type. Further research on VMware Communities revealed some other issues with it, the adaptor type is fairly new and looks to be pretty buggy at the moment.

Can everyone who can see this issue with Windows 2008 R2 confirm that you are using VMXNET 3 adaptor type?

[NightBird]

Fairly new and pretty buggy ?

VMXNET 3 is available since vSphere => May 2009, so about 1year and 6months ago.

I will try with VMXNET 2 adaptor type one of this days.

[joergr]

That is correct but the default reference of vmware when creating a vm is still the e1000, even with w2008r2 machines. Me personally, i use the vmxnet3 only for performance testing in my lab.

[joost1981]

I am also using the VMXNET3 adapter for performance (10Gb). We are excepting the 10Gb Ethernet (phsyical interfaces) somewhere early next year.

[Gostev]

Fairly new and pretty buggy?

Sorry, I missed the word in my previous post... I meant to say "further research on VMware Communities". Plenty of complaints and issue reports.

[Gostev]

VMware had acknowledged the issue with VMXNET3 adaptors and Windows 2008 R2 or Windows 7:
http://kb.vmware.com/selfservice/micros ... Id=1020078

However, by this time we have already implemented a workaround (part of 5.0.1 release), so SureBackup should no longer be affected by this issue with VMXNET3 adaptors.

Thanks!

[joost1981]

Hi Gostev,

Any idea when 5.0.1 is available?

Regards,
Joost

[Gostev]

Hi Joost, we are aiming at end of this month, so very soon. Thanks!

[Davd]

VMware had acknowledged the issue with VMXNET3 adaptors and Windows 2008 R2 or Windows 7:
http://kb.vmware.com/selfservice/micros ... Id=1020078

However, by this time we have already implemented a workaround (part of 5.0.1 release), so SureBackup should no longer be affected by this issue with VMXNET3 adaptors.

Thanks!

I have installed 5.0.1 and ran a Surebackup of several Windows 2008 R2 servers with VMXNET3 and I still have the problem that the network adapter in Surebackup job is added as vmxnet3 Ethernet Adapter #2 and it uses DHCP instead of static IP that we have on the actual/live machines. Do I need to do anything in order do enable the workaround that you mentioned in your previous post?

[Vitaliy S.]

David, the workaround is enabled by default, so no manual configuration is required. If you're still experiencing these issues, could you please contact our support team and tell me your ticket number. By the way, does a workaround with assigning a static MAC address for those VMs help you?

[Davd]

Vitaliy S.:

We haven't tried to assign static MAC addresses since it would be solved in 5.0.1. I have sent print screens and surebackup logfile to support and ticket number is #544913

[Gostev]

This is really strange because I actually received a confirmation from Mindflux a few hours after version 5.0.1 has been made available. Basically this was the first thing he tested, and he confirmed that the issue is resolved for him.

I guess there can be some exceptions or unusual configuration when even our workaround does not help. If this is the case, static MAC address (or changing network adaptor from VMXNET3) will be the only solution until VMware resolves this issue.

[Davd]

This is really strange because I actually received a confirmation from Mindflux a few hours after version 5.0.1 has been made available. Basically this was the first thing he tested, and he confirmed that the issue is resolved for him.

I guess there can be some exceptions or unusual configuration when even our workaround does not help. If this is the case, static MAC address (or changing network adaptor from VMXNET3) will be the only solution until VMware resolves this issue.

I'll wait for support's reply to see if they can see anything from the logs and if there is no workaround available form their side I might go with one of the two solutions that you provided Gostev.

By the way, I must say that I think you Veeam-guys are doing a terrific job on this forum. Really quick responses and a lot of helpful info. Thanks