Some time ago we built a second ADFS farm at our datacenter. We knew we had to upgrade to v3 at some point, but wanted to keep our v2 farm intact so we could always do a rollback. We also wanted to use a new domain name for our brand new Windows 2012 R2 ADFS cluster, including the WAP proxies.

Setting all this up proved fairly easy, ADFS v3 was operational and externally accessible, if you need to know how, I’d recommend this guide. We only use ADFS for Office 365.

However, when we copied over the claims rules, and pointed Office 365 to our new URL with set-msoldomainfederationsettings, we received an error: 8004789A. We could no longer log in to the portal, but the adfs/ls/IdpInitiatedSignon.aspx page worked fine.

Advanced trace logging proved ineffective, no errors were logged on our side, the issue was likely to be on Office 365’s side. Apparently, copying the default Office 365 Relying Party Trust from ADFS v2 to ADFS v3 is not the best way to switch ADFS farms for your Office 365 tenant and breaks the trust.

We ended up deleting the Relying Party Trust in our v3 farm, then using the MSOL cmdlets to re-establish the trust, with our new farm.

For your reference:

connect-msolservice

set-msoladfscontext -computer [new adfsv3primarynode]

update-msolfederateddomain -domainname contoso.local

The second command connects you with your primary farm member in the new farm, telling the cmdlet which farm to update. The last command retrieves domain configuration from Office 365 and establishes a new Relying Party Trust.