No one has responded to this discussion for at least a year, so this information may be out of date. If you're looking for information about this topic, please search for a more recent discussion or post a new question.

Hybrid Deployment - Creating Relying Trust Step

This question is not answered This question is not answered

I am currently deploying a hybrid deployment using SSO. We currently have an Exchange 2010 SP2 infrastructure.


- I have my 2 AD FS 2.0 servers deployed using existing DC's

- I have my 2 AD FS 2.0 Proxy servers deployed using 2008 R2


I'm at the point of installing Powershell to create the relying trust, and I have some questions.


Should this be deployed on my "primary" AD FS server, or a Proxy, or both?

What's the differance between "Adding" and "Converting" my domain to be SSO?

Depending on the difference of these, will there be any downtime for my existing user's? I only plan on moving some test mailboxes initially to see how everything works.



All Replies
  • You would first login online and add your domain, then add a TXT record in your public DNS and verify it. Once you have that done, you would login to the admin panel online and migrate mailboxes. Manage My Organization -> Users & Groups -> E-Mail Migration

    This would bring you to having mailboxes migrated and update every 24hours between your local Exchange and Exchange Online.

    Once you are in the process or have completed the migration process, you need to add licensed mailboxes to each user before the grace period ends.

    Once you have done this, you can login online and check the migrated emails, contacts, calendars, email settings etc.

    If everything looks good, you can continue with configuring the SSO.

    After you federate your domain, the following will happen:

    Users will go to and enter their email address. The website will then recognize that your has been federated and prompt the user to click on a link which will redirect the user to your ADFS Proxy website.

    Note that if this is not setup properly, user will not be able to login.

    You can setup and test all this without interfering with your users.

    The cut over happens when you point your public MX record from your local server to microsoft server. All the emails will be delivered to your Exchange Online and users will need to login online to access their emails.

    Powershell should be installed on the primary ADFS

    Adding a domain referes to you adding it into Exchange Online

    Converting a domain referes to when you federate the domain

    I recommend that if you do not have many users, that you skip SSO. To propely have SSO and give your users the best availability, you need to put up network load balanced servers, minimum 2 for ADFS and 2 for ADFS Proxy.

    Good Luck

  • Thanks for your response. I think what you're describing is a cutover migration. We cannot do a cutover migration, as there's no way we can recreate 300+ Outlook profiles, which is required with a cutover migration. We have to do hybrid migration for that simple fact.

    The TXT record has already been added to our external DNS, and our domain verified with Office 365. With over 300 users, we felt SSO was a good option for us. I have 2 AD FS servers and 2 Proxys, using Round Robin DNS instead of NLB's.

    Any more insight in regards to my initial questions and given that we are planning for a Hybrid migration?

  • There is no such thing as hybrid migration, what you are thinking of is a staged exchange migration which will only work if you do not have exchange 2010 mailboxes.

    If you are going to use Hybrid deployment and then move mailboxes, here is a good article that will describe the move of mailboxes.

    Your initial questions:

    Should this be deployed on my "primary" AD FS server, or a Proxy, or both?

    - There is a relaying trust between ADFS Proxy and ADFS that you create when you run the wizard on the ADFS Proxy.

    - There is also a 'trust' when you connect via powershell to Exchange online and run the federation. This is done on the primary ADFS.

    What's the differance between "Adding" and "Converting" my domain to be SSO?

    - Since you did add and verify the domain, then your 'Adding' is done.

    - Converting domain:

    "When you convert an existing domain to a single sign-on domain, every licensed user will become a federated user, using their existing Active Directory corporate credentials (user name and password) to access services in Office 365. Performing a staged rollout of single sign-on is not currently possible; however, you can pilot single sign-on with a set of production users from your production Active Directory forest."

    Depending on the difference of these, will there be any downtime for my existing user's?

    - No, unless something goes wrong...

    Good Luck

  • Hello Brad126,

    I understand that you want to deploy SSO and have some questions about deployment.

    For the first question:
    The cmdlets are recommended to be run at primary ADFS server in PowerShell. After the trust is built up, running these cmdlets is not necessary to run at ADFS proxy server.
    Moreover, does “I have my 2 AD FS 2.0 servers deployed using existing DC's” mean that you have installed ADFS to 2 DCs? If so, it isn’t recommend to install ADFS at DC directly.

    For the second question:
    Generally, converting is to convert an existing custom domain added to Office 365 from Standard to Federated (sign in via SSO).
    Adding is to add a new Federated domain. For example, once you have converted a top-level domain, such as, you must use New-MsolFederatedDomain cmdlet to add a sub-domain, such as for SSO.

    For the third question:
    Generally speaking, if the users are using Office 365 services continuously, since the authentication method is changed, there will be a short down time. As a result, it is recommended to deploy a test environment first for testing these potential issues.


  • This completely contradicts Microsofts recommended deployment with less than 1000 users.

    "For the federation servers, use two existing Active Directory domain controllers (DCs) and configure them both for the federation server role. To do this, first select two existing DCs, and then:

    Install AD FS 2.0 on both domain controllers.

    Configure one as the first federation server in a new farm.

    Join the second one to the federation server farm."

    As for the 3rd answer, when will this downtime occur? All I'd like to do at this point, is complete the trust between the AD FS server, and sync AD to Office 365. All 300 of my users are still active at my on prem Exchange 2010 infrastructure, and all mailboxes still reside on prem. Shouldn't the only interruption come when I get to the shared namespace step or repoint my MX record?

  • Hello Brad,

    If you are still having issues deploying your hybrid servers, I would recommend contacting a Microsoft Partner who specializes in ADFS hybrid setups. You can also contact Office 365 tech support by phone and they can escalate your service request to the ADFS deployment support team.

  • Hello brad126,

    Please advise whether this thread can be close. If you still have additional questions or concerns, please let me know and I will continue assist as needed. I look forward to hear from you soon.


    Best regards,

    Roger MSFT Support

  • Hi brad126

    How are things going? Did we answer your question to your satisfaction?

    If you have any other questions or concerns, please do not hesitate to contact us. It is always our pleasure to be of assistance.