![exchange public folder security group exchange public folder security group](https://exchangepedia.com/images/Windows-Properties-SecurityTab3.png)
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. It is, obviously, crucial to validate what damage any script you run will perform in case you review the changes and find that it will cause you problems.We installed a new Exchange 2016 server and migrated all the mailboxes from the Exchange 2010 server to it. The structure looks like this screenshot below, with each folder having a mix of different permissions added:īefore I replace the permissions, I will want to test the script to see which permissions will be removed.
![exchange public folder security group exchange public folder security group](https://dptechgroup.com/wp-content/uploads/office-365-support/office-365-1-admin-exchange.png)
I’ll give this group Owner permissions down the tree, starting from a folder called TopLevel. In the example below, I’m going to replace the existing permissions with a Mail-Enabled Security Group, called PFPGroup.
Exchange public folder security group download#
To use the script, download it from my GitHub. I’ll cover a quicker way of performing a search and destroy for these type of issues in my next article on the subject, but if you want to perform a clean of a Public Folder tree and remove spurious permissions that should not be there, then using the ReplacePFPermissions script may help. For example, you might find some recently deleted users, or users who are not mailbox-enabled still have Public Folder permissions, as shown below: One common problem you may be trying to solve (and failing) is removing permissions that aren’t identified as problematic by the Source Side Validation scripts provided by Microsoft. The ReplacePFPermissions script is a simple script that enables you to remove non-default permissions from a Public Folder and it’s sub-folders and add a new Public Folder permission – such as a group, or perhaps an admin account if you are removing general user access.
![exchange public folder security group exchange public folder security group](https://www.codetwo.com/media/images/658-2.png)
To help with this requirement for one of my customers, I’ve written a simple script that can be used to achieve this. There are scripts from Microsoft to do this on Exchange 2013 and above, but not a quick and simple one for Exchange 2010. One common ask is to be able to quickly replace a set of Public Folder permissions on Exchange 2010. Unfortunately, they’re still around and as Exchange 2010 lives beyond the grave, with its life-support extended until October 2020 you, like many others, are trying to get rid of Public Folders or move them to modern Exchange or Office 365. You wouldn’t expect that in 2020 we would still be trying to manage Public Folders in Exchange, especially given that people originally expected them to die a death nearly fourteen years ago, with Exchange 2007.