Creating virtual lab for Exchange 2010

[Gostev]

Yes, we definitely want to investigate every occurence when the workaround does not work, so thank you for creating support case and providing all logs. Thank you for your kind words

[tekna]

We have had this problem with the NICs being replaced when cloning or restoring 2008r2 VMs with vmxnet3 adapters.
After applying this hotfix from Microsoft, our troubles are noe more:
http://support.microsoft.com/kb/2344941

Here is vmware's take on the issue; either convert to E1000 adapters or apply the mentioned hotfix:
http://kb.vmware.com/selfservice/micros ... Id=1020078

[Gostev]

We have had this problem with the NICs being replaced when cloning or restoring 2008r2 VMs with vmxnet3 adapters.
After applying this hotfix from Microsoft, our troubles are noe more:
http://support.microsoft.com/kb/2344941

I heard this did not make it into 2008 R2 SP1 though... and there is no similar hotfix for 2008 R2 SP1 (or so I heard).

[cmoody]

I am currently experiencing this problem and working with Veeam support. We have installed 2008 R2 SP1, which supposedly includes the hotfix from Microsoft (KB2344941) (see http://www.microsoft.com/downloads/info ... R2+SP1.xls). I decided to compare the versions of the files in the hotfix against the versions of the files from SP1. What I found was that pci.sys, termdd.sys and volmgr.sys were version #: 6.17601.17514, all the other files were the version # identified in the KB. Seeing that the version # is newer than the KB version # 6.1.7600.20776, you would think that the problem should be resolved.

I'm hoping that maybe someone from the forum could help:

1. Someone mentioned a possible registry setting that could resolve the problem. Is there a registry fix?
2. Someone mentioned setting the MAC address manually. Is this a recommended work around?
3. What was the resolution for the individual with ticket #544913?

We are currently using Veeam 5.0.2.230 (64bit).

Thanks

[Vitaliy S.]

1. Someone mentioned a possible registry setting that could resolve the problem. Is there a registry fix?

Could you please clarify what registry key are you referring to?

2. Someone mentioned setting the MAC address manually. Is this a recommended work around?

If you still experience the issue mentioned in this topic while being on Veeam B&R 5.0.2 with all hotfixes applied from Microsoft, then you might consider setting a MAC address manually.

3. What was the resolution for the individual with ticket #544913?

As far as I see it from our support ticket tracking system, the resolution for this case was to use e1000 adapter type.

[cmoody]

Someone mentioned in an earlier post there might be a possible registry key. I'm going to bug VMware now since it only happens with the VMXNET3 adapter and Microsoft says they have provided the fix in SP1.

Thanks

[Alexey D.]

I might be wrong, but I heard that despite Microsoft promised to include this fix in SP1, it wasn't actually there. And folks had to re-apply the patch manually after installing SP1.

[cmoody]

I did try to install the patch after SP1, but receive "The update is not applicable to your computer". I was also informed that others, who applied the patch prior to SP1 are now experiencing the problem again after applying SP1. Hopefully, we will see a new patch soon, post-SP1.

[cmoody]

Microsoft has a patch post SP1. Haven't tried it yet but am hopeful.

For Windows 2008 R2 or Windows 7 versions post Service Pack 1, install the hotfix described in the Microsoft Knowledge Base article 2550978 (http://support.microsoft.com/kb/2550978) before deploying the template.

[Frosty]

Thanks for the info in this thread. We've just finished setting up a virtual lab and had been having this problem with the NICs losing their IP addresses. I've tried the post-SP1 hotfix mentioned above and can confirm, based on a limited test with just 1 VM, that it does seem to have fixed the problem for us. I did have one brief heart-stopping moment after the hotfix install reboot ... the server rebooted and had lost its IP address settings, and because it was an RODC in a network segment which had no DCs and no DHCP servers, I also couldn't login to the server. Fortunately connecting the VM to our LAN vSwitch and giving it a further reboot did the trick. I was then able to login, reset to a static IP, then connect the vNIC back to the original vSwitch. In my case all VMs which I have deployed from a Server 2008 R2 VM Template with VMXNET3 vNICs are affected. Luckily there are < 20 of them ... job for a rainy day.

[aweiss]

Hi Guys
I'm currently setting up an Exchange 2K10 lab with AD 2008R2 and CAS + MBX on different servers. (3 VM in my lab) As we all know, AD is quite long to start as it needs to make an initial replication with another controler. Instead of starting 2 controler in the lab, is there a way to insert at first boot the key "Repl Perform Initial Synchronizations"=0 to allow DC to start DNS without waiting for initial sync ? It is a Veeam KB that tells us to insert the key but Microsoft doesn't recommand it on production server and on a normal run. Scripts will only run after the VM had rebooted so inserting the key with script will take longer than just wait i think.
Gostev perhaps : is there any enhancements in V6 on this point (2008R2 quick start) ?
Perhaps there is another Topic on this on the forum.
Thkls !
Rgds
Alex

[Gostev]

Hi Alexandre, v6 does this automatically for you before the VM is booted up in the virtual lab. This is covered in the What's New as one of the enhancements. Thanks!

[aweiss]

Thks much Gostev. I'm gonna have a look.
Do i need to check the Domain Controler role in application group for my AD to have this key inserted ? or it is not necessary when doing item recovery to check this role.
Thks too!
Rgds
Alex

[Gostev]

Yes, absolutely you must do that in order for DC-related tweaks to be applied by the SureBackup job.

[mpozar]

Hi
We have upgraded to Veeam B&R 6 and we now seem to have the issue in our SureBackup Labs where the IP address in our Windows 2008 R2 SP1 DC servers are being reset, the Virtual Machines are defined with VMXNET 3 adapters and we are on vSphere 5.

I thought the patch/workaround in Veeam B&R 6 was still in place so I do not understand why this is happening.

Is the patch from Microsoft also required in conduction with the Veeam workaround?

Have FUN!

Michael

[Vitaliy S.]

Michael, If you don't want to have your IP address reset while using VMXNET 3 adapters, please apply Microsoft's patch to fix this issue. Thanks!

[Gostev]

Hi Michael, workaround should still be in-place - please provide logs to the support and we will investigate. Although the patch is more reliable resolution for sure. Thanks!

[mpozar]

Hi Gents,
Thanks for that. I've applied the Patch from Microsoft for Windows 2008 R2 SP1 and that has resolved my problem. I don't know why Veeam B&R 6 is not doing it's thing in regards to this issue.
I'll raise a support case as soon as I get the chance..

Have FUN!

Michael

[Gostev]

Hi Michael, yes please open a support case since I have confirmed that our built-in VMXNET3 workaround should still work after upgrade. Thanks!

[markholmes]

[merged]

Hi,

I'm currently testing replication in VEEAM (6.0.0.154).

The replication side is working fine, but when I failover I find the replica VM is missing it's IP information.

So far I have tested a Windows 2k8R2 and a Linux (Centos 5) VM, both with exactly the same result - the networking has been reset to the default (DHCP) rather than the static IP it should have.

I'm guessing I'm missing a simple setting somewhere...? Note:I'm not using the re-ip or network remapping features here, I want the replica to have exactly the same IP and use the same virtual network as the source.

I also have a support ticket open for this, but in case anyone has a quick answer...?

Regards,

Mark Holmes

[Vitaliy S.]

Mark, please review this topic for the resolution as it is also applies to your case.

[markholmes]

Hi Vitaliy,

This only applies to WIn 2008 R2 though, right? I'm having this issue with a Linux (CentOS) box as well..

Thanks,

Mark

[tsightler]

Most Linux distro's will likely also have a problem since the majority of them now use udev rules to bind the ethX interfaces to specific MAC addresses, or at least add the MAC to the interface configuration. Unless you are using static MAC addresses, the MAC addresses on the replica will be different from the source. There are other posts on the forum that describe workarounds to this issue for various distro's.

[markholmes]

I'm using static MAC addresses

[markholmes]

Scratch that - I'm not using static MAC, I can see that vCenter recognises the duplicate MAC and changes it.

How to work around this? Can I make a MAC static?

[dellock6]

Yes, you can edit mac address of the network adapter and set a fixed MAC address. It's in the properties of the virtual hardware.

Luca.

[markholmes]

Never noticed that before - I'll put in a static one now. Thanks Luca.

[stefanpeters]

I am currently creating this setup for a client also. And I noticed the IP address going wrong in the lab. I have manually changed the IP addresses to the correct ones and that works.

What is the best practive, fix the MAC address and / or use e1000 instead of vmxnet3?

Thanks
Stefan

[Cokovic]

Fixing the MAC address is not necessary for Windows based systems. Either use e1000, or install a patch provided by Microsoft if you are using Windows Server 2008 R2 (SP1) and VMXNET3. You will find the links in this thread.

[mbeckey]

[merged]

I am testing Veeam 6.1 to replicate VM guests to our DR site. Testing all other versions of 2003 and 2008 server the MAC address stays the same and the replica will power on with the production VM IP address as long as the prod VM is shutdown. With 2008 R2 SP1 the MAC address on the replica is being changed by VMware and a DHCP IP address is being grabbed. The test environment I am using is using VM hosts ESX 4.1 update 1 and just using the local disk on the hosts as the data stores. I have seen other posts on this topic but there doesn't seem to be any concrete resolutions.

One work around I did find is to manually change the mac address on the replica to what match the prod MAC address. I would not like to do this step if at all necessary.