none
Shared Calendars not updating when users are on different Databases and Mailbox Servers RRS feed

  • Question

  • Hi all,

    We have an issue in our Exchange 2013 on-premises environment.

    The thing is that we've deployed two different Mailbox Servers and two Mailbox databases. Users mailboxes are equally distributed between Mailbox Databases (username starting with A-M located to Mailbox1 and N-Z to Mailbox2).

    Everything works perfectly except when the active copy of the databases are on separated Mailbox Servers.

    When both active databases are on mailbox1 or mailbox2 users can see Shared Calendars from  users across all databases with no issue.

    When the active database are on separated mailbox servers, either from OWA or Outlook the messsage "Could not be updated" appears when consulting calendars from users on the other database. Calendars on the same database can be checked with no issue in this scenario though.

    One thing we don't have deployed is public folder mailbox, could this be related to our problem?

    Thank you for your kind help.


    • Edited by ICN2ITDept Tuesday, May 3, 2016 8:31 AM
    Tuesday, May 3, 2016 8:30 AM

Answers

  • We're having this same issue, have a case opened on it. Microsoft seems as dumbfounded as I am. Any update?

    EDIT:

    Microsoft provided this permissions fix:

    Get-clientaccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization", "ms-Exch-EPI-Impersonation" -User "DomainFQDN\Exchange servers"

    Get-mailboxServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization", "ms-Exch-EPI-Impersonation" -User "DomainFQDN\Exchange servers"

    After applying that, and forcing AD replication, calendars started working normally again.

    Not sure how that permission got broken, but this seems to have fixed it for us. If powershell reports that "the appropriate access control entry is already present" for your CAS servers, this is *not* the solution for you.



    • Edited by Chris Kratsch Wednesday, August 3, 2016 1:32 PM
    • Marked as answer by ICN2ITDept Thursday, September 1, 2016 7:09 AM
    Friday, July 8, 2016 5:49 PM

All replies

  • Hey ICN2ITDepart,

    No Public Folders are not needed for free/busy. In Exchange 2013 they use the availability service. Is it perfectly acceptable to have an Exchange 2013 environment without Public Folders at all.

    Possible this sounds like some of the URLs are off. How are you load balancing client access services? I'd recommend running the Synchronization, Notification, Availability, and Automatic Replies test at www.exrca.com and seeing if you get any failures.


    Practical help for Exchange & Office 365 - SuperTekBoy | Twitter | LinkedIn

    Tuesday, May 3, 2016 1:51 PM
  • Hi,

    Thank you for your response.

    We deployed two separated Client Access Servers load balanced by windows NLB service.

    All tests on EXRCA passed successfully without errors nor warnings at all.
    Tuesday, May 3, 2016 2:52 PM
  • Any possible solutions?

    Thanks.

    Wednesday, May 18, 2016 3:00 PM
  • We're having this same issue, have a case opened on it. Microsoft seems as dumbfounded as I am. Any update?

    EDIT:

    Microsoft provided this permissions fix:

    Get-clientaccessServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization", "ms-Exch-EPI-Impersonation" -User "DomainFQDN\Exchange servers"

    Get-mailboxServer | Add-ADPermission -AccessRights ExtendedRight -ExtendedRights "ms-Exch-EPI-Token-Serialization", "ms-Exch-EPI-Impersonation" -User "DomainFQDN\Exchange servers"

    After applying that, and forcing AD replication, calendars started working normally again.

    Not sure how that permission got broken, but this seems to have fixed it for us. If powershell reports that "the appropriate access control entry is already present" for your CAS servers, this is *not* the solution for you.



    • Edited by Chris Kratsch Wednesday, August 3, 2016 1:32 PM
    • Marked as answer by ICN2ITDept Thursday, September 1, 2016 7:09 AM
    Friday, July 8, 2016 5:49 PM
  • Hi Chris,

    Thank you for your response and update. I'll give a try whenever I have availability and will mark as correct answer or report to you otherwise.

    Bests Regards.

    Wednesday, August 3, 2016 9:21 AM
  • I forgot - run that powershell again with a get-mailboxserver instead of get-clientaccessserver.
    Wednesday, August 3, 2016 1:31 PM
  • Thanks for the update, I made the changes on both Client Access and Mailbox Roles and wait for 24 hours but the problem persists.

    It's the AD replication force a mandatory thing or it should work only waiting 24 hours or so like I did?

    Thank you again for your kind help.

    Wednesday, August 31, 2016 6:39 AM
  • We forced replication on ours, and the problem was resolved immediately.

    Surely these changes should replicate to all your DCs well before 24 hours have passed. Check to make sure replication is working properly - and this may not be the solution to your trouble, even though it seems that the symptom is the same.

    Wednesday, August 31, 2016 1:24 PM
  • Thank you for your kind reply. The problem was not solved, I marked your reply as the correct answer thought.

    Maybe in our scenario there's something else blocking this feature.

    Bests Regards.

    Friday, September 9, 2016 6:31 AM
  • Hi ICN21TDept 

    we have the same issue but in exchange 2016.

    Have you fixed the issue? could you share the solution? Thank you so much.

    Wednesday, April 17, 2019 8:04 AM
  • We're having the issue too, probably after adding Exchange Server 2016 servers to our Exchange Server 2013 installation recently but we're not sure exactly when it appeared. Unfortunately the solution above doesn't seem to have helped (even though the permissions were not present on our Client Access servers).
    Monday, May 13, 2019 2:32 PM