

- Exchange public folder security group how to#
- Exchange public folder security group full#
- Exchange public folder security group software#
They recommend to use Outlook clients or the PowerShell to change permissions on the public folders. "the reported issue is caused by a known problem (which is being addressed by our Product Engineering team from the backend)" MS says, that the problem with the WebGUI permission settings is well known:

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. 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. 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 are also investigating why it is not possible to set the permissions via the WebGUI.
Exchange public folder security group software#
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. In the meanwhile the group permissions completely disappeared.
Exchange public folder security group how to#
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? Why is it not possible to set a PF permission via the WebGUI? 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. If I remove there one of the group permissions and re-add it, then the SID is shown and everything works fine. It is possible to change permissions via an Outlook client. 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. System throws an exception at calculating Lambda Expression : Exception has been thrown by the target of an invocation.` `System throws an exception at calculating Lambda Expression : Exception has been thrown by the target of an invocation. I am also not able to change any permissions via the WebGUI, it ends up with the following message.
Exchange public folder security group full#
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. The user SIDs look fine, the problem is only on the groups. I found then out, that the SID on the folder permissions of the assigned groups are shown as unknown. Today the issue appeared that no one was able to access the PF anymore. Yesterday, I also changed the Azure AD Connector that it synchronizes just some of the needed OUs. 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. 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.Īfter that, on the clients the message appeared that the Exchange Administrator performed changes which required a restart of the Outlook client. 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. Yesterday we demoted the MSEX2016, which had already been turned off for testing a couple of days before. All the clients were able to access the public folders and their mailboxes on O365. This worked for a couple of weeks without problems. The local AD gets synchronized with Azure AD by the Azure AD Connector on one of our local servers. Then we migrated all the mailboxes and public folders from MSEX2016 to Office 365, and we demoted and shut down the MSEX2010. We installed a new Exchange 2016 server and migrated all the mailboxes from the Exchange 2010 server to it.
