How To Install AD FS 2012 R2 For Office 365–Part 3

Well then, here we are in part three already!  Previously we:

Installed AD FS 2012 R2 For Office 365 in part 1

Installed AD FS 2012 R2 Proxy For Office 365 in Part 2

Now we want to change the Office 365 domain to be a federated domain.  As discussed in part 1, this means that all of the users who authenticate using this domain will become a federated identity and the on-premises AD FS server is responsible for authenticating these requests.

Update 20-8-2014: Added comment for SupportMultipleDomain switch for the Convert-MSOLDomainToFederated cmdlet.

Importance Of AD FS When Office 365 Relies Upon It

Before we discuss the integration of Office with the on-premises AD FS infrastructure, let’s just again be clear on the criticality of ensuring that AD FS is available when the Office 365 domain is set to use AD FS authentication.  For whatever reason if the AD FS infrastructure is unavailable, then Office 365 cannot complete the authentication process and thus users cannot get access to Office 365.  This will cause a service impacting outage that will require resolution from you, not Microsoft’s online services team.

For this reason, unless you really need to leverage AD FS please review the DirSync password hash synchronisation feature in the recent DirSync builds.

Apologies if I sound pessimistic, but I don’t want to obviate the requirement for AD FS redundancy!

AD FS in Azure

On the topic of AD FS redundancy one option is to also host a portion of your AD FS infrastructure in Azure.  This is a perfect solution if you do not have sufficient capacity in your current datacentre, or your datacentres are located in close proximity of each other and a major incident would take both of them down.

There is a whitepaper published for this exact scenario. Please check this link. The documentation covers three main scenarios to meet the situations discussed above:

  • Scenario 1: All Office 365 SSO integration components deployed on-premises. This is the traditional approach; you deploy directory synchronization and Active Directory Federation Services (AD FS) by using on-premises servers.
  • Scenario 2: All Office 365 SSO integration components deployed in Windows Azure. This is the new, cloud-only approach; you deploy directory synchronization and AD FS in Windows Azure. This eliminates the need to deploy on-premises servers.
  • Scenario 3: Some Office 365 SSO integration components deployed in Windows Azure for disaster recovery. This is the mix of on-premises and cloud-deployed components; you deploy directory synchronization and AD FS, primarily on-premises and add redundant components in Windows Azure for disaster recovery.


This is an example of hosting AD FS in Azure for DR purposes:

Hosting ADFS In Azure For DR Purposes



AD FS is supported for deployment on Azure Virtual Machines, but there are AD FS best practices that require technologies beyond what AD FS offers itself, such as load balancing/high availability.  In addition to this please also consider the pricing for running this IAAS.  Read through the deployment caveats in the AD FS Azure documentation above and also the additional discussion points here.

Updating AD FS

Back to the business at hand – updating Office 365 so that it now uses your on-premises AD FS server!

In the previous posts we reviewed the required pre-requisites.  One to circle back on was that the AD FS servers will require Internet access to complete the configuration with Office 365.  This will require outbound access on HTTP and HTTPS using ports TCP 80 and 443 respectively.  If this is not open, then you will receive an error.

We will run the below on a domain joined server on the corporate network.  This has the Windows Azure Active Directory PowerShell Module and the Microsoft Online Sign-In Assistance (SIA) installed.  Let’s launch the WAAD PowerShell module.  For reference the remote AD FS server is

For other WAAD management tasks, take a peek at Manage Azure AD using Windows PowerShell page.

Using Connect-MsolService let’s connect to our WAAD instance.  Provide a set of global admin credentials:

Connecting to Windows Azure Active Directory

We can see the current status of the domains within this tenant.  the Get-MsolDomain cmdlet will show the domains, and we are interested in the first domain – “”.

Reviewing Starting Domain Status

Before we can execute the Convert-MsolDomainToFederated cmdlet, we need to also a hook into the local AD FS server (not the AD FS proxy) so that we can configure it.

There is a word of warning here, as chances are that you will see this lovely screen that features copious red text.

Set-MsolADFSContext : The connection to <ServerName> Active Directory Federation Services 2.0 server failed due to invalid credentials.

The connection to Active Directory Federation Services 2.0 server failed due to invalid credentials

This is caused by Remote PowerShell not being enabled on the remote  AD FS server.  This is an issue that is present on AD FS 2012 and AD FS 2012 R2 servers amongst others.  Thankfully it is quite easy to fix, by running the below on the AD FS server:


Once Remote PowerShell has been enabled, we can then connect to the AD FS server using the Set-MsolADFSContext cmdlet. Like the other MSOL cmdlets, this one is as unforgiving.  If you forget to explicitly use the required parameters the MSOL cmdlets typically do not prompt like the Exchange cmdlets do.  Because of this I have a habit of always specifying every option and not relying on PowerShell to prompt for required options that were missed.

