We installed a new Exchange 2016 server and migrated all the mailboxes from the Exchange 2010 server to it. Then we migrated all the mailboxes and public folders from MSEX2016 to Office 365, and we demoted and shut down the MSEX2010. The local AD gets synchronized with Azure AD by the Azure AD Connector on one of our local servers.
This worked for a couple of weeks without problems. All the clients were able to access the public folders and their mailboxes on O365.
Yesterday we demoted the MSEX2016, which had already been turned off for testing a couple of days before. There was no PF active on it, but it was not possible to remove the databases in the regular way, since it always showed that the server is still in migration mode. It did not help to manually set attributes (like MigrationComplete...) and we finally removed them with the force option, demoted the server and shut it down.
After that, on the clients the message appeared that the Exchange Administrator performed changes which required a restart of the Outlook client. Not sure why this message showed up, since alle the clients were already connected to the O365 and there should not have been any established connection to the old MSEX2016.
Yesterday, I also changed the Azure AD Connector that it synchronizes just some of the needed OUs.
Today the issue appeared that no one was able to access the PF anymore. I found then out, that the SID on the folder permissions of the assigned groups are shown as unknown.
The user SIDs look fine, the problem is only on the groups. I thought first this has maybe something to do with the OU limitation of the Azure AD Connector and I re-activated the full sync how it was before, but it did not help.
I am also not able to change any permissions via the WebGUI, it ends up with the following message.
`System throws an exception at calculating Lambda Expression : [ Boolean(@0[ApplyToSubFolders]) ] Exception has been thrown by the target of an invocation. ERROR
System throws an exception at calculating Lambda Expression : [ Boolean(@0[ApplyToSubFolders]) ] Exception has been thrown by the target of an invocation.`
I was able to create a new "test" folder in the root PF, but I am not able to setup any permissions there via the WebGUI.
It is possible to change permissions via an Outlook client. If I remove there one of the group permissions and re-add it, then the SID is shown and everything works fine. Means to me all the groups are known in general at O365 (they are also shown there in the Exchange Admin WebGUI), but on the existing permissions they are not assigned to it.
Why is it not possible to set a PF permission via the WebGUI?
Why did it lose its assignment from the existing public folder group permissions to the SIDs and how to fix it without to remove and re-add all permissions manually?
Edit 1 (Monday 2021-10-18):
Edit 2 (Thursday 2021-10-21):
There is a Microsoft ticket open since Monday, but they cannot explain why the permissions disappeared and their software engineers are working on it to figure out what happened. They are also investigating why it is not possible to set the permissions via the WebGUI. Their proposed solution was to set all the permissions by hand on all the folders with Outlook or with PowerShell, what did not satisfy me since we have about 2700 folders. They were not willing ("building custom scripts is generally outside of our support boundaries") to provide a script to re-apply the permissions from the XML file which was created during the migration and they did not show up with any other solution to get the permissions back.
I was in the meanwhile able to re-apply the public folder permissions with this script created by myself and by the support of the community.
Edit 3 (Saturday, 2021-10-30)
MS says, that the problem with the WebGUI permission settings is well known: "the reported issue is caused by a known problem (which is being addressed by our Product Engineering team from the backend)" They recommend to use Outlook clients or the PowerShell to change permissions on the public folders.
They further say that I cannot prove that the permission got not deleted by an admin activity, since our audit log was not enabled (per MS default) and I cannot show recordings about it. I have sent again my screenshot to them which shows the strange situation with the missing SID on the group permissions to point out that this is a problem in the MS infrastructure. I am the only guy who has admin access and I am sure that I did not delete permissions on the public folders.
Edit 4 (Sunday, 2021-11-14)
Answer from MS: "Regarding the issue with assigning permissions through the admin center UI, my colleague advised that this problem is already published externally, as the issue is know for some time now. As previously mentioned, our Product Engineering team is currently working on developing a permanent fix, however, there is no specific ETA at the moment so we cannot fully confirm when to expect the resolution. For more information, you can also refer to the Public folder permissions and settings don't propagate in EAC article (it also includes the PowerShell script we suggested, which is the official workaround for this problem that our colleagues have provided)."
"From the information you have shared with us so far (including the screenshot from the EAC, which shows the missing SIDs), my colleague suspects that the affected public folders were migrated normally to Exchange Online, however, the Mail-security groups granting permissions to users were not synchronized afterwards (or there was an issue with the synchronization process). As a result of that, these permission groups were considered orphaned/stale and have been deleted with our consistency agent, which runs every 7 days in the backend." "Having said that, this behaviour is by design, but we sadly cannot fully confirm why the permissions were detected as stale in the first place. For more information about this matter, we recommend to review the official Announcing the Public Folder Consistency Agent for Exchange Online post from the Exchange development team, which explains how the agent works."