This sounds like a networking issue. There is nothing different from an Exchange configuration perspective when you move VMs between hosts. If this works in one scenario but not another, that would indicate that there isn’t a configuration issue there. When your other servers are on the same host as your HTS/CAS NLB cluster members, can you telnet to the NLB VIP on port 80? If not, that is consistent and would appear to rule out an NLB configuration issue.

Have you reviewed VMware’s documentation on implementing NLB on VMware: http://www.vmware.com/resources/techresources/1072 and http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006580?

Did you modify your port rules so as to allow load balancing of TCP port 25? If you don’t do this, the NLB VIP will not respond on and load balance traffic for that port. Once you configure that, you should be able to communicate on that port.

Switch flooding is by design when you use Unicast for NLB…it’s how it works. If you’re sharing the same VLAN for NLB-related and other production traffic, you’re going to see this problem (see http://technet.microsoft.com/en-us/library/ff849728.aspx for more information). You can consider isolating this traffic onto its own VLAN or potentially change to Multicast for NLB.

I am having a really weird issue. Some of our applications are required to relay off of our exchange 2010 server, but on some server2008 boxes it does not seem to be working with the cas array. I tested telnet to port 25 on the cas array ip/name and it does not work, but works fine when i telnet on the same port into the individual cas servers. Telnetting on port 25 to the cas array does work on other servers that are set up exactly the same and to relay and they are all on the same subnet. Any idea as to what coudl possibly be the issue?

Glad to hear this post was helpful.

http://technet.microsoft.com/en-us/library/cc782694(WS.10).aspx provides a very good comparison of Unicast vs. Multicast. Unicast is Microsoft’s recommendation, mostly due to how it works easily in all routing situations. That being said, Unicast can suffer from switch flooding and can require additional effort to make it work in some specific networking configurations.

When switching to Multicast, you need to make sure that all upstream networking components are configured to properly support Multicast. If there are problems there, NLB will have issues. You shouldn’t need a second NIC to go with Multicast since Multicast doesn’t assign the same Unicast MAC address to all NLB nodes.

I hope this helps.

We recently moved our CAS/HT server to a new Hyper-V environment on same VLAN and did not change any IP’s. Found problem is with Cisco hardware (UCS/6120) and Unicast. We are told we need to change to Multicast and ARP table created on Cisco equipment (Cisco vendor will be taking care of those needs). I imagine that I need to tear down existing WNLB and reconfigure with Multicast.

Is there going to be any issues that I need to watch out for when switching over to Multicast? Do I still have two NIC’s as I needed with Unicast or do I remove one when doing Multicast? Curious why Unicast is recommended when it apparently floods the switch ports?