Once we have connected to the AD FS server, we use the Convert-MsolDomainToFederated cmdlet to convert the Office 365 domain from Managed to Federated.

Set-MsolADFSContext -Computer

Convert-MsolDomainToFederated -DomainName


Update 20-8-2014:  Andy pointed out in the comment that there is an area of concern to be noted here for customers that have multiple top level domains.  Back with early AD FS 2.0  builds customers with multiple top level UPNs had to deploy separate AD FS instances for each domain suffix.  A rollup was added to assist with this and the SupportMultipleDomain switch.   Please see here for more details if you have multiple sign on domains.


Once converted, we check to see if the change applied:

Converting Domain To Federated

Yes it did!  The domain is now Federated.

The full properties of the domain now look like so:

Viewing All Details Of Converted Domain

Please be aware that it can take up to two hours for domain authentication changes to apply.  Go drink a vat of coffee or play some flappy birds!

Testing Access To Office 365 OWA

To test that we are being authenticated to Office 365 OWA via AD FS, let’s see what happens now that the domain has been converted to federated.

Open IE, and navigate to  this is the neat shortcut that we can use to access OWA.  Change the domain name to match your own.

When we go to  the browser is redirected to our on-premises AD FS server, at this URL:

We then sign in to the on-premises AD FS server:

To On-Premises ADFS Server

AD FS authenticates us, assuming that the password is not fat-fingered, and this authorises Office 365 to let us access OWA:

Signed In To OWA - What A Glorious Sight -- No EMAIL !!

The astute reader will notice that IE in-private mode has been used.  This keeps my testing separate from the other IE Instances running on my laptop.

One thing to note, when testing this connectivity please do so on a regular client machine that has the proper access to the Internet and where the browser is not totally locked down.  In the below example on a Server 2008 R2 SP1 server, when browsing to the user experience is very different from the screenshots above.

ADFS Redirection Experience When Testing On A Server

The user will get logged on, but it can be disconcerting if you are expecting the sexy looking AD FS screen and you get an auth prompt instead…..

ADFS Redirection Experience When Testing On A Server


Testing Office 365 SSO

Chances are you will have use the site to test and troubleshoot on-premises issues.  The tool has been expanded as now we can also use it to test and diagnose Office 365 issues.

Office 365 Test Connectivity Website

KB 2650717  How to diagnose single sign-on (SSO) logon issues in Office 365 by using Remote Connectivity Analyzer  discusses using the tool to validate SSO.

BONUS TIP – if you get tired of typing that long URL to get to the site, try


Viewing the SSO Shuffle

Using the IE developer tools, that are accessible by pressing F12 we can see the traffic flow that the browser has taken to reach the sites involved.  You will want to click to enlarge the below.

using IE Developer Tools To View SSO Traffic Flow

Note that we went to the following URLs.  Can you work out why there are three ones at the top?



Repairing Office 365 Federated Domain

