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

Network Load Balancing (NLB) is a built-in Windows Server feature that distributes incoming TCP/IP traffic across multiple servers using a software-based approach that requires no dedicated hardware. On Windows Server 2025, NLB remains a viable option for distributing load across IIS web farm nodes, Remote Desktop Gateway servers, Remote Desktop Web servers, and other stateless or near-stateless services. While modern alternatives such as Azure Load Balancer and Application Request Routing (ARR) offer richer health checking and session intelligence, NLB is free, requires no additional infrastructure, and integrates directly with Windows Server roles. This tutorial covers the complete NLB configuration workflow using PowerShell, including cluster creation, node addition, port rule configuration, traffic management, and an honest comparison with alternative solutions.

NLB Use Cases

NLB is best suited for scenarios where you control all servers directly and your traffic patterns are relatively uniform:

  • IIS web farms: distribute HTTP/HTTPS requests across multiple web servers hosting the same application
  • RD Gateway: load balance Remote Desktop Gateway servers handling RDP-over-HTTPS connections
  • RD Web: distribute Remote Desktop Web Access portal requests
  • Stateless API endpoints: REST APIs where any server can handle any request without session affinity
  • Internal load balancing: situations where Azure Load Balancer is unavailable or not desired

NLB is not appropriate for database servers, file servers, or any service that maintains per-connection state unless you configure client affinity rules carefully.

Prerequisites

  • Two or more Windows Server 2025 nodes to form the NLB cluster
  • Each node must have at least one network adapter; two adapters (one for NLB traffic, one for management) is strongly recommended
  • All nodes should be domain-joined and running the same Windows Server 2025 build
  • A virtual IP address (the Cluster IP) allocated from your network — this is the address clients connect to
  • Multicast mode requires your network switch to support static ARP entries or IGMP snooping
  • Administrative access on all nodes

Step 1 — Install the NLB Feature on All Nodes

Install Network Load Balancing and its management tools on every server that will participate in the cluster. Use PowerShell remoting to push the installation to all nodes simultaneously.

$nodes = 'WEB-NODE1', 'WEB-NODE2', 'WEB-NODE3'

Invoke-Command -ComputerName $nodes -ScriptBlock {
    Install-WindowsFeature -Name NLB -IncludeManagementTools
    Install-WindowsFeature -Name RSAT-NLB
}

# Verify installation
Invoke-Command -ComputerName $nodes -ScriptBlock {
    Get-WindowsFeature -Name NLB | Select-Object Name, InstallState
}

No reboot is required after NLB installation. The NLB driver is loaded and the nlb.sys kernel driver becomes active on the specified network adapter.

Step 2 — Create the NLB Cluster

Create the NLB cluster from the first node. You will specify the virtual IP address, subnet mask, and operation mode. Multicast mode is recommended when nodes reside on the same subnet and your switch supports static ARP; Unicast mode causes all nodes to share the same MAC address, which can cause switch flooding.

# Create NLB cluster on the first node
# Replace InterfaceName with the adapter name used for NLB traffic (e.g., "Ethernet" or "NLB-Traffic")
New-NlbCluster `
    -HostName WEB-NODE1 `
    -ClusterName WEBNLB01 `
    -InterfaceName "Ethernet" `
    -ClusterPrimaryIP 10.10.2.100 `
    -SubnetMask 255.255.255.0 `
    -OperationMode Multicast

# Verify the cluster was created
Get-NlbCluster

After creation, the cluster will show as a single-node cluster. Inspect the cluster properties to confirm the virtual IP and operation mode:

Get-NlbCluster | Select-Object ClusterName, ClusterIPAddress, OperationMode |
    Format-List

Step 3 — Add Additional Nodes

Add each remaining server to the NLB cluster. Run the Add-NlbClusterNode command from an existing cluster member or from a management workstation with RSAT installed.

# Add WEB-NODE2 to the cluster
Add-NlbClusterNode `
    -HostName WEB-NODE2 `
    -InterfaceName "Ethernet" `
    -NewNodeInterface "Ethernet" `
    -NewNodeName WEB-NODE2

# Add WEB-NODE3
Add-NlbClusterNode `
    -HostName WEB-NODE3 `
    -InterfaceName "Ethernet" `
    -NewNodeInterface "Ethernet" `
    -NewNodeName WEB-NODE3

# List all nodes and their status
Get-NlbClusterNode | Select-Object NodeName, Status, HostPriority

Each node is assigned a host priority automatically. Priority 1 handles traffic for port rules with Single affinity when a single host is needed. All nodes with equal port rule weights share traffic proportionally under No affinity.

Step 4 — Configure Port Rules

Port rules define which traffic the NLB cluster handles and how it distributes that traffic across nodes. The default port rule covers all TCP/UDP traffic on all ports, which is rarely appropriate for production. Remove the default and add specific rules.

