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.

SID not shown in public folder permission

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.`

enter image description here

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):

In the meanwhile the group permissions completely disappeared. group permissions disappeared

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."

  • Hi, is there any update? If your problem has been fixed, you could share your solutions or mark the best answer so that others with the same problem will find it. Have a good day!
    – Ivan_Wang
    Oct 21, 2021 at 2:05
  • I just added "Edit 2" with updates. MS is working on it to figure put why the the permissions disappeared and why it is not possible to set them via the WebGUI. Oct 21, 2021 at 8:36
  • I am having this same error when I try to add someone to a fax folder, any resolutions so far?
    – Shoy
    Oct 22, 2021 at 13:36
  • Hi, it's been a while, any update?
    – Ivan_Wang
    Oct 27, 2021 at 9:51
  • 1
    I asked yesterday for an update regarding the MS ticked and I am still waiting for a response. Oct 28, 2021 at 10:09

2 Answers 2


The error "System throws an exception at calculating Lambda Expression" which happens on public folder seems to be a known issue: Can't change permissions error

The current solution is to modify the permission via Outlook or other clients. Besides, you could also try to connect to Exchange Online PowerShell and run the following command to modify the permissions of your public folders:

Add-PublicFolderClientPermission \pf -AccessRights Owner -User User01


I think I am finally able to answer the questions by myself.

"Why is it not possible to set a PF permission via the WebGUI?"

This is an issue in the Microsoft backend. Microsoft is aware about it and they are working on it, but there is no ETA at the moment. It seems there are a couple issues with public folder settings via the WebUI / EAC in general.

Edit 2022-01-14: It seems that MS fixed this issue, I was able to set permissions via the webinterface today.

"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?"

Microsoft installed in Exchange Online the Public Folder Consistency Agent for Exchange Online Tool which automatically deletes every 7 days all permissions from public folders or every day on mail-enabled folders which are considered as orphaned/stale. It seems it considers groups which are temporarily not synced by the Azure AD Connect client anymore as orphaned/stale and then it deletes all these permissions and there is no way back.

MS should give there at least an option to disable this automatic tool, or better to allow admins only run it manually.

I was able to get almost all of the permissions back by a script, because they got exported on our on-premesis exchange server during the migration process and not a lot on the folder structure got changes since that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.