@Richochet_Rabbit I had the same problem way back when... ...Maybe this will help:
When you add Delegation to users, you don't need to share calendars. This causes a problem when you try to offer a sharing setting on top of delegation because both sharing authentications are attempting to authorize the edits at the same time. In Delegation, you are granted access for sharing, with your user, but when you alter the events, you have a choice of whether you are as yourself or the other user you are a delegate for. When both are accessed simultaneously in an active memory under different sharing principle operations, both attempt the edit; the event is pulled from the calendar and opened for editing, but is then locked open. When the system then tries to save, the item is still open, and cannot close. When it times out, and tries to close or the memory is garbage collected, the connection resets and the event is either recovered and reconciled or wiped.
1. Do not combine sharing permission and delegation.
2. Do not keep shared calendars and delegate calendars under the same heading in your outlook (this acts like a folder layer, which is part of the OAuth pathway, and with both in the same path giving different credentials, even for different items in the list, the system may open the items but cannot properly decide which principle has what permission when attempting to close the item.
- This can result in losing or temporarily not seeing events
- This can result in wiping out an entire calendar
Here's my way to do this:
First undo all the delegation and the calendar sharing. Look up how to set up the defaults for each account using powershell. You may have to close and rebuild accounts.
If your situation is similar to a bunch of assistants or receptionist users accessing and altering the calendars for other people, you can do this several ways.
First, you can grant delegation or a share to anybody in a group or AD principle set by sharing calendaring or any other function to that group. This AD grouping gives you the ability to take on principles in Exchange as Delegates, but it is not always functional (some itanium builds don't process this properly and AMD is not guaranteed), so delegation in this way is not supported. However, you can certainly do this by sharing to a group principle.
If you tie the group to a mailbox, there's more you can do later with cloud services. I prefer this method because I can remove users from the shares simply by removing them from the group. You can add the function by adding them to the group.
You can also add the edit capability by setting Delegation per person. Only one principle can be granted delegate access, but there's little difference between a group principle and a user in an AD database, other than the fact that being part of a group checks another box in a user. If an AD principle group is given this, it can be shared by several users. This however isn't supported by microsoft because it doesn't always work perfectly on every on-premises deployment. I cannot stress that enough. It's hit and miss. I would not do this if I could avoid it.
Also, when you are grouping people together this way, you want to map out what each group needs. The cool part is that you can group groups that share an access level. For instance, lets say you have several sets of assistants based on levels of seniority, responsibility, and level of access to the calendars. They all need access to a "Deliveries" calendar\mailbox. By adding the deliveries shares to a grouping called deliveries, then adding the other groups as principles to the group, you can pass the permissions down through. This takes a longer time, sometimes 2 days for smaller groups. The larger the group set, the longer it takes.
So... The best way supported by microsoft:
If a single executive has multiple people acting as his assistant, the best way to share Calendaring is to share only the calendar as necessary to a group principle.
If that executive has one in particular that handles a lot of his communication, they get delegate access, not group access.
This must be mirrored in the cloud if you are in a hybrid mode.
Why I use grouping with a group mailbox:
The group mailbox allows some other functionality in the cloud. You can add some basic automation that puts up tasks on a kanban board using planner, and when the items there are undertaken, this can be communicated to the executive who originally sent it. The mailbox acts like a send-all mailbox. It captures messages and bounces a copy out to the members of the group. The calendar gives them a place where they can all add their own items but not mess with those of others by default. However, a Delegate for the group can be selected (this does not work in group mode for a group ever) who has full access to all the events on the calendar. Alternatively, you could just share the calendar in full to everybody. This results in a set of reception\assistant\secretary staff members who can work together to provide communication services as a group.
Don't Layer Delegation and sharing on the same user. IF you delegate to a user, don't adjust their sharing.
What order should you do this in:
First, apply sharing to all users you want to. When a new user is added, set up sharing first for those services that will be shared only.
Where they need delegate access, grant it.
Before you add the calendars to their lists, first open the delegated account on their outlook. You do this by closing and reopening outlook several times. It may take up to a day for the changes to carry through. Once the delegate is open, you can add other shared calendars under another heading. Make sure delegated calendars and shared calendars are not under the same heading in the same folder in outlook. The folder is given the connection using the OAuth in the path. When the two cross, there are problems. The errors pre-empt the writing of data back to the server which is why the event can get lost or locked out.
