Michael Uray's questions

I did run into the situation that I lost all my public folder permissions which were assigned via groups.

Before the migration started from our MSEX2016 server to Office 365, all the permissions got exported to a XML file, what I think (described on this Microsoft page) happened with the following command:

Get-PublicFolder -Recurse -ResultSize Unlimited | Get-PublicFolderClientPermission | Select-Object Identity,User,AccessRights -ExpandProperty AccessRights | Export-CliXML OnPrem_PFPerms.xml

The output file "OnPrem_PFPerms.xml" has about 5 GB. That sounds a lot to me for permissions only on a about 300 GB PF structure, but maybe is its huge size cause by the complexity of the XML format. 7-Zip compression brings it down to 25 MB, means there is a lot of redundant data in it.

On our MSEX2010 which got migrated to MSEX2016 before is a "Legacy_PFPerms.xml" file with about 500 MB.

What would be the proper PowerShell command to apply all the permissions from the XML file to the public folder structure on the Office 365 / Exchange online?

I guess Import-CliXML would do the job somehow, but I am not that familiar with PowerShell to build the right command.

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

In the meanwhile the group permissions completely 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."

I have there a OpenVPN VPN network connection, where the MSS size 60 gets send out for some reason (don't know why yet). EDIT: Reason: OpenVPN mssfix was mistakenly set to 1

36  92.064383   10.102.0.43 10.1.151.50 TCP 52  49991 → 63760 [SYN] Seq=0 Win=65535 Len=0 MSS=60 WS=128 SACK_PERM=1
37  92.064763   10.1.151.50 10.102.0.43 TCP 52  63760 → 49991 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1

There are two devices on this network, which behave different.

• Win 10 PC with Filezilla FTP Server
• Embedded device (PLC) based on VxWorks with internal FTP server

The PC sets the MSS size to 536, but the PLC sets it down to 60 like requested.

41  92.171676   10.1.151.50 10.102.0.43 FTP-DATA    576 FTP Data: 536 bytes (PASV) (RETR TCData.br)
67  17.385576   10.1.151.1  10.102.0.43 FTP-DATA    100 FTP Data: 60 bytes (PASV) (RETR TCData.br)

Is that implemented on the right way on both sides?

I know that the default TCP MSS is 536, but is there a required minimum size?

I assigned a self signed wildcard certificate to an OpenWRT (LEDE) router LUCI (uHTTPd) system. The CA which signed this certificate got added to all browsers as trusted certificate authoritiy.

It works fine on Internet Explorer, Edge and Chrome, but not on Firefox 58.0.2, which throws the error SSL_ERROR_BAD_CERT_DOMAIN, even when it states on the same error page that the certificate is issued for this domain.

If I issue the certificate directly for the host (no wildcard) then it works fine in FF as well.

What could cause this issue?