Office 365 integration now fails - "Cannot connect to Microsoft Office 365" RRS feed

  • Question

  • This server has been integrated with Office 365 for many years with no problems. Periodically when the admin password changes we need to update the admin account within the dashboard on the integration tab. This has also worked for years. Our setup is a simple SBS 2011 installation with around 20 users all with Office 365 accounts (Exchange in the cloud.) The integration service is basically used to keep the users' passwords on the on-premise server synced into the cloud.

    Now when the admin password changed in December, we get an error "Cannot connect to Microsoft Office 365" and thus the sync no longer works. We searched high and low on this one and came across some unsolved threads with similar issues with Windows 2012 Essentials. We've also spent hours on the phone with Office 365 support and they are stumped. 

    We have tried:

    (1) restart the server of course - same error

    (2) change the password of the admin account at Office 365 - same error

    (3) create a brand new admin account at Office 365 and try to use that - same error

    (4) remove and reinstall the Microsoft Online Services Sign-on Assistant - same error

    (5) uninstall the integrate module and then try again from scratch - same error, but now from the startup wizard

    (6) Thought we could forget about this error in the Dashboard panel and just use Azure AD Connect. The application installs but does not let us configure because it indicates it is not compatible with our OS - Server 2008 R2 which is under SBS 2011. So this doesn't seem to be a solution either. 

    We have also examined the log file at C:\ProgramData\Microsoft\Windows Server\Logs\OIMGettingStartedWizard.log which indicates an error but not anything we are able to interpret - here's the log for a single connection attempt:

    [23492] 161227.154433.7278: ProviderFramework: Information: [0] : (current thread: 0x5bc4): Installing new PfSynchronizationContext.
    [13964] 161227.154500.7936: GettingStartedWizard: Start O365 service
    [19604] 161227.154500.9184: ProviderFramework: Information: [0] : Register to listen to ProviderRegistryConnectionMgmt connected event.
    [19604] 161227.154500.9184: ProviderFramework: Information: [0] : ProviderRegistryProxy: Beginning connection attempt.
    [19604] 161227.154500.9340: ProviderFramework: Information: [0] : ProviderRegistryProxy: Creating proxy for AutoReconnecter.
    [19604] 161227.154500.9496: ProviderFramework: Information: [0] : ConnectionMgmt: _CreateChannel address generated = [net.tcp://sbserver:6602//Microsoft.WindowsServerSolutions.Common.ProviderFramework.IProviderRegistry]
    [19604] 161227.154500.9496: ProviderFramework: Information: [0] : GetDuplexChannelFactory()
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : Contract: [Microsoft.WindowsServerSolutions.Common.ProviderFramework.IProviderRegistry]
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : Address: [net.tcp://sbserver:6602//Microsoft.WindowsServerSolutions.Common.ProviderFramework.IProviderRegistry]
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : Binding: []
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : Identifier: []
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : ProviderEndpointBehavior.AllowedConnectionType: [AllowRemoteAccess]
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : ProviderEndpointBehavior.EndpointCredentialType: [None]
    [19604] 161227.154500.9652: ProviderFramework: Information: [0] : RequiredImpersonationLevel: [Identification]
    [19604] 161227.154501.0120: PfBinding: Information: [0] : Adding service dns identity [SBSERVER] in proxy endpoint.
    [19604] 161227.154501.0432: ProviderFramework: Information: [0] : factory impersonation level is: [Identification]
    [19604] 161227.154501.1368: ProviderFramework: Information: [0] : ConnectAsync was NOT able to synchronously connect to the provider registry.
    [19604] 161227.154501.1524: ProviderFramework: Information: [0] : (current thread: 0x4c94): PfSynchronizationContext not needed.
    [19604] 161227.154501.1524: ProviderFramework: Information: [0] : ProviderConnector: Querying for provider info: Microsoft.WindowsServerSolutions.O365Integration.IO365Provider, False, 
    [12128] 161227.154501.2928: ProviderFramework: Information: [0] : _OnConnected called.
    [12128] 161227.154501.2928: ProviderFramework: Information: [0] : _CoreConnected is called.
    [13964] 161227.154501.3864: ProviderFramework: Information: [0] : ProviderConnector: received ProviderInfo Microsoft.WindowsServerSolutions.O365Integration.IO365Provider net.tcp://
    [13964] 161227.154501.3864: ProviderFramework: Information: [0] : ProviderConnector: Beginning connection attempt for Microsoft.WindowsServerSolutions.O365Integration.IO365Provider
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : CreateWithCallback: Microsoft.WindowsServerSolutions.O365Integration.IO365Provider
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : GetDuplexChannelFactory()
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : Contract: [Microsoft.WindowsServerSolutions.O365Integration.IO365Provider]
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : Address: [net.tcp://]
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : Binding: [net.tcp]
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : Identifier: [Microsoft.WindowsServerSolutions.O365Integration.O365ManagementProvider]
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : ProviderEndpointBehavior.AllowedConnectionType: [AllowLocalAccessOnly]
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : ProviderEndpointBehavior.EndpointCredentialType: [User]
    [13964] 161227.154501.4020: ProviderFramework: Information: [0] : RequiredImpersonationLevel: [Identification]
    [13964] 161227.154501.4176: ProviderFramework: Information: [0] : factory impersonation level is: [Identification]
    [19428] 161227.154501.4332: ProviderFramework: Information: [0] : ProviderConnector: Received connection
    [19428] 161227.154501.4488: ProviderFramework: Information: [0] : ProviderConnector: Successfully connected for Microsoft.WindowsServerSolutions.O365Integration.IO365Provider
    [25788] 161227.154502.3380: O365Manager: TResult : Boolean, args : Microsoft.WindowsServerSolutions.Common.ProviderFramework.OperationInvokeEventArgs`1[System.Boolean]
    [25788] 161227.154502.3380: O365Manager: actualArgs : Microsoft.WindowsServerSolutions.Common.ProviderFramework.OperationInvokeEventArgs`1[System.Boolean]
    [25788] 161227.154502.3380: GettingStartedWizard: Activate O365 with Error Communication returned.
    [25788] 161227.154502.3380: GettingStartedWizard: Activate O365 with Error Communication returned.
    [23492] 161227.154502.3536: OIMUtils: GetO365ConfigurationErrorMessage for Communication

    Anyone have a solution to this or other ideas to try to resolve? Now we are left to instruct users to MANUALLY change their Office 365 password after the server requires them to change the on-premise password. A very annoying process when this has previously worked for many years.


    Tuesday, December 27, 2016 9:04 PM

All replies

  • Hi,

    According to your description, my understanding is that O365 is integrated with SBS 2011, when the admin password changed in December, it get an error "Cannot connect to Microsoft Office 365", the sync no longer works.

    The log has recorded error ” GettingStartedWizard: Activate O365 with Error Communication returned.

    Please reference KB 2652021 - The Office 365 Integration Module for SBS 2011 Essentials does not work as expected – to have a further identification on this problem:

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Wednesday, December 28, 2016 5:18 AM
  • Thanks - we have already referenced this article and have performed the following "solutions" from the article and continue to receive the same fault:

    Step 1: OIM setup -> our setup was correct and functioning correctly for years. After a stream of troubleshooting we went through the process to uninstall the OIM and then reinstall. We continue to receive the same fault, but instead of receiving it at the change admin account of the Office 365 tab we receive it from the wizard for setting up OIM.

    Step 2: Troubleshoot -> We are indeed able to access the Office 365 portal using our administrator ID. This is the same ID we use for OIM setup in the wizard (and previously used at "Change the Office 365 administrator account".)

    Step 3: Microsoft Online Services Sign-In Assistant -> There was never a problem here and the service was always running correctly, but as an attempt to solve this issue, we also removed the service and then reinstalled from scratch. None of this helped our fault condition.

    Step 4: Perform OIM tasks in the Office 365 portal -> yes, we can perform all administration tasks in the web portal.

    -- In essence, we only use the OIM for password sync upstream to Office 365. As mentioned in (6) above in our original post we tried to substitute Azure AD Connect for the sync services provided by OIM. When we install Azure AD Connect on the SBS 2011 we receive the error "The installed operating system is not supported." And thus we are stuck without a functioning AD password sync process even though this previously worked for many years. 


    Wednesday, December 28, 2016 4:55 PM
  • Interesting that if we deliberately enter the password incorrectly it tells us that the that the Microsoft Online Service Sign-in ID or password is incorrect. A different message than when the correct password is used. So the correct password actual must be authenticated correctly and then something goes wrong while communicating with the OIM service.
    Thursday, December 29, 2016 4:32 PM
  • Hi,

    We are currently looking into this issue and will give you an update as soon as possible.

    Thank you for your understanding and support.

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Wednesday, January 4, 2017 5:20 AM
  • Thanks - looking forward to a resolution to this problem!
    Wednesday, January 4, 2017 7:41 PM
  • Also today tried to install Azure AD Connect on a spare Windows 10 workstation in the domain - on the recommendation of Office 365 tech support as an interim solution. But, the install always fails with indication that it is not supported. After looking at the prerequisites it appears that the Azure AD Connector must run on a server OS but cannot run on SBS or Server Essentials. So this work-around route seems to have lead to a dead end. 
    Wednesday, January 4, 2017 9:31 PM
  • Hi,

    Thank you for your patience and sorry for my late. 

    As you understand that Azure AD Connect cannot be installed on Small Business Server or Windows Server Essentials. The server must be using Windows Server standard or better.

    Please reference below suggestions and check to see if they are helpful:
    1. Temporarily close the Firewall or other kind of Firewall software. Then check if the issue remains. 

    2. Check and confirm the new created admin account has Office 365 license assigned. 

    3. Remove your custom domain from Office 365. Then re-add the domain in Office 365. 
    After the domain re-verified and re-added successfully in Office 365, then test again. 

    4. Clear the stored Windows Credential from Credential Manger on the SBS Server. Then re-configure the integration. 

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Thursday, January 5, 2017 2:02 AM
  • Hi, 

    This would be the solution for the sync problems or just a temporary workaround? 

    • Edited by GregShore Thursday, January 5, 2017 1:22 PM
    Thursday, January 5, 2017 1:14 PM
  • We have completed this testing and we started with (2) since we thought this might have the best chance of success. For the last 5+ years, the admin account at Office 365 has NEVER had a license assigned as typically the Office 365 admin is a Microsoft Partner and not part of the organization - therefore no point in paying monthly for a license - AND this goes back to the time before it was possible for a partner of record to administer a 3rd party organization. 

    So to test (2), we changed an existing organization user to an Office 365 admin and also to a SBS 2011 enterprise/domain admin. We verified this user could login to Office 365 and perform admin tasks and also perform admin tasks on SBS. This user has an Office 365 license. Unfortunately, we receive the very same error at the beginning of this thread. We also did the deliberate entry of the incorrect password for this user and also got the response from Office 365 that the user ID or password was wrong. So just like previously with our existing admin account, the authentication gets through a first level successfully but then later craps out. 

    We tested (1) but this had no effect on the problem. Again we tried the original admin account and also the promoted user that we changed to an admin with a license. The firewall status on the server does not change the connection error. 

    We tested (4) by clearing everything in the Credential Manager and then trying the OIM connection with the original and the newly promoted user account. Again, continue to receive the connection error.

    We did NOT test (3) above because we are working with a business where the delivery of and access to email is a mission critical process. During the process you describe, there will be email down time and also bounced deliveries which is not acceptable. Also, this process does not seem to have any relationship to the connection error we are experiencing. This test can only be accomplished with your high degree of assurance that it is the solution to the connection error. 

    Thursday, January 5, 2017 6:15 PM
  • I agree with the above. These services are crucial for the daily operation of our users and we can't afford to disable

    its functionality just because of testing purposes. We also did not close the firewall because of the same reason. 

    Friday, January 6, 2017 7:38 AM
  • Hello, 

    we also wanted to migrate to Office 365 and got the same errors with an identical "OIMGettingStartedWizard.log".

    I testet a lot of things and nothing works, even the readding of the domain.

    The integration wizard works fine on a 2016 Std Test-VM with a Server Essentials Environment.

    Monday, January 9, 2017 5:35 PM
  • Hi,

    I am sorry for the late reply.

    For this problem, more further troubleshooting is necessary to find the root cause. I would recommend you submit a service request to MS Professional tech support service so that a dedicated Support Professional can give more satisfying explanation and solution to this issue.

    Global Customer Service phone numbers:

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, January 10, 2017 2:18 AM
  • Hello,

    did this get resolved?  And if so, can the resolution be posted here.  Thank You!

    Tuesday, January 8, 2019 6:12 PM