Tim-3523 avatar image
0 Votes"
Tim-3523 asked ·

ADFS migration from one farm to another

My company own 2 ADFS farms, lets call them and 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.

10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

piaudonn avatar image
0 Votes"
piaudonn answered ·

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.

· 4 ·
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

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:, which basically uses Update-MsolFederatedDomain on the new farm. No idea if that would work though.

0 Votes 0 ·

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:

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

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

0 Votes 0 ·

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?

0 Votes 0 ·
Show more comments