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:

[code language=”PowerShell”]Install-windowsfeature adfs-federation -IncludeManagementTools[/code]

Once complete, follow these steps:

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

Step 2: Connect to AD

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

Step 4: Select your certificate

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).

Step 6: Complete.

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

Alternatively, you could do so through PowerShell:

If you’re using Windows Internal Database:

[code language=”PowerShell”] 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 [/code]

or:

[code language=”PowerShell”]Import-Module ADFS

 $credentials = Get-Credential

 Install-AdfsFarm `

 -CertificateThumbprint:"071E6FD450A9D10FEB42C77F75AC3FD16F4ADD5F" `

 -FederationServiceDisplayName:"SwayIT" `

 -FederationServiceName:"sts.swayit.com.au" `

 -GroupServiceAccountIdentifier:"SWAYIT\ADFSgMSA`$"[/code]

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:

[code language=”PowerShell”]Set-AdfsSyncProperties -Role PrimaryComputer[/code]

 

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

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

[code language=”PowerShell”]Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName ADFS03.swayit.com.au [/code]

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

[code language=”PowerShell”]Get-AdfsSyncProperties[/code]

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

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

Next run: adprep /domainprep.

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:

[code language=”PowerShell”]Invoke-AdfsFarmBehaviorLevelRaise[/code]

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:

Once complete, you will see a successful message:

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:

[code language=”PowerShell”]Get-AdfsFarmInformation[/code]

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:

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.