In Part 1 of this series we have been getting ready for our ADFS v3.0 migration to ADFS v4.0 (ADFS 2016).

In part 2 we will cover the migration process, step-by-step. However, a friendly reminder that this series does not cover installation of ADFS and federation from scratch. This post assumes you already have a federated domain and Single Sign On (SSO) for your applications.

You may notice domain change and federation service name change from swayit.com.au to iknowtech.com.au. This doesn’t impact our migration, the certificate for swayit.com.au expired before completing the lab. : )

Migration Process – ADFS – Phase 1:

Assuming you already have installed the Active Directory Federation Services on your new ADFS 2016 servers, and if not, then you could do so through PowerShell:

Install-windowsfeature adfs-federation -IncludeManagementTools

Once complete, follow these steps:

Step 1: Add the new ADFS 2016 server to the existing farm

1-add-farm

Step 2: Connect to AD2

Step 3: Specify the primary Federation server (or federation service).3

Step 4: Select your certificate4

Step 5: Select your service account. For the sake of this lab, I created a user and gave it permission to run the ADFS service. It is advisable however, to use a group managed service account (gMSA).5

Step 6: Complete.

The warnings below are irrelevant to the ADFS 2016 server being added to the farm.6

Alternatively, you could do so through PowerShell:

If you’re using Windows Internal Database:

 Import-Module ADFS

#Get the credential used for the federation service account

$serviceAccountCredential = Get-Credential -Message "Enter the credential for the Federation Service Account."

Add-AdfsFarmNode `
-CertificateThumbprint:"071E6FD450A9D10FEB42C77F75AC3FD16F4ADD5F" `
-PrimaryComputerName:"sts.swayit.com.au" `
-ServiceAccountCredential:$serviceAccountCredential 

or:

Import-Module ADFS

$credentials = Get-Credential

Install-AdfsFarm `
-CertificateThumbprint:"071E6FD450A9D10FEB42C77F75AC3FD16F4ADD5F" `
-FederationServiceDisplayName:"SwayIT" `
-FederationServiceName:"sts.swayit.com.au" `
-GroupServiceAccountIdentifier:"SWAYIT\ADFSgMSA`$"
Once the machine has restarted, open the ADFS Management Console, and you’ll notice it’s not the primary federation server in the farm. Now you need to make the newly added ADFS 2016 server as primary. Follow the steps below.

Once the newly added ADFS 2016 server run the following cmdlet:

Step 1:

Set-AdfsSyncProperties -Role PrimaryComputer

8

Open the ADFS Management Console and you’ll notice that ADFS03 (our ADFS2016 server) is now primary:

10

Step 2: Run the following cmdlet on all other federation servers in the farm

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName ADFS03.swayit.com.au 

Step 3: Run the following cmdlet on the secondary server to confirm that the ADFS Properties are correct.

Get-AdfsSyncProperties

9-5

Migration Process – ADPREP – Phase 2

Now that we’ve made our new ADFS 2016 Server as primary, it is time to upgrade the schema.

Assuming you had already downloaded Windows Server 2016 ISO file, and if not, you can obtain a copy from TechNet Evaluation Centre.

I performed these steps on the ADFS2016 server:

  1. Open a command prompt and navigate to support\adprep directory.
  2. Type in: adprep /forestprep

1

Once the first step is complete, you will get “The command has completed successfully.”

Next run: adprep /domainprep2

Migration Process – ADFS – Phase 3:

At this stage we had already completed:

  • Adding ADFS 2016 to the existing farm
  • Promoting one of the new ADFS2016 server as primary
  • Pointing all secondary server to the primary server
  • Upgraded the schema

Next phase is to remove the existing ADFS v3 (ADFS 2012 R2) from the Azure Load Balancer (or any load balancer you have in place).

After you have removed ADFS v3 from the load balancer, and possibly from the farm (or simply by having them turned off) you will need to raise the Farm Behavior Level (FBL).

When raising the FBL, any ADFS v3 server will be removed from the farm automatically. So you don’t have to remove them yourself.

