How to Configure Network Load Balancing (NLB) on Windows Server 2022

Introduction to Network Load Balancing on Windows Server 2022

Network Load Balancing (NLB) is a built-in Windows Server feature that distributes incoming TCP/IP traffic across multiple servers in a cluster. Unlike Windows Server Failover Clustering (WSFC), which provides high availability by moving a service from a failed node to a healthy one, NLB distributes load across all active nodes simultaneously — all nodes are online and processing requests at the same time. NLB operates at Layer 4 (transport layer) of the OSI model, making routing decisions based on IP addresses and TCP/UDP port numbers rather than application-level content.

NLB is well-suited for stateless applications such as web servers running IIS, Remote Desktop Session Hosts (RDSH), and HTTPS-based services where session state is stored externally (in a database or distributed cache). It is not appropriate for services requiring shared storage or stateful failover, which is where WSFC applies. This guide covers the complete installation, configuration, and management of NLB on Windows Server 2022.

NLB vs Failover Clustering: Key Differences

Before deploying NLB, understand the architectural differences between NLB and WSFC. NLB is an active-active load balancer: all nodes receive traffic simultaneously. WSFC is an active-passive HA mechanism: only one node owns a resource at a time, and failover means moving ownership to another node. NLB has no concept of shared storage — each node runs its own copy of the application with its own local storage. WSFC requires shared storage accessible from any node.

NLB operates at Layer 4 and has no awareness of HTTP sessions, cookies, or application state. It cannot inspect HTTP headers, perform SSL offloading natively, or do content-based routing. These capabilities require an application delivery controller (ADC) or a reverse proxy like Application Request Routing (ARR) in IIS, or a dedicated load balancer appliance. NLB also has a known limitation: in Unicast mode, all servers in the NLB cluster use the same MAC address for the cluster IP, which prevents NLB nodes from communicating directly with each other using the cluster IP. A dedicated management network is recommended for node-to-node communication.

Installing the Network Load Balancing Feature

Install the NLB feature on all servers that will participate in the NLB cluster. Run this on each node:

Install-WindowsFeature -Name NLB -IncludeManagementTools

This installs both the NLB service and the NLB Manager GUI tool (nlbmgr.exe). Verify the installation:

Get-WindowsFeature NLB | Select-Object Name, InstallState, DisplayName

NLB management can be done from any machine that has the management tools installed — it does not need to run from a cluster node. If you want to manage the NLB cluster from a remote management workstation, install the management tools there as well:

Install-WindowsFeature -Name RSAT-NLB

Creating a New NLB Cluster with PowerShell

Use the NetworkLoadBalancingClusters PowerShell module to create and manage NLB clusters. First, create the cluster on the initial node. You will specify the cluster’s virtual IP address, subnet mask, cluster name, and the operation mode (Unicast or Multicast):

Import-Module NetworkLoadBalancingClusters

