Windows Server 2025 NIC Teaming: LBFO vs SET Setup Guide

Windows Server 2025 still has a place for NIC Teaming, but the first decision is not the team name or the IP address. It is whether you should create a classic LBFO team or build the team into a Hyper-V virtual switch with Switch Embedded Teaming.

That distinction matters. A file server management network, a backup network, and a Hyper-V host carrying VM traffic are not the same design. If you use the wrong teaming model, the server may work at first and then behave badly under live migration, failover, RDMA storage, VLANs, or driver updates.

This guide shows the practical Windows Server 2025 NIC Teaming options, the PowerShell commands for LBFO and SET, and the checks you should run before you trust the configuration.

LBFO vs SET in Windows Server 2025#

Windows admins use “NIC Teaming” to describe more than one thing. On Server 2025, the two important models are LBFO and SET.

For a simple management network on a physical server, LBFO may still be reasonable. For a Hyper-V host, SET is usually the better starting point because it is part of the virtual switch instead of sitting underneath it as a separate team.

Microsoft’s Hyper-V network recommendations also call out a critical storage detail: NIC Teaming disables RDMA on the member adapters. If your design depends on SMB Direct, Storage Spaces Direct, or RDMA-capable storage traffic, do not casually put those adapters in a classic LBFO team.

Recommended SEO title options#

For this topic, the strongest titles are the ones that include “Windows Server 2025 NIC Teaming” and then clarify LBFO vs SET. The title used for this article is the best balance of keyword and admin intent:

Before you create a team#

Plan the adapters before touching PowerShell. Most NIC teaming problems are design problems: wrong adapters, wrong switch ports, mixed speeds, or storage traffic accidentally losing RDMA.

Get the adapter names first:

Get-NetAdapter

Example:

Name          InterfaceDescription                 Status   LinkSpeed
----          --------------------                 ------   ---------
NIC1          Broadcom 10GbE Adapter #1             Up       10 Gbps
NIC2          Broadcom 10GbE Adapter #2             Up       10 Gbps
NIC3          Broadcom 10GbE Adapter #3             Up       10 Gbps
NIC4          Broadcom 10GbE Adapter #4             Up       10 Gbps

Use the Name values exactly in the commands. If the server has unclear adapter names like Ethernet, Ethernet 2, and Ethernet 3, rename them first:

Rename-NetAdapter -Name "Ethernet" -NewName "NIC1"
Rename-NetAdapter -Name "Ethernet 2" -NewName "NIC2"

Small naming cleanup saves a lot of pain later.

Option 1: Create an LBFO NIC team#

Use this when you need a classic host-level NIC team and the adapters are not being used for a Hyper-V SET switch or RDMA storage path.

For a common switch-independent team:

New-NetLbfoTeam `
  -Name "Team-Mgmt" `
  -TeamMembers "NIC1","NIC2" `
  -TeamingMode SwitchIndependent `
  -LoadBalancingAlgorithm Dynamic

Then verify it:

Get-NetLbfoTeam
Get-NetLbfoTeamMember -Team "Team-Mgmt"
Get-NetAdapter

You should see a new team interface. Put the IP configuration on that team interface, not on the physical member adapters.

For DHCP:

ipconfig /renew

For a static address:

New-NetIPAddress `
  -InterfaceAlias "Team-Mgmt" `
  -IPAddress 192.168.10.20 `
  -PrefixLength 24 `
  -DefaultGateway 192.168.10.1

Set-DnsClientServerAddress `
  -InterfaceAlias "Team-Mgmt" `
  -ServerAddresses 192.168.10.10,192.168.10.11

LBFO teaming modes and load balancing#

Two settings drive most LBFO behavior: teaming mode and load balancing algorithm.

Do not expect every single transfer to double in speed. Teaming can provide aggregate bandwidth and failover, but one flow may still land on one physical adapter. If you need predictable high throughput for one workload, faster individual adapters are often cleaner than trying to squeeze magic out of a team.

Option 2: Create a SET switch for Hyper-V#

For Hyper-V hosts, create a SET-enabled external virtual switch instead of building an LBFO team first.

New-VMSwitch `
  -Name "vSwitch-Prod" `
  -NetAdapterName "NIC1","NIC2" `
  -EnableEmbeddedTeaming $true `
  -AllowManagementOS $true

Verify the switch:

Get-VMSwitch
Get-VMNetworkAdapter -ManagementOS

If the management OS needs an IP address on that virtual switch, configure the management vNIC:

Get-VMNetworkAdapter -ManagementOS

Then set the IP on the management adapter shown by Windows. In many builds it appears with a name like vEthernet (vSwitch-Prod).

New-NetIPAddress `
  -InterfaceAlias "vEthernet (vSwitch-Prod)" `
  -IPAddress 192.168.20.20 `
  -PrefixLength 24 `
  -DefaultGateway 192.168.20.1