When the ADFS v3 servers are no longer part of the farm, I would like to recommend to keep them turned off, should anything go wrong you simply can go back on turning the ADFS v3 servers, make one primary, and in this case you may avoid impacting the business.

If you find yourself in this situation, just make sure everything else is pointing to the ADFS v3.

When you’re ready again, just start from the beginning in adding ADFS 2016 back to the farm.

Here are the steps:

  1. On the Primary ADFS 2016 server open an elevated PowerShell and run the following cmdlet:
Invoke-AdfsFarmBehaviorLevelRaise

12

As you may have noticed, it automatically detected which ADFS servers the operation will be performed on. Both ADFS03 and ADFS04 are ADFS 2016 versions.

During the process, you will see the usual PowerShell execution message:

12-1

Once complete, you will see a successful message:

13

If the service account had failed to be added to the Enterprise Key Admins group, do it manually.

In order to confirm the Farm Behavior Level, run the following cmdlet:

Get-AdfsFarmInformation

14

If you go to https://portal.office.com, and enter the email address of a federated domain, you should be redirected to your ADFS login page:

15

And this is it. You have successfully migrated from ADFS v3.0 to ADFS 2016.

The next post in our series is on Azure MFA integration with ADFS 2016, so make sure to please come back tomorrow to check in details the configuration process.

I hope you’ve enjoyed this post. For any feedback or questions, please leave a comment below.

Category:
ADFS, Identity and Access Management, Office 365, PowerShell, User Experience

Join the conversation! 15 Comments

  1. Great guide. Looking forward to the mfa piece. There isn’t much Microsoft produced documentation on it. Thanks

    Reply
  2. Great guide indeed. Whish there was a step-by-step like this for customers with a single WAF and single ADFS servers.

    Reply
    • Hi mihapecnik,

      The process for upgrading from a single ADFS and a single WAP, is the same. No extra or additional settings or configurations are required.

      However, it is recommended to have at least two ADFS and WAP servers.

      Please let us know if you have any further questions.

      Reply
  3. thanks again
    good stuff

    Reply
  4. […] Part 1 and Part 2 of this series we have covered the migration from ADFS v3 to ADFS 2016. In this series we will […]

    Reply
  5. […] Part 1, and Part 2 of this series we have covered the migration from ADFS v3 to ADFS 2016. In this post […]

    Reply
  6. […] 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 […]

    Reply
  7. My iphone/android apps stopped working after the upgrade, it seems they have changed from ClientTLS to PKeyAuth for mobile apps and that does not seem to work after upgrading.. probably something more that needs to be done but.. missing documentation makes it hard. 😦

    Reply
  8. Hi Daniel,

    This shouldn’t have happened. Could you please provide more details, and maybe we could help you resolve the issue?

    Reply
  9. Hello,

    Thank you for the guide, i’m looking forward to following it next week, when i planned to upgrade the adfs to windows server 2016.

    I do have a question, however. As stupid as this question may be, what happens to users trying to login when the adfs server is being migrated? Should this just work for them and they authenticate against the adfs 2016 as soon as you make the 2016 a primary server?

    Would it be a good idea to de-federating the domain before migrating the adfs?

    Thank you,

    Reply
  10. Hi Nonis,

    If you’re migrating from ADFS v3 to ADFS2016, as mentioned in this guide, the ADFS 2016 will be added to the farm. Afterwards you need to make it a primary.

    Everything will be working as usual, it will have no impact to the business.

    Cheers.

    Reply
  11. Nice step by step, but I’m unclear on the ‘return to FBL 1’ or the 2012R2. Pointing the servers at the 2012R2 won’t do anything, as the databases have all (primary and secondary) been converted to FBL 3 format when you did the ‘upgrade’ to FBL 3/2016. I can’t even see if there is a supported (or any) way to go back without restoring the servers/databases to what they were before the upgrade command was issued.

    Do you have any information on that process? Thanks!

    Reply
  12. Nice Article. i am not able to find migration from WAP 2012 R2 to WAP 2016.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: