How to Set Up a Windows Server Load Balancer with NLB on Windows Server 2025

Network Load Balancing (NLB) is a built-in Windows Server clustering technology that distributes incoming TCP/IP traffic across multiple servers, providing high availability and horizontal scalability without additional hardware. Unlike hardware load balancers, NLB operates at the network layer using a distributed algorithm where every node in the cluster participates in routing decisions. On Windows Server 2025, NLB remains a straightforward option for distributing stateless workloads such as web servers, VPN endpoints, and terminal services. This tutorial walks through installing the NLB feature, creating a cluster, adding nodes, and configuring port rules using PowerShell — giving you a production-ready NLB setup from the command line.

Prerequisites

  • Two or more Windows Server 2025 machines with static IP addresses on the same subnet
  • Each node must have at least one dedicated NIC for cluster traffic (two NICs per node is recommended — one for cluster, one for management)
  • PowerShell 5.1 or later, running as Administrator on all nodes
  • Windows Firewall rules permitting ICMP and the service ports you intend to load-balance
  • No domain membership is strictly required, but workgroup environments require matching local administrator credentials across all nodes

Step 1: Understanding Unicast vs Multicast Mode

NLB supports two cluster operation modes, and choosing correctly before installation saves considerable reconfiguration effort later.

Unicast mode assigns a single virtual MAC address to the cluster. All nodes share this MAC, which means inter-node communication cannot occur over the cluster NIC — the reason a dedicated management NIC is strongly recommended. Unicast is simpler and works on most switches without additional configuration.

Multicast mode assigns a multicast MAC to the cluster IP while each node retains its original unicast MAC. Nodes can communicate with each other over the cluster NIC, but some switches require static ARP entries to resolve the multicast MAC correctly. Multicast is preferred in environments where a management NIC is not available or when inter-node communication is required over the cluster adapter.

For this tutorial, unicast mode is used, which is the default on Windows Server 2025.

Step 2: Installing the NLB Feature

Run the following command on every node that will participate in the cluster. The -IncludeManagementTools flag also installs the NLB Manager GUI and PowerShell cmdlets.

# Run on each cluster node
Install-WindowsFeature NLB -IncludeManagementTools -Restart

After the server restarts, verify the installation:

Get-WindowsFeature -Name NLB

# Expected output:
# Display Name                        Name  Install State
# ------------                        ----  -------------
# [X] Network Load Balancing          NLB   Installed

Also import the NLB PowerShell module if it is not loaded automatically in your session:

Import-Module NetworkLoadBalancingClusters

Step 3: Creating the NLB Cluster

The cluster is created from one of the nodes (the primary node). You will need the virtual cluster IP address — an IP that clients connect to — and the IP of the primary node’s cluster NIC.

# Variables — adjust to your environment
$ClusterIP      = "10.10.1.100"
$ClusterSubnet  = "255.255.255.0"
$PrimaryNodeIP  = "10.10.1.11"     # IP on the cluster NIC of this node
$ClusterName    = "WEB-NLB-CLUSTER"

# Create the cluster
New-NlbCluster `
    -HostName            $env:COMPUTERNAME `
    -ClusterName         $ClusterName `
    -ClusterPrimaryIP    $PrimaryNodeIP `
    -ClusterIPAddress    "$ClusterIP/$ClusterSubnet" `
    -InterfaceName       "Ethernet" `
    -OperationMode       "Unicast"

On success, NLB returns a cluster object. Verify with:

Get-NlbCluster

Step 4: Adding Additional Cluster Nodes

Once the cluster exists, add the remaining nodes from the primary node. Each node must already have the NLB feature installed (Step 2).

# Add a second node
Add-NlbClusterNode `
    -HostName    "WEB02" `
    -NewNodeName "WEB02" `
    -NewNodeInterface "Ethernet" `
    -NewNodeIPAddress "10.10.1.12"

