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.