Set-DnsClientServerAddress `
  -InterfaceAlias "vEthernet (vSwitch-Prod)" `
  -ServerAddresses 192.168.20.10,192.168.20.11

For a smaller lab host, allowing the management OS on the same switch can be fine. For a production cluster, plan management, live migration, storage, cluster, and VM traffic deliberately. The related guide on installing the Hyper-V role on Windows Server covers the role setup, and the Hyper-V best practices guide goes deeper on host layout.

What about RDMA and SMB storage?#

This is the section to read twice before configuring a file server, Hyper-V cluster, or storage-heavy host.

Classic NIC Teaming disables RDMA on the member adapters. That matters because SMB Direct depends on RDMA. If your design uses RDMA-capable adapters for Storage Spaces Direct, SMB storage, or high-performance file traffic, do not put those adapters into a normal LBFO team and expect RDMA to keep working.

For SMB workloads, also remember that SMB Multichannel can use multiple network paths without you creating an LBFO team. In many storage designs, SMB Multichannel plus correct adapter/VLAN/IP layout is the better answer.

The rough rule:

• Use LBFO for traditional host network redundancy where RDMA is not needed.
• Use SET for Hyper-V virtual switch teaming.
• Use SMB Multichannel and RDMA-aware design for storage traffic.

Testing failover#

After you create a team or SET switch, test it before calling the job done.

For LBFO:

Get-NetLbfoTeam
Get-NetLbfoTeamMember -Team "Team-Mgmt"

Unplug one team member cable or shut one switch port, then confirm the server stays reachable. Bring it back, wait for the member to return to active state, then test the other side.

For Hyper-V SET:

Get-VMSwitch
Get-VMNetworkAdapter -ManagementOS

Test management access, VM connectivity, live migration if applicable, and any VLANs carried by the virtual switch. A SET switch that passes one ping test is not fully validated.

Also check event logs after physical link changes. Link flaps, driver resets, and switch negotiation warnings often show up there before users notice a real outage.

Removing an LBFO team#

If you need to back out an LBFO team, move or record the IP settings first. Then remove the team:

Remove-NetLbfoTeam -Name "Team-Mgmt"

Confirm the physical adapters returned:

Get-NetAdapter
ipconfig /all

If the team interface held the only IP address, put that configuration back on a physical adapter before you leave the server.

Removing a SET virtual switch#

Be more careful with a Hyper-V switch. Removing it disconnects management vNICs and VM network adapters attached to it.

List the switch:

Get-VMSwitch

Then remove it only when you are sure:

Remove-VMSwitch -Name "vSwitch-Prod"

If you are connected remotely through the management vNIC on that switch, you can disconnect yourself. Use console access or out-of-band management for production changes.

Common mistakes#

Creating LBFO under a Hyper-V switch without a design reason
For modern Hyper-V, start with SET. It is built into the virtual switch and avoids the awkward layering of a separate LBFO team under Hyper-V.

Using LACP without switch configuration
LACP is not just a Windows setting. The switch ports must be configured as the same aggregation group. If the server says LACP and the switch does not, expect broken or inconsistent connectivity.

Putting RDMA adapters into classic NIC Teaming
LBFO disables RDMA on team members. If you need SMB Direct, plan for it before the team is created.

Mixing adapter speeds or driver families
Teaming a 10 GbE adapter with a 1 GbE adapter is usually a troubleshooting exercise waiting to happen. Keep members as similar as possible.

Assuming teaming doubles every transfer
Teaming helps aggregate traffic and failover. It does not guarantee one single flow uses every adapter.

Recommended design choices#

For a small physical server with two 1 GbE or 10 GbE ports used for management and normal LAN access, an LBFO switch-independent team with dynamic load balancing is a reasonable starting point.

For a Hyper-V host, use a SET virtual switch with matching physical adapters. Then create management OS vNICs and VM networks on top of that switch as needed.

For storage traffic, especially anything RDMA-based, step back and design the storage network separately. Do not hide it inside a generic LBFO team.

For new Windows Server 2025 deployments, this is also a good time to review what else changed in the platform. The Windows Server 2025 feature guide covers the wider release, including Hyper-V scale, security changes, and SMB improvements.

Wrapping up#

Windows Server 2025 NIC Teaming is not one button. Use LBFO when you need classic host-level teaming, use SET when Hyper-V is involved, and keep RDMA storage paths out of classic teams.

The two core commands are:

New-NetLbfoTeam -Name "Team-Mgmt" -TeamMembers "NIC1","NIC2" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

and:

New-VMSwitch -Name "vSwitch-Prod" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

Pick the one that matches the workload. That choice matters more than the exact team name.