Skip to main content

Hyper-V problem with Network Load Balancing (NLB) in virtual machines running Windows 2008

I recently had a problem with virtualized Exchange 2007 SP1 with CAS role installed and NLB enabled. Exchange is installed on top of Windows Server 2008 and two network cards were added to configuration. One network card for Outlook Anywhere on port 443 in NLB and the other card for other traffic and server management.

After some time one of the virtualized Exchange 2007 servers started to reboot unexpectedly without any useful information in event logs.

Since I had many problems with NLB in my career I thought that maybe Hyper-V and NLB are not working well together.

During the search for error I ran into Rob Whitehouse’s blog post in which he posted the link to Microsoft’s knowledge base article with exactly the same error/problem I got.

Microsoft provided a hotfix for this error that was described with following symptoms:

  • You are running a Windows Server 2008 virtual machine in the Hyper-V environment on a Windows Server 2008 host computer.
  • You try to create a new Network Load Balancing (NLB) cluster on this virtual machine. Or, you try to add this virtual machine to an existing NLB cluster.
In this scenario, the NLB host on the virtual machine does not converge as expected. Additionally, if a large volume of traffic occurs in the NLB cluster, the guest system on the virtual machine may restart unexpectedly, and you may receive the following Stop error message:

 

STOP: 0x000000E1 (parameter1, parameter2, parameter3, parameter4)

In my case hosts were converged properly (after the reboot) just that one of the servers was constantly unexpectedly rebooting.

Reference:

Windows Server 2008 Hyper-V virtual machines generate a Stop error when NLB is configured or when the NLB cluster does not converge as expected

 

Comments

Post a Comment

Popular posts from this blog

Netscaler vs Exchange 2019 "time out during ssl handshake stage

If you are using Citrix Netscaler as load balancer in front of Exchange 2019 server you must know this: Microsoft Exchange 2019 is secured by default and allows only TLS 1.2. Therefore default schannel settings are as follows (using IISCrypto tool from Nartac Software): While Citrix Netscaler offers following Cipher Suites: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Now, you will fi

Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}]

 If you got this error checking the mail flow for a distribution group, it means the distribution group is closed and only internal senders can send e-mail to this group. When outside user sends e-mail to this group you get  Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}] Set Delivery for this group to internal and external users and your problem will be solved. 

Ports that need to be open on Firewall for Edge Transport servers

Ports that need to be open on firewall for Edge Server subscription with Hub Server to function properly: For Inbound traffic: SMTP - TCP port 25 (from Internet) SMTP - TCP port 25 (from Edge server to Hub server on internal network) For Outbound traffic: SMTP - TCP/UDP port 25 (from Edge to Internet) SMTP - TCP/UDP port 25 (from Hub to Edge server) LDAP for EdgeSync - TCP port 50389 (from Hub to Edge server) Secure LDAP for EdgeSync - TCP port 50636 (from Hub to Edge server) Since Edge server needs to communicate with Hub server it is important that it can resolve Hub transport servers by FQDN and Hub transport servers must be able to resolve Edge servers by its FQDNs. To accomplish this you need to either open 53 (DNS) port and configure internal network adapter to use internal DNS but as a security precaution I would suggest to enter DNS records for Edge servers on local DNS manually and to fill hosts file on Edge servers with FQDNs for Hub transport servers.