Awareness – Is Your Federation Trust Metadata Updated?


Imagine the scenario — all is working well with your Office 365 hybrid solution until you come into the office tomorrow morning and you get calls saying on-premises users are unable to see the free/busy information for mailboxes in Office 365.  While this sounds like a bad dream, this reality could come true tomorrow morning, so let’s to check to make sure that this does not happen!

The background here is that there is a planned change to the Microsoft Federation Gateway (MFG).  A certificate is being updated which means customers with a federation trust to the MFG must refresh their configuration so that they are aware of the new certificate.  While this will affect Exchange hybrid deployments, it will also affect on-premises deployments that have a trust to the MFG. 

Exchange 2013 SP1 systems installed onto Windows Server 2012 will automatically update themselves, but previous versions of Exchange will not.  The same is true for Exchange 2013 installed onto Windows Server 2008 R2.  Either you do this manually or create a scheduled task to periodically do this work for you.  The steps to create the scheduled task are in the link to the planned change. 

 

Update 31-10-2014: Added nuance above to call out that manual work will be needed when Exchange 2013 is installed onto Server 2008 R2.

 

Updating FederationTrust Metadata

The steps to update the MFG metadata are straight forward.  Open the Exchange Management Shell and run:

Get-Federationtrust | Set-FederationTrust –RefreshMetadata

 

In the example below,  the optional –Verbose option was added:

 

Testing Federation Trust

We can use the Test-FederationTrust cmdlet to validate the Federation Trust to the MFG.

 

This is before updating the metadata:

Running Test-FederationTrust Before Updating Metadata

 

After Get-Federationtrust | Set-FederationTrust –RefreshMetadata  was executed this is the result:

Running Test-FederationTrust After Updating Metadata

 

Test CAS User Required To Run Test-FederationTrust Cmdlet

If you have not created the test CAS account to run some of the other test cmdlets or for SCOM, then you will receive the below error:

Couldn't find object "extest_blahblahblahblah". Please make sure that it was spelled correctly or specify a different object

Couldn't find object "extest_4ca5fda1c3994". Please make sure that it was spelled correctly or specify a different object.

This is a test lab with a single mailbox server so I ran the below to create a single test CAS mailbox. 

Get-MailboxServer | .\New-TestCasConnectivityUser.ps1

Note that in Exchange 2010 there is only one extest account per AD site. 

 

Viewing Certificate Details in Federation Trust

Use the Test-FederationTrustCertificate cmdlet to see the certificates:

Test-FederationTrustCertificate

Additionally we can also look at the Get-FederationTrust cmdlet to  see the certificates.  The below screenshots show the certificates before and after updating the Federation Trust. 

Note that in the screenshot below from prior to updating the metadata, the TokenIssuerPrevCertificate  Expires on the 15th of July 2015.

TokenIssuerPrevCertificate  Expires on 15th July 2015

After updating the metadata, the certificates have been changed so that the above TokenIssuerPrevCertificate   certificate has ben replaced:

TokenIssuerPrevCertificate  Expires on 19th November 2018

 

Go forth and update your metadata, if you have not done so already!

 

Cheers,

Rhoderick

Comments (3)

  1. Nice Article !!!
    I guess, we can skip the error for Test CAS user by including -UserIndentity switch to a vaild user
    Test-FederationTrust -UserIdentity

  2. That’s a good point!

    Normally I just create the test account as its needed for other purposes, but that’s just me and how I roll.

    Thanks for adding

    Cheers,
    Rhoderick

  3. anonymouscommenter says:

    Tuto OK The Phantom / ?

Skip to main content