Introduction
Some organisations may still have ADFS v2 or ADFS v2.1 running in their environment, and haven’t yet moved to ADFS v3. In this blog, we will discuss how can you move away from ADFS v2 or ADFS v2.1 and migrate or upgrade to ADFS 2016.
In previous posts, Part 1 and Part 2 we have covered the migration of ADFS v3.0 to ADFS 2016. I have received some messages on LinkedIn to cover the migration process from ADFS v2 to ADFS 2016 as there currently isn’t much information about this.
As you may have noticed from the previous posts, upgrading to ADFS 2016 couldn’t be any easier. In ADFS v2 however, the process is as simple, albeit differently than upgrading from ADFS v2 or ADFS v2.1 to ADFS v3.
Migration Process
Before we begin however, this post assumes you already have a running ADFS v2 or ADFS v2.1 environment. This blog post will not go into a step-by-step installation of ADFSv2/ADFSv2.1, and will only cover the migration or upgrade to ADFS 2016.
This blog post assumes you already have a running Windows Server 2016 with the ADFS 2016 role installed, if not, please follow the procedures outlined in part 2.
Prerequisites
Prior to commencing the upgrade, there are few tasks you need to perform.
- Take a note of your ADFS Server Display Name
- Take a note of your Federation Service Name
- Take note of your federation Service Identifier
- Export the service communication certificate (if you don’t already have a copy of it)
- Install/Import the service communication certificate onto ADFS 2016 server
Notes:
- There is no need to make your ADFS 2016 server as primary, since this should have been a new installation. You can’t add to an ADFS v2/ADFS v2.1 farm anyway.
- There is no need to raise the farm behavior level, since this is not a farm member like we did when migrating from ADFS v3 to ADFS 2016.
- However, you will still need to upgrade the schema as outlined in part 2.
Before you begin, you will need to download the following PowerShell script found here.
Those scripts can also be found in the support\adfs location in the Windows Server 2016 installation file. Those scripts are provided by Microsoft and not Kloud.
The two main functions, are the export and import federation configuration.
Let’s begin
Firstly, we will need to export the federation configuration by running the “export-federationconfiguration.ps1”.
Here are the current relying party trust I have in the ADFS v2.1.
The “Claims Provider Trust” is Active Directory, this toll will be exported and imported.
1- Navigate to the folder you have just downloaded:
Then, type
[code language=”PowerShell”].\export-federationconfiguration.ps1 -path "c:\users\username\desktop\exported adfs configuration"[/code]
Once successful, you will see the same results in the above picture.
Open your folder, and you should see the extracted configuration in .xml files.
2- Head over your ADFS 2016 Server and copy/paste both the folder in which you have extracted your federation configuration, and the one you downloaded that includes the scripts.
Then open PowerShell and run:
[code language=”PowerShell”].\import-federationconfiguration.ps1 -path "c:\users\username\desktop\exported adfs configuration"[/code]
When successful, you will see a similar message as above.
And now when you open the ADFS management you should see the same relying party trust as you had in ADFS v2/ADFS v2.1.
Basically, by now you have completed the move from ADFSv2/ADFSv2.1 to ADFS 2016.
Notice how the token-signing and token-decrypting certificates are the same. The screenshots below are only of the token-signing certificates only, for the purpose of this blog.
ADFS v2.1:
ADFS 2016:
You can also check the certificates through PowerShell:
[code language=”PowerShell”]Get-AdfsCertificate[/code]
Last thing, make sure that service account that was running the Active Direction Federation Services in ADFS v2/ADFS v2.1 is the same one running in ADFS 2016.
Notice the message in the exported results:
Ensure that the destination farm has the farm name ‘adfs.iknowtech.com.au’ and uses service account ‘IKNOWTECH\svc-adfs’.
If this is not setup, then head over your services and select the account that you were originally using to run the ADFS service.
In addition, make sure that the service account has read-only access to the certificate private key.
Conclusion
This is a very straight forward process, all that you need to be sure of is to have the right components in place, service certificate installed, service account setup, etc.
After you have complete the steps, follow the steps here to configure your Web Application Proxy. Although this covers a migration, but it also helps you in configuring a new deployment.
I hope you’ve found this informative. Should you have any question or feedback please leave a comment below.
this is just great, thank you so much for the info!
Thank you for this guide, I found it very useful. Just a question, after the migration can I switch off the server with adfs 2? Or something else is required?
Did you just switch your dns and re run claims?
does the role need to be configured as the first federation server in a farm after being installed?
Hello,
I get the “Failed to read the policy store connection string from the AD FS service configuration file” when running the Import script. Is there any ADFS configuration to do before importing on the 2016 Server ?
Thanks in advance.
We are running into the same error on import. Did you ever get a response on this or were you able to figure it out?
Hello,
Is there a significant advantage migrating WAP to 2016?
If so, what those would be?
Thanks in advance
This is excellent. However, we are running into a problem on doing the import. Also getting “failed to read the policy store connection string from the AD FS service configuration file….”
What would be the process for also upgrading the ADFS Proxy (in the DMZ) to 2016?
@Gary
Did you ever figure this part out? I am getting
Federation metadata does not contain a public key of the certificate used by the AD FS server to sign the Web Application Proxy Service token.
can you help me ? :
PS C:\Users\admin\Desktop\ADFS 2.0 to ADFS 2016 Migration> .\import-federationconfiguration.ps1 -path “c:\users\admin\desktop\export-adfs”
Import Federation Configurations.
If you choose to import federation configurations, all existing claims provider and relying party trusts on the target
server will be deleted. Do you want to continue?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”): a
Reading configurations from folder ‘C:\users\admin\desktop\export-adfs’…
Importing federation services configurations to server ‘ADFS01’…
Failed to read the policy store connection string from the AD FS service configuration file ‘C:\Windows\ADFS\Microsoft. IdentityServer.Servicehost.exe.config’.
For help with AD FS migration, see http://go.microsoft.com/fwlink/?LinkId=294108.
At C:\Users\admin\Desktop\ADFS 2.0 to ADFS 2016 Migration\import-federationconfiguration.ps1:300 char:13
+ throw (“{0}`n{1}” -f $obj, ($_system_translations.MoreHel …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Failed to read …?LinkId=294108.:String) [], RuntimeException
+ FullyQualifiedErrorId : Failed to read the policy store connection string from the AD FS service configuration f
ile ‘C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config’.
For help with AD FS migration, see http://go.microsoft.com/fwlink/?LinkId=294108.
“This blog post assumes you already have a running Windows Server 2016 with the ADFS 2016 role installed, if not, please follow the procedures outlined in part 2.”
So you install ADFS 2016 and leave it unconfigured?
Great read. Quick question, Can i add WAP to the ADFS server itself? Then I’d just have to update DNS/Firewall config to point to the new server.
Planning a *migration* (not upgrade, so new service entirely) from ADFS 2 to 4. Considering this approach to shift RPTs (apps) from one ADFS service to another:
* Get-ADFSClaimsProviderTrust | Export-Clixml -Path
* Get-AdfsRelyingPartyTrust | Export-Clixml -Path <path to XML file for RP trust
Then import into new farm.
My thought is to do the 'copy' of RPT config, then provide app teams with a limited window to test applications against the new service and migrate prod apps before the old service is shut down. So there's nothing preventing us from having RPTs configured on both services, and it's purely up to apps to update service address and certs as and when they're ready? My caveat would be a 'change freeze' on the old service so as not to introduce config drift. Sensible?