ADFS migration issue from 2016 OS to 2025 OS.

Hello naveen0007​ ,

Joining a newer-OS node to an existing farm and leaving the farm at its current behavior level is the normal AD FS rolling-upgrade pattern. It has worked for 2012 R2 to 2016 and 2016 to 2019/2022. I couldn’t find a 2025-specific page that explicitly confirms or excludes joining a 2025 node to a 2016-level farm. So check Microsoft’s current AD FS upgrade documentation before you commit to a production cutover.

AD FS Requirements for Windows Server | Microsoft Learn
Verify That a Federation Server Is Operational | Microsoft Learn
Upgrade an AD FS farm by using Windows Internal Database in Windows Server | Microsoft Learn
Upgrade to AD FS on Windows Server 2016 with SQL Server | Microsoft Learn

The message comes from the join prerequisite check, not from the farm’s behavior level. A few things commonly cause it even when SPNs look right in AD:

1. The SPN is on a different object, or duplicated. The SPN must sit on the gMSA object itself, not on a user, computer, or the old service account. Duplicates make the lookup unreliable.
2. It is checking for host/<FederationServiceName>, not http/. AD FS setup normally registers host/<fsname> on the service account. If you only see http/ SPNs, that could explain it.
3. The joining account can’t read the gMSA’s attributes. Run Add-AdfsFarmNode as a domain account, not a local admin.
4. The new node isn’t allowed to retrieve the gMSA password. Check PrincipalsAllowedToRetrieveManagedPassword, and reboot the node after adding it to the group so it gets a fresh Kerberos ticket.

The SPN error does not, by itself, establish that your Windows Server 2016-to-2025 farm expansion is unsupported. Microsoft’s current WID upgrade guidance applies to Server 2025 and allows a newer federation server to join a lower-FBL farm temporarily in mixed mode. AD FS also supports gMSAs. First confirm whether your configuration database is WID or SQL, because the join parameters differ. For a gMSA, check that Add-AdfsFarmNode uses GroupServiceAccountIdentifier for the existing farm account, rather than ordinary service-account credentials. Verify the new server can retrieve that gMSA’s password using Test-ADServiceAccount, and inspect the exact account’s SPNs from the new node. Do not delete or recreate SPNs simply because setup reports them missing. Keep the existing farm operational and collect the command, verbose output, and AD FS event details for Microsoft support. I cannot confirm an officially documented 2025 gMSA defect matching this error.