ADFS migration from one farm to another

Tim 21

My company own 2 ADFS farms, lets call them fed1.company.com and fed2.company.com. Both farms run on server 2016 and consist of 2 ADFS servers and 3 WAP servers.

Fed1 currently hosts the RPT for O365, fed2 hosts several 3th party RPT's. The goal is to move the O365 RPT to fed2, and eventually get rid of the fed1 farm.
What steps would I need to perform to move the current O365 RPT from fed1 to fed2?

I have been searching online but the information I found seems to be a bit inconclusive.

2 answers

Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-05-25T20:21:32.633+00:00

I would start by saying that you do not require ADFS for Single Sign On with Azure AD. You can use the Azure AD Connect Seamless SSO option to achieve this. So the easiest way for you might just be to get rid of ADFS for Azure AD workload (such as Office 365).

Now, you can set up the trust on ADFS and update it in Azure AD using the Azure AD Connect wizard. Look at the section Modify the AD FS configuration.
Please sign in to rate this answer.
Tim 21 Reputation points

2020-05-25T20:42:35.513+00:00

Thanks for your reply. Isn't Seamless SSO meant for corporate devices? We have a requirement for O365 apps to be available from non-domain joined devices as well.
In the "Modify the AD FS configuration" article, there is a description on how to add a new AD FS server to an existing farm, but it doesn't describe how to move the O365 RPT from one ADFS farm to another.
I did find this article: https://araihan.wordpress.com/2017/11/21/migrate-office-365-relying-party-trust-to-different-adfs-farm/, which basically uses Update-MsolFederatedDomain on the new farm. No idea if that would work though.

Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-05-26T02:04:50.103+00:00

Seamless SSO is providing SSO for domain-joined devices yes. Non domain-joined devices, or domain-joined devices connected externally (without a line of sight of a domain controller) will do Username/Password in a webform.

But if you don't care care SSO, there is really no reasons to use ADFS at all for Azure AD workloads (unless you fall into a corner case exception like a custom MFA provider or the mandatory use of an attribute store).

That said, if you really want to go ADFS... Update/Add/Replace is pretty much the same thing. You need two things:

Create the trust in the other ADFS (can be done manually, or with the MSOL module - if done with the MSOL module then upgrade the claim rules using this wizard).

Update the trust in Azure AD. That is done with the MSOL module too. Which essentially it is like an update (like suggested in the article you quote).

Tim 21 Reputation points

2020-05-26T08:00:34.037+00:00

We will go with ADFS now as we still use an on-prem MFA server as well, and we still use ADFS for several other RPT's. I will definitely look into your suggestion regarding seamless SSO however.

Regarding the move; would it be sufficient to run convert-msoldomaintostandard on fed1 for each federated domain, than run convert-msoldomaintofederated on fed2 for each domain? Would that re-create the trust both on-prem and in AzureAD, as well as set up the RPT on fed2?
All we would need to do than is clone the current claims rules from fed1 to fed2 for the Office365 RPT, correct?

Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-05-27T03:48:36.817+00:00

Not sure about the convert part. For the rules, yes. You'll have to copy them over. If you use MFA server on prem you might also need to add the -SupportMFA parameter.
Sign in to comment
Gopi Ponnusamy 41 Reputation points

2021-07-05T16:15:44.2+00:00

I would suggest to re-create the RPT to new farm similar to old RPT including claim rules.
then communicate to application owner with new metadata and certificate (if required).
post switch over from app team you can disable/delete the RPT from old farm.

If in case of more RPT then do it in Powershell.

I have performed similar activity (approx. 250+) from 2012 to 2019.

All the best.!
Please sign in to rate this answer.

0 comments No comments
Sign in to comment