locked
2012 R2 Essentials O365 Password Sync not working (2 AD servers) RRS feed

  • Question

  • Hi,

    As per https://community.office365.com/en-us/f/613/t/294825.aspx

    I have Server 2012 Standard with essentials role enabled on one AD server. I have a second AD server in the environment.
    Essentials dashboard is telling me to reboot both AD servers as mentioned below (this has been done several times).

    I would like to use Essentials dashboard for managing O365, not dirsync. 

    Please help with correcting the problem

    Thanks

    Domain controllers requiring restart

    Occurrences
    02/03/2015 22:05
    Details
    To enable password synchronization between Active Directory and Microsoft Azure Active Directory, you must restart the following domain controllers:
    XX
    YY

    Resolution
    Restart all listed domain controllers.



    • Edited by du5t Tuesday, March 3, 2015 3:49 PM
    Tuesday, March 3, 2015 9:28 AM

Answers

  • Update on this...

    I restarted both my domain controllers.

    On the DC with the Essentials role installed: Within Essentials dashboard, I removed the office 365 service, and then removed the Azure AD service. I then re-added the Azure AD service, and finally the office 365 service.

    I then restarted the DCs... reran the health monitoring scan, and I no longer get this error.

    Tested changing password from a Windows 7 PC, and can confirm that the Office 365 password did update!

    Please try the same process and report back here! :D

    • Proposed as answer by Simon Daniel Monday, May 18, 2015 6:56 AM
    • Marked as answer by RobertPearman Friday, December 4, 2015 12:21 PM
    Friday, May 15, 2015 9:02 AM

