NLB can come in handy in less obvious ways as well. For example, with SharePoint 2010, you might have Web front-end servers that you want to be a little more redundant, although this may prove difficult if you're using Cisco switches. With Exchange 2010, you can use NLB to establish a CAS Array for your Client Access Server role to provide high availability for CAS services. However, note that you cannot use NLB if your CAS servers are co-lacated with Mailbox servers that are members of an Exchange DAG.
You can also use NLB for additional Hub Transport balancing support (requires SP1 or later), which is necessary only if there's an SMTP application in your environment that requires it. If you're using edge transport servers within an on-premises environment, you can configure a cloned edge and use NLB. Learn more about NLB for hub transport servers through TechNet.
Note: While NLB is supported for Exchange server load balancing with the Hub/Edge Transport and CAS server roles, it is not necessarily recommended. Generally Microsoft recommends a hardware load balancer because of limitations with NLB and Exchange, for example there may be performance issues, NLB doesn't detect service outages and port flooding is, at times, an issue. To understand load balancing recommendations a bit better you can read up through TechNet. Some would say NLB isn't really appropriate for most, if not all Exchange implementations -- so it is essential that I mention that fact. However, it is being utilized and is, in some cases, supported and so it warrants mentioning that as well.
As opposed to NLB, Microsoft recommends using a hardware load balancer, and it is good to be aware of the circumstances: for example, as mentioned above, when the CAS server is part of a DAG (Database Availability Group) you cannot use NLB. Servers that are already part of a Windows failover cluster (as in the case of a DAG member) cannot also be part of an NLB cluster.
There are other reasons, in an Exchange environment or otherwise, where a hardware load balancer is recommended because of the size and configuration of the network and the other solutions you have in play. You'll have to do your due diligence and confirm that NLB is the right choice for your environment.
The main thrust of this post is to help folks remember this forgotten solution that has many uses, especially if you have a Web farm or terminal services that require both load balancing and high availability through server redundancy. If NLB is a good fit for you and your environment, go for it!
This article, "Tap the power of Windows network load balancing," was originally published at InfoWorld.com. Read more of J. Peter Bruzzese's Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.