[Issue] SourceSideValidations - InvalidPermissions

[PrayingMoses]

Script does not detect permission issues caused by objects which are not AAD synced, which might cause a lot of errors (A corrupted item was encountered: Folder ACL )within the PublicFolderMailboxMigrationRequests.

Permission Report should also report/consider 'RecipientDisplayTypeRaw': non ACLable objects (i guess those should be at least re-viewed since it makes no sense to keep the PF permissions of such recipients?) e.g. (Remote)SharedMailboxes 'SyncedMailboxUser' DL's which are not security-enabled

Proposal: get all recipients with permissions on on-prem public folder, check if they are also available in Exchange Online and report them if not.

Regards

[bill-long]

Note this type of error does not prevent the migration from completing. It just creates a lot of error noise in the log.

I'm not sure if this is something we should address in this script. There are some downsides:

• This would make the script require internet access. Right now, it can be run on servers with no such access, so it can be used before any sort of hybrid server or MRS endpoint is set up and can be used to check for problems in purely on-prem environments.
• This would add a dependency on the EXO PowerShell module, and that would add auth prompts and token refreshes that we would need to deal with in the script.
• The script is called source side validations. If we're going to start validating the target, it seems like we should also do the type of work that Sync-ModernMailPublicFolders does. After all, a failure to sync the PF proxy objects will actually break your migration, unlike these ACL errors. Those are synced by the script and not by AAD Connect.

Are there any tools out there for highlighting and/or troubleshooting issues with AAD Connect? Pointing people to an existing tool where that type of validation is already in scope would be preferable.

[PrayingMoses]

Hi,

I agree on the source side validations. I also wanted to highlight "If the folder hierarchy had many corrupt ACLs that were not cleaned up before the migration, there might be a significant delay in completion." at https://learn.microsoft.com/en-us/exchange/collaboration/public-folders/migrate-to-exchange-online?view=exchserver-2019#step-6-lock-down-the-public-folders-on-the-exchange-on-premises-server-public-folder-downtime-required

It might be a (not 100%) idea to add more information to the source side validation (permission check) to be able to catch potential recipients which are not AAD synced and/or not ACLable (as I said, only taking a look at on-prem will not be 100%). e.g.: `Get-PublicFolderClientPermission -Identity "\TESTPF" | select -ExpandProperty user | select -ExpandProperty adrecipient | select samaccountname,recipientd,recipientt,RemoteRecipientType,MasterDirectoryObjectId

SamAccountName : MigratedUserMailbox RecipientDisplayTypeRaw : ACLableSyncedMailboxUser RecipientDisplayType : ACLableSyncedMailboxUser RecipientType : MailUser RecipientTypeDetails : RemoteUserMailbox RemoteRecipientType : Migrated MasterDirectoryObjectId : User_e32f2ac2-d9ba-4686-9211-a0632aefg505

SamAccountName : OnPremOnlyUserMailbox RecipientDisplayTypeRaw : ACLableMailboxUser RecipientDisplayType : ACLableMailboxUser RecipientType : UserMailbox RecipientTypeDetails : UserMailbox RemoteRecipientType : None MasterDirectoryObjectId :

SamAccountName : OnPremOnlySharedMailbox RecipientDisplayTypeRaw : MailboxUser RecipientDisplayType : MailboxUser RecipientType : UserMailbox RecipientTypeDetails : SharedMailbox RemoteRecipientType : None MasterDirectoryObjectId :

SamAccountName : DistributionList RecipientDisplayTypeRaw : SecurityDistributionGroup RecipientDisplayType : SecurityDistributionGroup RecipientType : MailUniversalSecurityGroup RecipientTypeDetails : MailUniversalSecurityGroup RemoteRecipientType : MasterDirectoryObjectId : ` The RemoteRecipientType might be misleading if the mailbox was migrated back to on-prem, as far as i've seen. (not fully tested) I am not only talking about AAD Connect issues. I am also referring to AAD configurations/issues were specific AD Objects are not targeted to by synced (for whatever reasons) or recipients which got permissions on PF's in the past and got converted (e.g. to shared mailboxes / not ACLable) afterwards, etc. Adding additional information (also available on-prem only) about potential on-prem only recipients and/or not ACLable will give us the possibility to check against O365 (with an additional script) and/or clean-up in advance to avoid a significant delay in completion of the PublicFolderMigrationBatch.