New-NlbCluster -HostName "WEB01" `
  -ClusterName "WebCluster" `
  -ClusterPrimaryIP 192.168.1.100 `
  -SubnetMask 255.255.255.0 `
  -InterfaceName "Ethernet" `
  -OperationMode Multicast

The -ClusterPrimaryIP is the virtual IP address that clients will use to connect to the NLB cluster — this IP is shared across all nodes. The -OperationMode should be set to Multicast in most enterprise environments to avoid the MAC address sharing problem inherent in Unicast mode. In Multicast mode, each node retains its original MAC address, and the cluster IP is associated with a multicast MAC address.

Verify the cluster was created:

Get-NlbCluster | Select-Object ClusterName, ClusterNetworkAddress, PrimaryClusterNetworkAddress, OperationMode
Get-NlbClusterNode | Select-Object NodeName, Status, HostPriority

Adding Nodes to the NLB Cluster

After creating the cluster on the first node, add additional nodes. Each node must have the NLB feature installed and the cluster IP should NOT be manually assigned to their network adapters — NLB manages this automatically:

Add-NlbClusterNode -HostName "WEB01" `
  -NewNodeName "WEB02" `
  -NewNodeInterface "Ethernet"

Add a third node if needed:

Add-NlbClusterNode -HostName "WEB01" `
  -NewNodeName "WEB03" `
  -NewNodeInterface "Ethernet"

After adding nodes, verify all nodes are converged and online:

Get-NlbClusterNode | Select-Object NodeName, Status, HostPriority, DedicatedIpAddress

All nodes should show Status: Running and ConvergenceStatus: Converged. NLB convergence happens automatically when node membership changes — the cluster re-negotiates which node handles which portions of traffic. During convergence (typically a few seconds), some traffic may be briefly disrupted.

Configuring NLB Operation Modes: Unicast vs Multicast

Unicast mode assigns a single MAC address (the cluster MAC) to all NLB nodes for the cluster adapter. This means all nodes respond to ARP requests for the cluster IP with the same MAC. The advantage is broad switch compatibility. The disadvantage is that NLB nodes cannot communicate with each other using the cluster IP, and some switches may flood unicast frames out all ports (since multiple ports have the same MAC), consuming bandwidth. For Unicast deployments, add a dedicated second NIC for management and inter-node communication.

Multicast mode keeps each node’s original MAC address intact and maps the cluster IP to a multicast MAC address (in the 01-00-5E range). Nodes can communicate with each other normally. However, some routers and switches require a static ARP entry to associate the cluster IP with the multicast MAC since they may not proxy ARP for multicast addresses. Add this on your router/switch:

# On a Cisco switch (static ARP for multicast NLB)
arp 192.168.1.100 0100.5e7f.0064 arpa

Change the operation mode of an existing cluster using PowerShell:

Set-NlbCluster -HostName "WEB01" -OperationMode Multicast

Configuring NLB Port Rules

Port rules define which traffic the NLB cluster handles and how it is distributed. By default, NLB creates a single rule covering all ports (0-65535) for all protocols with Multiple Host filtering (all nodes handle traffic). For a web server cluster, you typically want more specific rules. First, remove the default all-ports rule and add specific rules:

# Remove the default catch-all port rule
Remove-NlbClusterPortRule -HostName "WEB01" -Port 0

# Add a rule for HTTP (port 80)
Add-NlbClusterPortRule -HostName "WEB01" `
  -Protocol TCP `
  -StartPort 80 `
  -EndPort 80 `
  -Mode Multiple `
  -Affinity Single `
  -LoadWeight Equal

# Add a rule for HTTPS (port 443)
Add-NlbClusterPortRule -HostName "WEB01" `
  -Protocol TCP `
  -StartPort 443 `
  -EndPort 443 `
  -Mode Multiple `
  -Affinity Single `
  -LoadWeight Equal

View existing port rules:

Get-NlbClusterPortRule -HostName "WEB01" | Select-Object StartPort, EndPort, Protocol, Mode, Affinity, LoadWeight

NLB Affinity Types Explained

Affinity determines how NLB maps client connections to specific nodes. There are three affinity options:

None — No affinity. NLB distributes each new connection to any node based on load. A single client may be directed to different nodes for different connections. This maximizes load distribution but breaks any server-side session state. Only use this when your application stores session state externally (Redis, SQL Server, etc.).

Single — Single client IP affinity. All connections from a given client IP address are always routed to the same node. This preserves server-side sessions but can create uneven load if many clients share a single IP (e.g., behind a corporate NAT). This is the most common affinity setting for IIS-hosted applications with in-memory session state.

Network — Class C network affinity. All connections from a client IP within the same /24 subnet are routed to the same node. A compromise between None and Single for environments with many clients behind NAT.

# Change affinity on port 443 rule
Set-NlbClusterPortRule -HostName "WEB01" -Port 443 -Affinity Single

Draining Connections for Maintenance

When you need to take a node offline for maintenance, use the drain feature rather than stopping NLB abruptly. Draining allows existing connections to complete naturally while preventing new connections from being directed to that node:

# Drain connections on WEB02 (accepts no new connections, existing ones finish)
Stop-NlbClusterNode -HostName "WEB01" -NodeName "WEB02" -Drain

# Check drain status
Get-NlbClusterNode -HostName "WEB01" | Where-Object NodeName -eq "WEB02" | Select-Object NodeName, Status

Once the node shows Status: Draining and eventually all connections have closed, you can fully stop NLB on that node:

Stop-NlbClusterNode -HostName "WEB01" -NodeName "WEB02"

After maintenance, bring the node back into the cluster:

Start-NlbClusterNode -HostName "WEB01" -NodeName "WEB02"

Configuring NLB for IIS, RDS, and HTTPS

For IIS web farms, ensure that all NLB nodes have identical web content. Use DFS-R (Distributed File System Replication) to keep content synchronized, or deploy from a CI/CD pipeline that targets all nodes. IIS application pool identities and machine keys must be synchronized if you use forms authentication — generate the same machine key on all nodes and add it to each site’s web.config:

For Remote Desktop Services (RDS), NLB can distribute connections across a farm of RDSH servers. Configure each server identically with the same applications, and use Roaming User Profiles or FSLogix profile containers so user profiles follow them regardless of which node they land on. Create a port rule specifically for RDP (TCP 3389) with Single affinity.

For HTTPS, each NLB node must have the SSL certificate installed in its local certificate store (bound in IIS to port 443). The certificate should be issued to the NLB cluster name (e.g., webcluster.contoso.com). Export the PFX from one node and import it on all others. NLB does not terminate SSL — each node terminates its own SSL connections.

NLB Limitations and When to Use a Layer-7 Load Balancer

NLB’s Layer 4 operation means it cannot make routing decisions based on URL paths, HTTP headers, or cookie values. It cannot do SSL offloading (terminating HTTPS at the load balancer and forwarding plain HTTP to backends). It has no health checking — if an IIS application crashes on one node, NLB will continue sending traffic to that node because the TCP stack is still responding on port 443. You would need a separate health monitoring solution (System Center, custom scripts, or a third-party agent) to detect application failures and manually stop NLB on affected nodes.

For content-based routing (e.g., route /api to one set of servers and /static to another), URL rewriting, WebSocket support with smart affinity, or true health-check-based load balancing, consider IIS Application Request Routing (ARR), NGINX, HAProxy, or a dedicated hardware/software ADC. These tools operate at Layer 7 and are far more capable for complex web application topologies. NLB remains valuable for its simplicity, zero licensing cost, and tight Windows integration for straightforward TCP workloads.

Managing NLB with nlbmgr.exe

The NLB Manager GUI (nlbmgr.exe) provides a graphical interface for all NLB operations. Launch it from the Start menu or by running nlbmgr.exe. From the GUI you can connect to existing clusters, add or remove nodes, configure port rules, start/stop/drain individual nodes, and view convergence status. The GUI connects to NLB hosts remotely over WMI (Windows Management Instrumentation), so ensure WMI traffic is allowed through host firewalls.

For scripted automation, all operations are also available via the NetworkLoadBalancingClusters PowerShell module. Export the current cluster configuration for backup or replication:

# Export cluster configuration to XML
$cluster = Get-NlbCluster -HostName "WEB01"
$cluster | Export-Clixml -Path "C:BackupNLBConfig_$(Get-Date -Format yyyyMMdd).xml"

# View all port rules
Get-NlbClusterPortRule -HostName "WEB01" | Format-Table -AutoSize

# View node statistics
Get-NlbClusterNodeStat -HostName "WEB01" | Format-Table -AutoSize

Regularly test NLB failover by stopping NLB on one node while monitoring client connectivity. With proper port rule configuration, correct affinity settings, and synchronized application state, NLB provides an effective and cost-efficient load distribution solution for Windows Server 2022 workloads.