Forum Discussion
Windows Server 2022 File Server Cluster | Network Teaming
Hello Microsoft Community,
I have a Windows Server 2022 File Server Cluster (all physical nodes) running with SMB shares. At present, it is not configured with NIC teaming.
We are planning to setup NIC teaming. I am going to add an additional network adapter to achieve this.
Since this is a production file server server. It tried to perform NIC teaming in a test environment. Upon setting up network teaming, File server clustered roles do not come online and fail. It registers an Event ID 1049 about duplicate IPs despite the fact that I have deleted old network adapter via device manager (show hidden devices). New network adapter comes online without any previous knowledge of IPs. When setting up old IP scheme on a new individual network adapter, File server clustered roles come online successfully. However, setting up the old IP scheme on teamed network adapter, it registers Event ID 1049 about duplicate IPs and roles shows a status of Failed instead of Stopped. Duplicate IPs are only registered for clustered file server roles. They are not registered for node IPs and cluster management IPs.
What would be a best way to achieve network teaming on an existing file server cluster without setting up the cluster from scratch?
1 Reply
Hi, I would be cautious changing networking under an existing file server cluster, especially with clustered IP resources already in play.
For file server clusters, first consider whether you really need NIC teaming, or whether SMB Multichannel with separate NICs gives you the redundancy/performance you want with less cluster pain. If you do proceed with teaming, do it one node at a time in a maintenance window: drain roles, create the team, verify bindings/DNS, bring the node back, and run cluster validation for networking.
The duplicate IP event on the clustered roles suggests the cluster IP resource is seeing an address conflict or stale network identity after the team is introduced. Check old hidden adapters on every node, DNS records for the clustered name, ARP/neighbor cache on the network, and the cluster network/resource configuration. I would not make this change in production until the exact test-lab duplicate-IP cause is understood.
