Migrating ADFS from 2012 R2 (3.0 v) to 2016 (4.0 v.)

Reading Time: 5 minutes

I will explain today how to migrate ADFS from 2012 R2 (3.0 v) to 2016 (4.0) without almost no downtime. The overall process consists in adding the new ADFS server to the farm, assign the primary role to the new ADFS, make some changes and then we’re done.

 

The current environment is:

  • 1 x WAP Server (W2012 R2)
  • 1 x ADFS Server (W2012 R2)

No applications published, just an Office 365 Relying party trust.

A DNS A record that points sts.teselia.com to the ADFS IP address.

 

And the future environment will be:

  • 1 x WAP Server (W2016) -> Not in this post
  • 1 x ADFS Server (W2016) -> In this post

Planning for your ADFS Migration

  1. Active Directory schema update using ‘ADPrep’ with the Windows Server 2016 additions (not necessary in my case)
  2. Build a Windows Server 2016 server with ADFS and join into an existing farm.
  3. Promote one of the ADFS 2016 servers as “primary” of the farm, and point all other secondary servers to the new “primary”.
  4. Change DNS records to the new servers’s IP address.
  5. Raise the Farm Behavior Level feature (FBL) to ‘2016’
  6. Test that the setup works correctly.
  7. Remove the old ADFS server (W2012 R2) from the farm.

Upgrading Schema

Now, time to upgrade the schema of the AD:

Put the installation media from W2016 Datacenter:

Adprep /forestprep

In my case, it was already updated (my domain is in W2012 R2 so it seems that I don’t need it).

 

Installing and configuring ADFS

Once we deployed a new Windows Server 2016 and it’s joined to our domain…

Install the role of ADFS in your target server and then continue with the post-deployment config:

 

Provide can account with Domain Administrator permissions:

 

Provide your federation service name. You can review it in the current ADFS primary server and click Properties in the root folder of the ADFS console:

 

In our case “sts.teselia.com”:

 

Specify your SSL certificate (usually your wildcard):

 

Then, I will use an account (Managed service account recommended):

 

Review your configuration and after the pre-requisite checks proceed with the “Configure” button:

 

After the server is installed you will have some warnings that will be fixed later by rebooting the server and making this new server as the primary ADFS server in the farm:

Then, we will proceed to reboot our server (ADFS01.teselia.com).

 

Configuring as a “PrimaryComputer” in the ADFS farm

Once the machine has restarted, open the ADFS Management Console, and you’ll notice it’s not the primary federation server in the farm.

Open a PS console and execute:

Set-AdfsSyncProperties -Role PrimaryComputer

 

After that, I can access the ADFS console from our new ADFS server without the warning:

 

Execute this on the other ADFS servers (we will point the new ADFS server as the PRIMARY):

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName sts.teselia.com

Then, we will check that in our old ADFS server it’s correct:

Details to bear in mind

So, in my case, I have a DNS A record that points sts.teselia.com to an IP address (the ADFS server)

After pointing the new, I had to modify the hosts file from the WAP server in the DMZ to point to the new server!

Also, I modified the DNS  record from the internal DNS with the new server’s IP address.

 

 

Error with 0365 relying party trust

After migrating the service from ADFS 3.0 (W2012 R2) to ADFS 4.0 (W2016), I faced a  problem when updating the O365 relying party trust.

The solution was to apply a fix described by Microsoft:

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358

Basically, what you have to do is to add a couple of registry values in this new ADFS server because it’s Windows Server 2016 and is running ADFS 4.0 version.

Once you applied the fix, reboot it and works flawlessly!

 

Testing the new setup

To check that it’s really working, try to log into your Office 365 portal and it must show you the portal from your federation service.

As the WAP service isn’t migrated yet, it should respond correctly but if the configuration is not correct, it won’t be able to gather the configuration from the ADFS service.

Removing the old ADFS server

Once you tested that it works correctly, as both ADFS servers will have the configuration replicated, you can remove the role from the old one (that now holds the secondary role) and then remove it from the domain.

With that done, you will have a fresh new Windows Server 2016 ADFS server and none “old” ADFS servers.

 

 

And that’s all, I will do in the future another post about the WAP service migration that it’s easier than this one, I hope that this can help someone.

3 thoughts on “Migrating ADFS from 2012 R2 (3.0 v) to 2016 (4.0 v.)

    1. If you go to the KB shared in the post you will see that you must add these entries (for 32 and 64-bit applications which are the most common):

      HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
      “SchUseStrongCrypto”=dword:00000001

      [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
      “SchUseStrongCrypto”=dword:00000001

      I hope this helps.

Leave a Reply