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: https://answers.microsoft.com/en-us/msoffice/forum/all/calendar-permissions-in-an-office-365-group/b5f7cacc-bc11-4b8c-adf1-e94f11616ae2#:~:text=Below%20are%20the%20steps%3A%201%201.%20Connect%20to,command%20to%20check%20the%20CalendarMemberReadOnly%20in%20this%20group.
More info about the Set-UnifiedGroup command is found here: https://learn.microsoft.com/en-us/powershell/module/exchange/set-unifiedgroup?view=exchange-ps
All of a sudden I now am only able to read the settings and can't change them anymore. So this still works:
Get-UnifiedGroup -Identity "MYGROUP" -IncludeAllProperties | Format-List *Calendar*
But this gives an error:
Set-UnifiedGroup "MYGROUP" -CalendarMemberReadOnly
The error is:
Write-ErrorMessage : Object reference not set to an instance of an object.
The strange thing about this, is that I am able to change other attributes, like:
Set-UnifiedGroup -Identity "MYGROUP" -AccessType Private
I use an account with Global Admin rights to execute the commands and we have an educational tenant. What is going wrong here?
39 Replies
- It looks like several have seen progress on this issue, I am still getting the 'Write-Error'. Is there a trick to getting it working or just need to wait for the fix to hit my instance?
- Hi everyone,
I have the same problem, I entered the command:
Set-UnifiedGroup "MYGROUP" -CalendarMemberReadOnly
It seems to be propagating well, as there's no problem in Outlook Webmail for member.
On the other hand, I'm getting some strange behavior on Outlook:
- Outlook must be configured in cache mode, to see Microsoft 365 groups.
- Members can't modify items created by a group 365 owner => Perfect
- User can still create new meetings in the Microsoft 365 group's calendar, but he's the only one to see it, and cannot be modified/deleted afterwards.
- Restarting Outlook clears the cache, and previously created meetings disappear.
Do you have the same problem ?
Do we need to wait a little longer (command launched 4 hours ago) ?
Thank you !- 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.
- I have a case with MSFT about the M365 groups being visible in Outlook desktop client. But this is another topic. I see that if I don't have my Outlook with Cached Mode enabled (set to All) I won't be able to see the groups.
So...with that said I think proper experience is expected with OWA but not entirely with Outlook desktop client. That's what I've observed so far.
- Can confirm that the command is working now and it propagates too. Hooray!
- I used the command in my test tenant yesterday successfully to set the group calendar to CalendarMemberReadOnly:$true.
Today I wanted to revert it for another test and am not able to set it to CalendarMemberReadOnly:$false nor $true...bthomas Same here. The command on my tenant didn't work too. I get the below message:
Set-UnifiedGroup: Object reference not set to an instance of an object.I tried to specify by the name of the group or by groupID and both didn't work.
- This command appears to have started working for me as of this morning, July 24.
Powershell indicates "The command completed successfully but no settings of [Group] have been modified" after I run it, but when I check on the Group's properties, I can see that CalendarMemberReadOnly has changed from False to True. - Same here
- July 20, 2023 still broken. Unfortunate because I banged my head against a wall trying to solve this, until adding a "2023" to my search and find it's broken. Ha. Hopefully it gets fixed soon.
- Has Microsoft fixed this for anyone yet? Or have they provided an update as to when this will be fixed?
- No update on my case yet.
- Commenting to confirm that I'm having the exact same problem trying to run this command.
- Same here - at first i thought it was my own doing. Then I found this post.
- I just opened a case about this issue as I head scratched why the powershell cannot change the calendar property. Will keep you guys posted if I find a solution or anything.
So far the update from MSFT is that they still working on it. My case has been merged into a larger case which includes all other cases like mine and their respective affected domains.
- Add me to the list. Also opened case with Microsoft. Maybe is enough ppl open cases for this it will get resolved sooner.
Kris_Petrov_1986 Ok, I hope you will get an answer. I also opened a case, but no response until now.