# Remove the default all-traffic port rule
Get-NlbClusterPortRule -HostName WEB-NODE1 | Remove-NlbClusterPortRule -Force

# Add a rule for HTTP (port 80) with No affinity (stateless web traffic)
Add-NlbClusterPortRule `
    -HostName WEB-NODE1 `
    -Protocol TCP `
    -StartPort 80 `
    -EndPort 80 `
    -Mode Multiple `
    -Affinity None `
    -LoadWeight 50

# Add a rule for HTTPS (port 443) with Single affinity (TLS session persistence)
Add-NlbClusterPortRule `
    -HostName WEB-NODE1 `
    -Protocol TCP `
    -StartPort 443 `
    -EndPort 443 `
    -Mode Multiple `
    -Affinity Single `
    -LoadWeight 50

# Verify port rules
Get-NlbClusterPortRule -HostName WEB-NODE1 | Format-Table -AutoSize

Affinity Options Explained

  • None: each incoming connection is distributed independently to any available node — maximum distribution, best for truly stateless services
  • Single: all connections from the same client IP address go to the same node — required for applications that store session state in server memory
  • ClassC: all connections from the same /24 subnet go to the same node — useful for clients behind NAT where all requests share an IP

Step 5 — Manage Node Traffic

You can take individual nodes out of the cluster rotation for maintenance without removing them from the cluster. This is the equivalent of draining a node in modern load balancers.

# Stop a node from receiving new connections (existing connections continue)
Stop-NlbClusterNode -HostName WEB-NODE2

# Resume the node
Start-NlbClusterNode -HostName WEB-NODE2

# Drain the node — stop after existing connections complete (drainstop)
Stop-NlbClusterNode -HostName WEB-NODE2 -Drain

# Check node status
Get-NlbClusterNode -HostName WEB-NODE2 | Select-Object NodeName, Status

During a drainstop, the node stops accepting new connections but allows existing connections to complete. This is the correct approach for patch maintenance windows on NLB-managed web servers.

Step 6 — Verify Traffic Distribution

NLB does not provide built-in traffic statistics at the same depth as a dedicated load balancer. Use Windows performance counters and IIS logs to verify even distribution:

# Check NLB performance counters on each node
Get-Counter -ComputerName WEB-NODE1, WEB-NODE2, WEB-NODE3 `
    -Counter "Network Load BalancingTotal Connections Established"

# Review IIS access logs for request counts per node
Get-Content "C:inetpublogsLogFilesW3SVC1u_ex$(Get-Date -Format 'yyMMdd').log" |
    Measure-Object -Line

NLB Limitations

NLB’s simplicity comes with important limitations that must inform your architecture decisions:

  • No health checking: NLB does not probe backends for health. If IIS stops on one node, NLB continues sending traffic to it. You must implement external health monitoring and remove unhealthy nodes manually or via script.
  • No session state awareness: NLB cannot share session state between nodes. Use a distributed cache (Redis, SQL-backed sessions) or Single affinity if your application requires session persistence.
  • Unicast MAC flooding: in Unicast mode, all nodes share one MAC address, which may cause network switches to flood all ports on the VLAN. Use Multicast or dedicated NLB adapters.
  • No SSL offload: NLB passes TLS connections directly to backend nodes. Each node must have the SSL certificate installed.
  • Limited to 32 nodes: NLB clusters support a maximum of 32 nodes.

Comparing NLB with ARR and Azure Load Balancer

For IIS-specific scenarios, Application Request Routing (ARR) in IIS is a significantly more capable HTTP-aware reverse proxy. ARR supports URL-based routing, server health probes, session affinity via cookies, SSL offload, and content-based routing. ARR requires a dedicated proxy tier but eliminates all of NLB’s health-checking limitations for web workloads.

Azure Load Balancer (when workloads run in Azure or Azure Stack HCI) provides health probe-based distribution, zone redundancy, outbound NAT rules, and deep integration with Azure Monitor — at the cost of Azure subscription dependency. For hybrid environments, Azure Application Gateway adds WAF, TLS termination, and URL routing in a managed PaaS model.

Choose NLB when you need fast, zero-cost load distribution for simple stateless workloads with no external dependencies. Choose ARR for IIS web farms needing health awareness. Choose Azure Load Balancer or Application Gateway for cloud-connected or Azure-hosted workloads.

Conclusion

Network Load Balancing on Windows Server 2025 is a powerful tool when applied to the right scenarios. By installing the NLB feature across all participating nodes, creating a cluster with the correct operation mode, defining precise port rules with appropriate affinity settings, and using drain-stop procedures for maintenance, you build a functional and cost-effective load balancing tier without additional hardware. Pair NLB with external health monitoring scripts and IIS log aggregation to compensate for its lack of native health probing, and you have a production-ready distribution layer for stateless web workloads and Remote Desktop infrastructure.