Currently at the time of writing the following ADFS versions are available:
- ADFS v1.0 as a server role in Windows Server 2003 R2
- ADFS v1.1 as a server role in Windows Server 2008
- ADFS v1.1 as a server role in Windows Server 2008 R2
- ADFS v2.0 as a separate download for both Windows Server 2008 and Windows Server 2008 R2
- ADFS v2.1 as a server role in Windows Server 2012
- ADFS v3.0 as a server role in Windows Server 2012 R2
- ADFS v4.0 (?) as a server role in Windows Server vNext
With regards to the terms used here I mean the following with:
- Upgrading: adding an new ADFS STS to an existing ADFS farm. This is only possible if the "old" version can interoperate with the "new" version at farm level
- Migration: exporting all configuration from the existing ADFS farm and importing it into a new ADFS farm. This is always possible, either manually or (semi-) automated
Both ADFS v1.0 and ADFS v1.1 are almost the same, so upgrading from ADFS v1.0 to ADFS v1.1 is possible.
When comparing ADFS v1.x with any ADFS version starting from ADFS v2.0 you will understand, they are far from the same/similar. Therefore the only way is to migrate, and you will have to do everything manually.
Both ADFS v2.0 and ADFS v2.1 are almost the same, so upgrading from ADFS v2.0 to ADFS v2.1 is possible. While having an existing farm consisting of only ADFS v2.0 STS servers, you can add ADFS v2.1 STS servers to that farm and remove the ADFS v2.0 STS servers. Be sure to check for any custom code that you implemented and see if it still works. One thing is certain and that is you will have to recompile any DLL used by any custom attribute with the correct .NET version.
Although ADFS v2.x looks very similar to ADFS v3.0 and ADFS v4.0, under the hood they are quite different. Because of that, it is NOT possible to upgrade from ADFS v2.x to ADFS v3.0 or ADFS v4.0. The only way is to migrate everything. Be sure to check for any custom code that you implemented and see if it still works or if it needs to be implemented differently. One thing is certain and that is you will have to recompile any DLL used by any custom attribute with the correct .NET version.
For more information about this have a look at the info through the following links:
- Migrating Active Directory Federation Services Role Service to Windows Server 2012 R2
- (2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0
The links above provide information when migrating from ADFS v2.x to ADFS v3.0. That information also applies when migrating from ADFS v2.x to ADFS v4.0. However, you need to take some subtle differences into account.
- Enabling RelayState in ADFS v2.0 is done by editing the file "C:\inetpub\adfs\ls\web.config"
- Enabling RelayState in ADFS v2.1 and ADFS v3.0 is done by editing the file "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
- Enabling RelayState in ADFS v4.0 done by configuring an ADFS property
REMARK: Regarding enabling RelayState in ADFS, see: (2014-10-16) Enabling RelayState In ADFS Versions
What I’m trying to say is that in ADFS v2.x and ADFS v3.0, some configuration needed to take place in configuration files and many of those configuration have moved to become ADFS properties. So when migrating from ADFS v2.x to ADFS v4.0 and you are using the guide above, check if a property in a configuration file in ADFS v2.x has become a property in ADFS v4.0
Although ADFS v4.0 contains some interesting enhancements (see: (2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only), compared to ADFS v3.0, both ADFS v3.0 and ADFS v4.0 are almost the same, so upgrading from ADFS v3.0 to ADFS v4.0 is possible. While having an existing farm consisting of only ADFS v3.0 STS servers, you can add ADFS v4.0 STS servers to that farm and remove the ADFS v3.0 STS servers. Be sure to check for any custom code that you implemented and see if it still works. One thing is certain and that is you will have to recompile any DLL used by any custom attribute with the correct .NET version. Now when looking at the enhancements in ADFS v4.0 how is it possible to have those and still interoperate between ADFS v3.0 and ADFS v4.0 in the same farm, while ADFS v3.0 does not support those enhancements? That’s where an ADFS farm enters the world of functional levels. Yes, you are reading it right. ADFS v4.0 introduces the so called Farm Behavior/Level. When mixing ADFS v3.0 and ADFS v4.0 in the same ADFS farm, any ADFS v4.0 STS will tell you the following about the farm.
Figure 1: Viewing The Farm Behavior/Level Through An ADFS v4.0 STS When Upgrading From ADFS v3.0 To ADFS v4.0
So, how can you change the farm level? Well, first introduce at least one ADFS v4.0 STS server into the existing ADFS farm. When using WID configure the new ADFS v4.0 STS to become the primary farm member. Follow the steps as mentioned in (2014-03-19) Gathering Architectural Details From Your ADFS Infrastructure – WID Primary Computer Or Not. When using SQL, no need to transfer the primary member role as that only exist when using WID. Now introduce as many ADFS v4.0 STS members as needed. Make sure have implemented all certificates with private keys in the certificate store, and all (recompiled) attribute store DLLs on every new ADFS v4.0 STS member. After doing that get rid of the old ADFS v3.0 members.
Figure 2: ADFS MMC On An ADFS v4.0 STS Before The Increased Of the Farm Behavior/Level (The Same As The ADFS MMC On An ADFS v3.0 STS)
Now at this point in time you can increase the farm behavior/level. To do that, make sure that every ADFS v4.0 STS farm member has Remote Management enabled, which is enabled by default. That can be done on every ADFS v4.0 STS farm member through Server Manager or by executing the following command line: quickconfig winrm
# Import The ADFS PowerShell Module Import-Module ADFS # Get The Current Farm Behavior/Level (Get-ADFSProperties).CurrentFarmBehavior # Define The Admin Credentials For ADFS When Connecting $adfsAdminUserName = '<DOMAIN\ADFSADMINACCOUNT>' $adfsAdminPassword = '<ADFSADMINACCOUNTPASSWORD>' | ConvertTo-SecureString -asPlainText -Force $adfsAdminCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adfsAdminUserName,$adfsAdminPassword # Increase The Farm Behavior/Level Invoke-AdfsFarmBehaviorLevelRaise -Member <Comma-Separated list of the FQDN of each farm member> -Credential $adfsAdminCreds # Get The New Farm Behavior/Level (Get-ADFSProperties).CurrentFarmBehavior
Figure 3: Increasing The ADFS Farm Level
As you can see the Farm Behavior/Level was increased to "Threshold", whatever that may mean!
During the Farm Behavior/Level increase a new database "AdfsConfigurationV2" is created, using the old database "AdfsConfiguration" as input. After the upgrade the old database is not removed. On every farm member the connection string is adjusted to point to the new database.
Figure 4: Increasing Farm Behavior/Level Results In New Configuration Database "AdfsConfigurationV2"
REMARK: Remember that currently you may have features enabled that can only be enabled after the Farm Behavior/Level increase!
REMARK: I have not tested this, but one thing to keep in mind, AFTER the Farm Behavior/Level when performing an upgrade, is that any new ADFS STS member most likely needs to be configured through PowerShell as you need to specify a custom connection string for SQL.
Figure 5: ADFS MMC On An ADFS v4.0 STS After The Increased Of the Farm Behavior/Level (Also Applies When Installing A Brand New ADFS Farm)
Figure 6: Viewing The Farm Behavior/Level Through An ADFS v4.0 STS When Installing A New Farm
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########