Searching and cleaning such permission errors (in my case ~230k PF's) might be very time consuming (depending to the hierarchy size) and I discovered those permission issues after a lot of error noise in the migration log, even the SourceSideValidations script told me that there are no more permission errors.

Regards

[bill-long]

True, it does make the migration slower. It just doesn't stop it.

Hmmm, so the logic for this kind of check, assuming a very simple script, would be something like:

$validAclableRecipientTypes = @(
    "ACLableSyncedMailboxUser",
    "ACLableMailboxUser",
    "SecurityDistributionGroup")

Get-PublicFolder -Recurse -ResultSize Unlimited | ForEach-Object {
    $permissions = Get-PublicFolderClientPermission $_.Identity
    foreach ($p in $permissions) {
        if ($null -ne $p.User.ADRecipient) {
            if ($p.User.ADRecipient.RecipientTypeDetails -notin $validAclableRecipientTypes) {
                Write-Host "Invalid recipient type $($p.User.ADRecipient.RecipientTypeDetails) for $($p.User.ADRecipient.PrimarySmtpAddress)"
            }
        }
    }
}

[Batre-MSFT]

The ACL sync failure themselves do not interrupt/fail the migration, but they will assign lower score (DCS) to migration batch, which tenant admins will have to approve to continue. If possible, we should report these in SSV and provide command/way for tenant admin to these ACLs

[PrayingMoses]

Hi,

sorry for the late response.

`$validAclableRecipientTypes = @( "ACLableSyncedMailboxUser", "ACLableMailboxUser", "SecurityDistributionGroup")

Get-PublicFolder \ -Recurse -ResultSize Unlimited | ForEach-Object { $permissions = Get-PublicFolderClientPermission $_.Identity foreach ($p in $permissions) { if ($null -ne $p.User.ADRecipient) { if ($p.User.ADRecipient.RecipientDisplayType -notin $validAclableRecipientTypes) { Write-Host "Invalid recipient type $($p.User.ADRecipient.RecipientTypeDetails) for $($p.User.ADRecipient.DistinguishedName) on Public Folder $($p.Identity)" } } } }`

please note:

• $p.User.ADRecipient.RecipientTypeDetails was changed to $p.User.ADRecipient.RecipientDisplayType to match the values defined in $validAclableRecipientTypes
• added some stuff to clearly identify the affected AD object and Public Folder
• DL's which are converted from Security-enabled to (pure) Distribution Group are still shown as RecipientDisplayType "SecurityDistributionGroup" within the PF permissions but as RecipientTypeDetails already MailUniversalDistributionGroup. (maybe this just takes a while for Exchange/Public Folder to pick up the change)
• again, as long as not verified against O365 you will not be able to catch recipients which are 'valid' on-prem but e.g. ACLableMailboxUser" are not synced to O365

e.g.: Security-enabled DL: Get-DistributionGroup TestDLSec | fl recipient RecipientType : MailUniversalSecurityGroup RecipientTypeDetails : MailUniversalSecurityGroup

after converting to pure (not security-enabled) DL in AD: Get-DistributionGroup TestDLSec | fl recipient

RecipientType : MailUniversalDistributionGroup RecipientTypeDetails : MailUniversalDistributionGroup

[bill-long]

I converted a USG to a UDG before the holidays, and since then it has been several weeks and several reboots. The ADRecipient in the ACL still says it is a SecurityDistributionGroup. I think this value never updates.

Given that we can't trust the accuracy of the values on-prem, and we don't have visibility into Exchange Online without vastly expanding the script, I don't think we can address this in the script.

This scenario will have to be solved through troubleshooting, unless we start seeing enough of these cases to justify a huge expansion to the scope of the script. PRs are welcome if someone else wants to try implementing this.