# Add a third node
Add-NlbClusterNode `
    -HostName    "WEB02" `
    -NewNodeName "WEB03" `
    -NewNodeInterface "Ethernet" `
    -NewNodeIPAddress "10.10.1.13"

Confirm all nodes are visible and converged:

Get-NlbClusterNode

# NodeName  HostPriority  DedicatedIPAddress  Status
# --------  ------------  ------------------  ------
# WEB01     1             10.10.1.11          Converged
# WEB02     2             10.10.1.12          Converged
# WEB03     3             10.10.1.13          Converged

Convergence is the process by which all NLB nodes agree on cluster membership and traffic distribution. After adding or removing a node, NLB enters a convergence period (typically a few seconds) before traffic resumes normally.

Step 5: Configuring Port Rules

Port rules define which traffic the cluster handles and how it is distributed. A default port rule covering all ports and all protocols is created automatically; in production it is best to remove it and create explicit rules.

# Remove the default all-ports rule
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force

# Allow HTTP (TCP 80)
Add-NlbClusterPortRule `
    -StartPort   80 `
    -EndPort     80 `
    -Protocol    TCP `
    -Affinity    None `
    -LoadWeight  Equal

# Allow HTTPS (TCP 443)
Add-NlbClusterPortRule `
    -StartPort   443 `
    -EndPort     443 `
    -Protocol    TCP `
    -Affinity    Single `
    -LoadWeight  Equal

# Allow DNS (UDP 53) — example for a DNS load-balancing scenario
Add-NlbClusterPortRule `
    -StartPort   53 `
    -EndPort     53 `
    -Protocol    UDP `
    -Affinity    None `
    -LoadWeight  Equal

The -Affinity parameter controls session stickiness:

  • None — no affinity; requests are distributed without regard to source IP (best throughput for stateless services)
  • Single — source IP affinity; all requests from a given client IP go to the same node (useful for HTTPS without shared session state)
  • ClassC — Class C (24-bit) subnet affinity; all clients in the same /24 subnet hit the same node

Step 6: Verifying the Cluster

# Check overall cluster status
Get-NlbCluster | Format-List *

# Check port rules
Get-NlbClusterPortRule | Format-Table -AutoSize

# Test connectivity to the cluster IP from an external machine
Test-NetConnection -ComputerName 10.10.1.100 -Port 80

From a client machine, browse to http://10.10.1.100. Requests should round-robin across your web nodes (verifiable by checking IIS access logs on each node).

Step 7: NLB vs ARR vs Azure Load Balancer

NLB has notable limitations that make it unsuitable for some workloads:

  • No health checks — NLB does not probe backend node health. A failed web application on a node still receives traffic unless you manually drain the node with Stop-NlbClusterNode.
  • No content-based routing — NLB works at Layer 4 (transport) and cannot route based on URL path, HTTP headers, or cookies.
  • Session affinity is coarse — IP-based affinity does not handle clients behind NAT well (all NAT’d clients share one IP and hit the same node).

IIS Application Request Routing (ARR) is a Layer 7 reverse-proxy built into IIS that supports URL-based routing, health probes, and cookie-based affinity — making it a better choice for HTTP/HTTPS workloads on-premises.

Azure Load Balancer (or Azure Application Gateway) is appropriate when your workload runs in or will migrate to Azure, providing managed health probing, autoscaling integration, and WAF capabilities without managing cluster nodes.

Conclusion

Windows Server 2025 NLB provides a free, low-overhead solution for distributing TCP/UDP traffic across multiple nodes without third-party software. By following this guide you have installed the NLB feature, created a unicast cluster, added multiple nodes, and defined explicit port rules for HTTP, HTTPS, and UDP traffic. While NLB is well-suited to stateless services that do not require health monitoring or Layer 7 routing, for more advanced scenarios consider pairing NLB with IIS ARR or adopting a dedicated load-balancing solution. Regular monitoring of cluster convergence events in Event Viewer (source: NLB) and periodic testing of failover behavior will keep your cluster reliable in production.