All replies

  • It looks like Essentials has pushed the Forefront Password service to both ADs but still the error occurs and password syncs don't work reliably.

    Hopefully someone can help otherwise it looks like I will be taking off the essentials role and using DirSync 

    Wednesday, March 4, 2015 9:35 AM
  • Having the exact same issues but when we try to check the log location the logs don't exist?

    Glad someone else is having an issue.

    C:\ProgramData\Microsoft\Windows Server\Data\settingsproviderdata\PWDSYNCDATASTORE\PASSWORDCHANGEDATA-AZUREAD

    Thursday, March 5, 2015 1:31 AM
  • Yep - no logs, the PWDSYNCDATASTORE directory does not exist

    Hopefully someone from MS can help!
    • Edited by du5t Thursday, March 5, 2015 10:34 AM
    Thursday, March 5, 2015 9:02 AM
  • Hi,

    Would you please let me know whether the August 2014 update rollup was installed in the server 2012 R2?

    Windows Server Essentials integration with Office 365 or Windows Azure Active Directory is blocked

    In addition, please follow the path: %programdata%\Microsoft\Windows Server\Logs and check log files if find some cluse. Please also open Event Viewer and check if find relevant events.

    If any update, please feel free to let me know.

    Best regards,

    Justin Gu


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Thursday, March 5, 2015 10:59 AM
  • Yes all the R2 servers are fully updated

    In logs

    NetworkHealthPlugin-HostedEmailAlerts.log

    [6312] 150301.123513.9317: HostedEmailIntegration:Alerts: Hosted Email Authentication Failed : False

    NetworkHealthPlugin-PasswordSyncAlert.log

    [1644] 150301.123515.5724: PfBinding: Information: [0] : Adding service dns identity [XX] in proxy endpoint.
    [6556] 150301.123527.6766: PasswordSync:Alerts: Password Sync Failed : False
    [1828] 150301.123527.7703: PasswordSync:Alerts: Password Sync Failed : False

    This repeats over and over in both logs

    NetworkHealthPlugin-O365Alerts.log - all seems fine

    In the dashboard no problems with O365 service - everything looks normal

    Which logs in particular would contain useful data?

    Thursday, March 5, 2015 12:29 PM
  • Forgot to say - passwords do sync to O365 if the password is changed by admin in the dashboard, no sync if user changes their own AD password via the usual methods

    I also get these strange events, started after installing essentials role

    ---------

    Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards. No user action is required.  

     DETAIL - 
     18 user registry handles leaked from \Registry\User\S-1-5-21-1391488518-4099733014-3512292719-1111:
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111
    Process 884 (\Device\HarddiskVolume4\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111
    Process 884 (\Device\HarddiskVolume4\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\SystemCertificates\CA
    Process 1520 (\Device\HarddiskVolume4\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Printers\DevModePerUser
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\SystemCertificates\Disallowed
    Process 884 (\Device\HarddiskVolume4\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Policies\Microsoft\SystemCertificates
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Policies\Microsoft\SystemCertificates
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Policies\Microsoft\SystemCertificates
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Policies\Microsoft\SystemCertificates
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\SystemCertificates\trust
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\SystemCertificates\TrustedPeople
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\SystemCertificates\Root
    Process 1804 (\Device\HarddiskVolume4\Program Files\Common Files\microsoft shared\Microsoft Online Services\MSOIDSVC.EXE) has opened key \REGISTRY\USER\S-1-5-21-1391488518-4099733014-3512292719-1111\Software\Microsoft\SystemCertificates\SmartCardRoot

    ---------

    Thursday, March 5, 2015 12:45 PM
  • So it looks like Dirsync is the best way forward?
    Monday, March 9, 2015 8:26 AM
  • Also having the same problem at 3 customers.
    Monday, March 9, 2015 2:33 PM
  • Not good ! Are you going to wait, or switch to dirsync?
    Monday, March 9, 2015 3:06 PM
  • Also experiencing this issue
    Tuesday, March 10, 2015 9:24 PM
  • Anyone have a resolution?
    Friday, March 27, 2015 2:01 PM
  • Nope.

    I even contacted an OEM specialist at Microsoft who had no idea.

    Not good.

    Monday, March 30, 2015 10:27 PM
  • Same issue. I have rebooted the servers several times. It must be an AD permissions issue or something like that. Any one have any ideas?
    Wednesday, May 6, 2015 8:57 PM
  • I've just struck the exact same issue on my latest server deployment. I migrated this customer from SBS 2003 to Windows Server 2012 R2 Standard with the Essentials role installed and Office 365 integration. Password sync isn't working.

    To enable password synchronization between Active Directory and Microsoft Azure Directory, you must restart the following domain controllers:
    <name of server>

    I've rebooted three times already. Sheesh!

    I've performed many 2012 R2 server migrations/new installs the exact same way as this one, but never ran into this issue until now.

    In my case, there's only one domain controller (the SBS 2003 server has been fully decommissioned).
    • Edited by Simon Daniel Friday, May 8, 2015 6:49 AM Added additional info.
    Friday, May 8, 2015 6:46 AM
  • Lot's of people with the issue and no one seems to have an answer, no fix from MS - even Justin who commented above has not replied.

    That's really interesting that even in a single DC setup it's broken :(

    Thursday, May 14, 2015 2:32 PM
  • Update on this...

    I restarted both my domain controllers.

    On the DC with the Essentials role installed: Within Essentials dashboard, I removed the office 365 service, and then removed the Azure AD service. I then re-added the Azure AD service, and finally the office 365 service.

    I then restarted the DCs... reran the health monitoring scan, and I no longer get this error.

    Tested changing password from a Windows 7 PC, and can confirm that the Office 365 password did update!

    Please try the same process and report back here! :D

    • Proposed as answer by Simon Daniel Monday, May 18, 2015 6:56 AM
    • Marked as answer by RobertPearman Friday, December 4, 2015 12:21 PM
    Friday, May 15, 2015 9:02 AM
  • That did the trick. Thanks for the tip.
    Monday, May 18, 2015 6:56 AM
  • I tried this but am still receiving the reboot request. Anyone else have a solution??


    Miles


    • Edited by mrthompson Friday, July 24, 2015 5:42 PM
    Friday, July 24, 2015 1:45 PM
  • Same issue. My domain have 1 primary domain controller SBS 2003 and 1 domain controller W2012R2. Windows Essential Experience is installed on another member server W2012R2. Essentials dashboard is telling me to reboot only SBS2003 server.

    Anyone else have a solution??

    Thursday, August 13, 2015 11:50 AM
  • To answer the question regarding 2003 domain controller still in the environment, my understanding is that this is not supported. I have ran into this with many clients and found that once I decommissioned the 2003 domain controller\SBS server everything worked. I hope this helps others as they come across this issue. 
    Tuesday, November 17, 2015 8:17 PM
  • Ensure that the account you are using to integrate with Azure AD and Office 365 is assigned the Global Admin permission in the office 365 admin console.
    Friday, December 4, 2015 1:08 AM
  • Worked for me. I also ensured that the account used to integrate with Azure AD and Office 365 has 'Global Admin' permissions in the Office 365 admin console.
    Friday, December 4, 2015 1:19 AM