Forum Discussion
Can't make a goup calendar readonly anymore with Powershell
Hi, We have some groups where regular group members are not allowed to make changes to the group calendar. I was able achieve this with Powershell as described in this post: Calendar permissions i...
Hello! Did you ever get any answers for the "strange behavior"? I am seeing similar issues where OWA respects the read-only flag, but desktop clients (Outlook for Mac and Outlook for Windows) allow entries and modification of events, but such edits don't write back to the Group Calendar and stay local to the user.
I'll reply to my own question since I got a decent explanation of why this is happening:
The behavior you’re experiencing with the M365 Group calendar is due to the way Outlook for Mac and Windows handles calendar permissions and caching compared to Outlook on the web (OWA).
When you set a group calendar to be read-only using the PowerShell command Set-UnifiedGroup -Identity “GroupName” -CalendarMemberReadonly, this permission is enforced directly on the server side. Outlook on the web (OWA) interacts with the server more directly and in real-time, which means it will immediately respect these permissions.
On the other hand, Outlook for Mac and Windows clients maintain a local cache of the mailbox and group calendar data. When a user attempts to create a new meeting in the group calendar, the Outlook client allows this because it doesn’t immediately check the server for the current permission level. The meeting appears to be created successfully and is visible to the user because it is temporarily stored in the local cache.
However, since the group calendar is actually set to read-only on the server, these changes are not synchronized back to the server, and therefore other users do not see them. The user who created the meeting also cannot modify or delete it because the server does not grant write permissions to the calendar.
Once the user restarts Outlook, the client re-syncs with the server, the local cache is updated, and any non-synchronized items that are not permitted by the server permissions (like the meetings created in a read-only calendar) are removed.
This discrepancy between the client-side behavior and the actual permissions set on the server is why you are seeing this behavior. It is essentially an issue with the Outlook client not immediately reflecting the server-side permissions until a re-sync occurs.
To address this, you might want to inform users about this behavior so that they understand that any entries they make in the read-only calendar on their Outlook client will not be saved and will disappear after a restart or re-sync. Unfortunately, there isn’t much that can be done on the user’s end to change this behavior, as it’s a limitation of how Outlook clients handle group calendar permissions and caching.
The behavior you’re experiencing with the M365 Group calendar is due to the way Outlook for Mac and Windows handles calendar permissions and caching compared to Outlook on the web (OWA).
When you set a group calendar to be read-only using the PowerShell command Set-UnifiedGroup -Identity “GroupName” -CalendarMemberReadonly, this permission is enforced directly on the server side. Outlook on the web (OWA) interacts with the server more directly and in real-time, which means it will immediately respect these permissions.
On the other hand, Outlook for Mac and Windows clients maintain a local cache of the mailbox and group calendar data. When a user attempts to create a new meeting in the group calendar, the Outlook client allows this because it doesn’t immediately check the server for the current permission level. The meeting appears to be created successfully and is visible to the user because it is temporarily stored in the local cache.
However, since the group calendar is actually set to read-only on the server, these changes are not synchronized back to the server, and therefore other users do not see them. The user who created the meeting also cannot modify or delete it because the server does not grant write permissions to the calendar.
Once the user restarts Outlook, the client re-syncs with the server, the local cache is updated, and any non-synchronized items that are not permitted by the server permissions (like the meetings created in a read-only calendar) are removed.
This discrepancy between the client-side behavior and the actual permissions set on the server is why you are seeing this behavior. It is essentially an issue with the Outlook client not immediately reflecting the server-side permissions until a re-sync occurs.
To address this, you might want to inform users about this behavior so that they understand that any entries they make in the read-only calendar on their Outlook client will not be saved and will disappear after a restart or re-sync. Unfortunately, there isn’t much that can be done on the user’s end to change this behavior, as it’s a limitation of how Outlook clients handle group calendar permissions and caching.
