Microsoft Office 365 Troubleshooting Guide Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.

Microsoft Office 365 Troubleshooting Guide

Oct 08, 2015 | by Thomas Hill in Office 365

Original Author: Sophia Yang, Okta,  Edited By Stephen Lee, Okta

Microsoft Office 365 Troubleshooting Guide


Q: Can I run Directory Synchronization tool on-demand?
A: Yes.  Load the "C:\program files\Microsoft Online Directory Sync\DirSyncConfigShell.psc1", when the console loads, run the Start-OnlineCoexistenceSync cmdlet.  This cmdlet will return results when it has started a sync cycle.

Q: Can Directory Synchronization be installed on a domain controller?
A: No - this is because SQL Server Express is not supported on a domain controller.

Q: Can Directory Synchronization be installed on a 64-bit machine?

A: Yes. See Directory Synchronization tool 64-bit support.

Q: Where do I find information about downloading and installing the Directory Synchronization tool?
A: Go to Install the Microsoft Online Services Directory Synchronization tool.

For more info on above questions:


Q. Why does it give error when federating the domain - You cannot federate the default domain?

    fed error.png

A: You cannot federate a domain marked “Default”, so make sure to change the domain your are federating to a non-default one and rerun the Powershell script to federate your domain.

This behavior is by design. Executing the Msol Federate cmdlet will result in an error referencing replacing the default domain.  This error will occur if the customer has changed the default domain to be something other than the "" administrative tenant. Customers seem to think that their real domain has to be the default domain.  It does not and should not.  This impedes the success of WS-Federation.

The solution is to login to the MS Online Services Portal and click on the domain link above the Admin Overview header.  This brings up the "Edit Company Information" window.  Select the "Default Domain" dropdown box and choose the admin tenant to be the default domain. Click Ok.  Re-run the PowerShell federate cmdlet and it should now instantly succeed and return you to the PowerShell prompt. You will now not get any errors and the WS-Federation has occurred in the background as expected.


Q. How to know what Federation endpoint, Office 365 is connected to ?

A: Check Get-MsolDomainFederationsettings against Office365 tenant to know the parameters and it tells you if all the parameters are switched. The figure shown below shows it is connected to Okta org with all the endpoints:

       set-msol settings.png

Q: Can we federate two endpoints for Office 365?
A: No.

Q. How to remove the federation endpoint?

A: Use Convert-MsolDomainToStandard -DomainName <string> -PasswordFile <string> -SkipUserConversion <Boolean> [-Confirm] [-WhatIf] [<CommonParameters>]

Few caveats worth mentioning though:

To use Convert-MsolDomainToStandard cmdlet to revert their office365 domain to standard authentication. This would be a "Back Out".

The Convert-MsolDomainToStandard requires a string value attribute called PasswordFile.  This is because when you "undo" or "back out" Office 365 single sign on, the users necessarily have to be given passwords again.  The command automatically generates a temporary password for the users and PasswordFile is the file where the PowerShell script stores all the standard authentication users (newly converted from being WS-FED users) temporary passwords for distribution.  ALL the users in a domain would have new temporary passwords and they would be found here unless the SkipUserConversion flag has been used as well.

Yes, when you run Convert-MsolDomainToStandard users HAVE to be handed out their new passwords from this file. The passwords are set randomly to make your life more enjoyable.

SO, This is not a function that you would normally do during the middle of the day or at night during a random outage window without proper planning because the users have to be able to get their temporary passwords and email won't be a good way to distribute this since Outlook is going to say it needs credentials again..

So undoing WS-Federation in Office365 is not as simple as federating it.

...would never recommend to undo the federation without a change control filed and in that change control have a plan with documented steps to be able to distribute the temporary passwords.


Reference for the associated MS documentation on this Powershell Commandlet.