Federation Issues after Migrating from Live@edu to Office 365 (part 1)

Have you recently migrated from Live@edu to Office 365 and afterwards federation isn’t working? Can you see Free/Busy of cloud users from on-premises, but not from the cloud to on-premises? If so, you might be using the wrong instance of the Microsoft Federation Gateway. Make sure that your federation trust was moved from the consumer instance to the commercial instance. Johan Veldhuis has a great blog post that tells you how to check your trust and get it fixed.  Read Federation issue after Live.edu is migrated to Office 365 for more info.

OK, That’s the short version of this post. Feel free to read on if you’re interested in my experience with this same issue. Otherwise, thanks for stopping by.

A couple years ago, the university where I work selected Microsoft’s Live@edu service to provide email for our students and alumni.  Last month, the University Live@edu instance was migrated to Office 365.  There were a few bumps during the move, but overall it was a successful transition with one exception. Federation with the on-premises Exchange systems on campus was broken.

Some background:  Before the move to the cloud, student email resided in email systems operated by the individual schools and departments. When the students moved to Live@edu, faculty and staff remained in the on-premises systems. Until we are able to move faculty and staff into Office 365, being able to share information via federation is pretty important.

After the migration was complete, I recreated our federation trust. I had to do this because Live@edu uses the consumer instance of the Federation Gateway by default while Office 365 uses the commercial instance. Afterwards I verified that federation was working with other systems on campus, but was unable to do the same for the cloud.  On-premises users could see free/busy for cloud users, but not vice versa.  After some local troubleshooting, our central IT opened a ticket with Microsoft (love those Premier agreements!), and they quickly identified the problem.

I had assumed, along with everyone else, that the trust for Office 365 would already be setup to use the commercial instance.  It turned out that this was not the case. It was still set to the consumer gateway. Microsoft is going to recreate the trust, and once they do, federation should be back to normal.

If you run the Get-FederatedOrganizationIdentifier cmdlet, you can determine which gateway is being used by looking at the DelegationTrustLink attribute.

We saw the following, which indicated Office 365 was configured to use the consumer gateway.

DelegationTrustLink : WindowsLiveID

This is what we expected to see, which would indicate it was configured fot the commercial gateway.

DelegationTrustLink : MicrosoftOnline

Note that these values are what you will see for your cloud instance. If I run the cmdlet in my on-premises environment, I see:

DelegationTrustLink : Microsoft Federation Gateway.

We all assumed that the trust had been moved, and in hindsight (always 20-20) that should have been the first thing to check. Searching for a relevant blog post had turned up nothing as well, but after Microsoft identified the problem, I quickly found a blog post by Johan Veldhuis describing the same situation. I can’t believe that article didn’t turn up before, but sometimes the search gods are cruel that way. Hopefully my linking to the article will help others find it more easily.

You may remember that this post is only part 1 (check the title).  It turns out there was another problem, one that was specific to my Exchange system. I’ll talk about that next time.