EXOManagementRoleAssignment: Does not work if a soft-deleted identically named Administrative Unit exists

[Borgquite]

Details of the scenario you tried and the problem that is occurring

The resource EXOManagementRoleAssignment supports specifying Administrative Units by DisplayName (#2708). However it does not cope with the situation where an Administrative Unit has been soft-deleted and a new Administrative Unit created with an identical display name.

After deleting an Administrative Unit the AU remains in a soft deleted state for 30 days. At this point it cannot be hard deleted - you have to wait 30 days. https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/recover-from-deletions#administrative-units-1

However the Get-AdministrativeUnit cmdlet in the Exchange Online PowerShell module which EXOManagementRoleAssignment uses at present does not return information about an AU being soft-deleted - it simply returns all AUs, whether soft-deleted or not.

This causes various errors when running a configuration where there is an AU which has been soft-deleted with the same name as one that has not.

Verbose logs showing the problem

VERBOSE: [COMPUTERNAME]: LCM:  [ Start  Resource ]  [[EXOManagementRoleAssignment]AssignManagementRole]                                                                               VERBOSE: [COMPUTERNAME]: LCM:  [ Start  Test     ]  [[EXOManagementRoleAssignment]AssignManagementRole]                                                                               VERBOSE: [COMPUTERNAME]:                            [[EXOManagementRoleAssignment]AssignManagementRole] Testing Management Role Assignment for MyManagementRoleAssignment             
VERBOSE: [COMPUTERNAME]:                            [[EXOManagementRoleAssignment]AssignManagementRole] Getting Management Role Assignment for MyManagementRoleAssignment
VERBOSE: [COMPUTERNAME]:                            [[EXOManagementRoleAssignment]AssignManagementRole] Management Role Assignment MyManagementRoleAssignment does not exist.
VERBOSE: [COMPUTERNAME]:                            [[EXOManagementRoleAssignment]AssignManagementRole] Current Values: ApplicationId=***;
CertificateThumbprint=***; Ensure=Absent; Name=MyManagementRoleAssignment; RecipientAdministrativeUnitScope=Test-Unit; Role=Mail Recipients;   
SecurityGroup=Test-Group; TenantId=***; Verbose=True
VERBOSE: [COMPUTERNAME]:                            [[EXOManagementRoleAssignment]AssignManagementRole] Target Values: ApplicationId=***;
CertificateThumbprint=***; Ensure=Present; Name=MyManagementRoleAssignment; RecipientAdministrativeUnitScope=Test-Unit; Role=Mail Recipients;  
SecurityGroup=Test-Group; TenantId=***; Verbose=True
VERBOSE: [COMPUTERNAME]:                            [[EXOManagementRoleAssignment]AssignManagementRole] Test-TargetResource returned False
VERBOSE: [COMPUTERNAME]: LCM:  [ End    Test     ]  [[EXOManagementRoleAssignment]AssignManagementRole] False in 1.0510 seconds.
VERBOSE: [COMPUTERNAME]: LCM:  [ End    Resource ]  [[EXOManagementRoleAssignment]AssignManagementRole]

Suggested solution to the issue

EXOManagementRoleAssignment does not cope well with multiple Administrative Units with identical DisplayNames. Suggest:

• Informing the Exchange Online PowerShell team that the Get-AdministrativeUnit cmdlet returns both existing and soft-deleted AUs. They could include an attribute indicating this, but ideally soft-deleted AUs would be excluded from the output by default, with some sort of switch to show them.
• In the mean time, modify EXOManagementRoleAssignment module to select and use the last Administrative Unit returned (most recently created, therefore most likely to be the correct one) where the DisplayName filter returns multiple AUs.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

• Manually create an Administrative Unit called 'Test-Unit'
• Delete it
• Wait for it to be visible in Get-AdministrativeUnit in Exchange Online PowerShell

$credsCredential = Get-Credential

Configuration Example
{
    Import-DscResource -ModuleName Microsoft365DSC

    node localhost
    {
        AADAdministrativeUnit 'TestUnit'
        {
            Credential                    = $credsCredential;
            DisplayName                   = "Test-Unit";
            Ensure                        = "Present";
        }
        EXODistributionGroup 'MailEnabledSecurityGroup'
        {
            Credential = $credsCredential;
            Name = "Test-Group";
            Alias = "Test-Group";
            Type = "Security";
            Ensure = "Present";
        }
        EXOManagementRoleAssignment 'AssignManagementRole'
        {
            Credential           = $credsCredential;
            Ensure               = "Present";
            Name                 = "MyManagementRoleAssignment";
            Role                 = "Mail Recipients";
            SecurityGroup        = "Test-Group";
            RecipientAdministrativeUnitScope = "Test-Unit"
        }
    }
}

$cd = @{
    AllNodes = @(
        @{
            NodeName = 'localhost'
            PSDscAllowPlainTextPassword = $true
        }
    )
}

The operating system the target node is running

OsName : Microsoft Windows 11 Enterprise
OsOperatingSystemSKU : EnterpriseEdition
OsArchitecture : 64-bit
WindowsVersion : 2009
WindowsBuildLabEx : 22621.1.amd64fre.ni_release.220506-1250
OsLanguage : en-GB
OsMuiLanguages : {en-GB, en-US}

Version of the DSC module that was used ('dev' if using current dev branch)

1.23.308.1

[NikCharlebois]

That's an interesting find. The Get-MgAdministrativeUnit Graph cmdlet does it differently and doesn't return the soft deleted AU at all. I will try and reach out to the EXO Management Shell team.

[NikCharlebois]

Would it be a viable solution for you if we were to leverage the Graph cmdlet that doesn't return soft-deleted AU instead?

[Borgquite]

@NikCharlebois Whatever is easier for you!

[Borgquite]

@NikCharlebois My only thought was that there's normally a delay between an AU being created/deleted in Azure AD and it being available/removed in Exchange Online. However thinking about it, in this instance, that would only be an issue where an AU was deleted (and as we know the current situation is broken there anyway). It feels like such an edge case that it's not worth worrying about. So yes, give it a try :)

[Borgquite]

Thanks, that's really helpful!