As discussed in KB 2647048, there are situations that will require the Office 365 domain federation to be repaired.

  • 2523494 (You receive a certificate warning from AD FS when you try to sign in to Office 365, Windows Azure, or Windows Intune
  • 2618887 Error when you try to configure a second federated domain in Office 365: "Federation service identifier specified in the AD FS server is already in use."
  • 2713898 "There was a problem accessing the site" error from AD FS when a federated user signs in to Office 365, Windows Azure, or Windows Intune
  • 2647020 "Your organization could not sign you in to this service" error and "80041317" or "80043431" error code when a federated user tries to sign in to Office 365
  • 2707348 "Metadata Exchange (MEX) document received from AD FS contains an unknown WS-Trust version" error after you run the MOSDAL Support Toolkit
  • The Federation Service name in AD FS is changed. For more info, go to the following Microsoft website: AD FS 2.0: How to Change the Federation Service Name

For example, you may find yourself running this:

Updating MSOL Federated Domain


Additional Reading

I love this KB as it links to so many other articles that are relevant and introduce many of the issues that can arise with an AD FS deployment.

KB 2647048 -- How to update or to repair the configuration of the Office 365 federated domain

The PFE Platform blog have some great AD FS content, amongst other things.  Just don't propose to Charity via the comment system please!

How to Build Your AD FS Lab on Server 2012 Part 1

Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature

Upgrading AD FS to Server 2012 R2

FAQ on AD FS - Part 1

Finally the TechNet Wiki has the AD FS content section.

AD FS Content MAP




Comments (47)
  1. anonymouscommenter says:

    In part one we installed the ADFS server on our corporate network, and tested that it was working. Now

  2. anonymouscommenter says:

    Thanks a lot
    very helpfull

  3. Shakthiravi says:

    Thanks for the Great post Rhod, Excellent walkthrough … 🙂

  4. Brad_Voris says:

    I am really glad you wrote this article. I have to implement ADFS for office 365 in the next few months.

  5. Thanks for the feedback guys!

    Brad – do let us know how you get on with the deployment!!

    I also have another post coming up that you will love – please subscribe to the RSS feed. I’ll probably publish it on Monday.


  6. anonymouscommenter says:

    When discussing and reviewing Office 365 with customers, I wanted to have a series of posts to illustrate

  7. anonymouscommenter says:

    Great work one of the best worked articles I have ever read. One question is around firewall rules for the internal ADFS to the DMZ WAP is only port 443 required between the two servers? Is this bidirectional or one way only?

    Thank again

  8. Good question Techno 🙂

    The firewall stuff is in here

    But does not state the direction. I’ll see what I can locate….


    1. Phil Martin says:

      Hi Roderick, any update on the direction of port 443? Is it bidirectional?



  9. anonymouscommenter says:

    Hi Rhoderick, my users were able to login to the Office 365 ADFS 2.0 with username (ABC)and password without using (FQDN) However, when I upgraded my ADFS farm to Windows Server 2012 R2, the Office 365 ADFS 3.0 login page does not allow users
    to use username login (abc) rather it ask to enter or domainusername.

    How can i fix this issue ?

  10. anonymouscommenter says:

    As far as the user experience, what happens if they already have the same password in outlook for Office 365 as AD? Immediately after federated, will they be prompted for their password through outlook? Or will outlook continue to login without prompt?

    This would happen if already using dir sync with password sync enabled and adding ADFS.

  11. anonymouscommenter says:

    Outstanding how to article!!! Allows anyone with decent skills to install and understand.

  12. anonymouscommenter says:

    Thank you! Very helpful blog! Tell me please if SSO should work during autoiscover (when outlook is adding profile), because this is only place where I am asked for password?

  13. Mark and Andrej – Outlook is trying to do basic auth. So this will present the password prompt, which is the reason for the recommendation to save credentials else users get bored of the enter password game….

    As long as the right creds are saved in there it should not prompt, but I’m just back from 3 weeks of holiday and brain is still warning up….


  14. Puneet – Not something I’ve looked at since I always use the for all auth purposes.


  15. anonymouscommenter says:

    Used this awesome guide a few times when installing ADFS/WAP, to ensure I don’t miss anything – can I suggest that you point out the -SupportMultipleDomain parameter of the Convert-MSOLDomainToFederated cmdlet, as not specifying this when converting can
    be a pain to undo.

  16. Good point – I’ll add a wee note to that Andy!


  17. anonymouscommenter says:

    Nice guide with lots of good info in it. A quick question – are there any guides for migrating from ADFS 2.x on Windows Server 2008 R2 with Office 365 over to Windows Server 2012 R2 with ADFS 3.x?

  18. Hi Joshua,

    There are a few blogs that deal with the platform aspect of this – I have something in draft but not yet finished yet!


  19. anonymouscommenter says:

    We have a Student Office pro license as well. My question is if we stick to Same Sign On scenario where password hash is synced to windows azure AD, will students be able to license desktop apps? such as Onedrive desktop app and Lync?

  20. Shouldn’t make a difference Farzan – as long as their subscription has the proPlus feature and they can sign-in to activate it they should be good to go.

    Are you seeing something different?


  21. anonymouscommenter says:

    Happy New Year!

    I have a question relating to a merging of directories. In my situation I inherited an organization who created a Office 365 Environment but thought it was to much work to federate so they operated both directories independently. I would like to federate and
    have SSO and central management of a single AD environment. Could I still follow your 3 Step process?

    Thank you!


  22. Hi Dave,

    if I’m understanding you correctly so that you have a tenant where DirSync was not comfigured and uses cloud identities only then you can use the soft match feature to hook the two up.


  23. anonymouscommenter says:

    Using the standalone, workgroup WAP server to connect to Azure AD, I was still getting the credentials error when executing the Set-MsolADFSContext command, despite enabling PS Remoting on the ADFS server. In order to get the command to work, I had to
    add the ADFS server as a PowerShell remoting trusted host on the WAP server. Eg. I executed this on the WAP (workgroup) server
    winrm s winrm/config/client ‘@{TrustedHosts="ADFSSERVER"}’

    It seems counterintuitive to tell the server where you’re executing the command from (in my case, the WAP server) to trust the other server (the ADFS server) but that’s what I did to get the Set-MsolADFSContext command to work.

  24. anonymouscommenter says:

    This is a link throw-down for the items that we discussed during a recent Office 365 workshop that I

  25. anonymouscommenter says:

    Hi great article … in "Scenario 2: All Office 365 SSO integration components deployed in Windows Azur|" is there any recommendation on what tier + instance from the Azure pricing calculator should be used to cost the VM’s required for the presumably
    6x minimum VM’s required ….

  26. anonymouscommenter says:

    I’m on the my 3rd iteration of my EMS lab. Meaning, I had something up and running (twice) then tore

  27. anonymouscommenter says:

    Converted my domain to "Federated" successfully. When I go to login page and enter my credentials, it gives me "incorrect user ID or password." And, actually, if I were to try to login to ADFS page (via WEP) I receive the same thing. Any thoughts on what
    I can check?

  28. Rocky – start with the app logs on the Proxy and ADFS server(s).

    Is AD replicating to all DCs with no issues?

    Also try resetting the password for the test account.


  29. anonymouscommenter says:

    Very nice article, thanks a lot for posting it

  30. anonymouscommenter says:

    Hi, I currently have AAD Connect and hybrid configuration setup with O365. Can I setup ADFS on a separate server in the same domain, and establish its own federation trust with O365 to "test" it out, without interfering with the existing aad connect sync?

  31. Steve says:

    Hello, I presume if we have CRM as part of our Office 365 purchase this will also work with SSO / ADFS etc. But, I am tempted by DirSync it just feels better. As we move more ‘stuff’ to the cloud ADFS will be adding less value. Thanks

  32. Andrew says:

    Hey Rhoderick,
    Thank you for these blog posts, they have helped me immensely in setting up my hybrid Exchange test lab. I did run into an issue whereby the relying party Trust was missing so the OWA sign on was not working. The WAP server was working correctly and I could authenticate to ADFS externally. The internal ADFS server did not have an Internet connection and such the relying party Trust was not present. To fix this I presented an internet connection to the ADFS server and ran the following command:
    update-msolfederatedDomain -domain

    Upon refreshing the relying Party trust the “Microsoft Office 365 Identity Platform” is now listed and OWA sign in is now working with the on Prem credentials.

    Just thought I would post in case anyone else this issue. Now onto setting up the Exchange Hybrid Connection!



    1. Thanks for the feedback Andrew – I’ll add that as a note as well since some folks may not parse the comments immediately.


  33. Harold says:

    I’m curious about this sentence: “For this reason, unless you really need to leverage ADFS please review the DirSync password synchronisation feature in the recent DirSync builds.”

    When do I really want to leverage ADFS and when is DirSync the way to go?

    1. Harold says:

      Never mind, this answers my question:

      Based on that article I think most of my customers will choose for Federated because they already have ADFS en because of SSO (Windows Authentication) on local network and MFA on external networks.

      Developer question: I’m wondering if the examples at will work with federated authentication?

    2. For the reasons in the other link that you added Harold. AD FS will provide benefits to most enterprises, but you must be cognisent of the requirements and what it means if AD FS is unavailable. Hence the password hash sync is th starting point for discussions.


  34. Klaus Lingskov says:

    Thank you very much for all 3 parts!

  35. Mhyar says:

    Where did part 2 go!!

    1. Thanks! Have updated the link.

      The permalink was point to the wrong place, the content was there on the full path:

      And also via the tag cloud on the right hand side.


  36. SJMiller says:

    Thanks for the great walk through. My situation was a standalone AD FS 2.0 server and old DirSync. I found out that there is no way to upgrade 2008 AD FS 2.0 to 2012R2 AD FS 3.0 the hard way. That being said, I followed your part one and part two to where I am now. I Got my Azure Connect, ADFS Server (same box) and Proxy Server (seperate box in DMZ) up and running perfectly but my AD FS 2.0 server is still controlling my logins. I can change my DNS and firewall and point to my 2012R2 server. However, my relaying party trusts have not been altered yet. I didn’t follow your part three as my federation is not being converted – that already happened when I installed 2008 AD FS 2.0. I believe that I just have to update my relaying party trusts. Am I correct? How do I do that? The upgrade path for a multi server AD FS 2.0 setup to the AD FS 3.0 server setup had a configuration export and import option. That won’t work for me as I was single server.

    1. The configuration import/export just for Office 365 does not really apply here.

      Just re-run the Azure AD module and connect to the new primary AD FS server. Then update the MSOL domain information.

      (On holiday so will not be quick to reply)

      1. SJMiller says:

        Thank you. I didn’t see your reply here right away and I did figure this out. Everything is up and running. I was just uneasy running the msol convert when the domains were already listed as federated. After I ran the convert and the update, externally I got the correct Login pages but when I entered my creds it just refreshed the page asking for me to login again. This was kinda unnerving. As it turns out (and even though you stated this in your blog I didn’t remember this) I just had to wait a few minutes. Then it all started working.

        In turn, it didn’t break anything so all was good. Thanks again. You three blogs helped me.

        1. Yay ! 🙂

          Thanks for circling back on this!

Comments are closed.

Skip to main content