O365OrgCustomizationSetting - Problem with command

[T630Dev]

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

Used the DSC Res O365OrgCustomizationSetting and the applied it to the target tenant.
Error is:
:The role assignment policy"Default Role Assignment Policy" wasn't found. Make sure that you typed the identity correctly.

When I execute manually a PS command against the tenant, the policy is there:

The given error message contains the below code:
Get-RoleAssignmentPolicy -DomainController $RoleDomainController -Organization $RoleOrganizationHierarchicalPath -IgnoreDehydratedFlag | Where {$_.Name -eq $raPolicyName};

However, the IgnoreDehydratedFlag seems to not exist any longer:

Verbose logs showing the problem

FailureCategory=Cmdlet-ScriptExecutionException] 1A838805,Microsoft.Exchange.Management.Deployment.EnableOrganizationCustomizationTask. Fehlermeldung: The following error was generated when
if (!$AdvancedHydrateableObjectsSharedEnabled)
{
$unifiedRAP = ($NewServicePlanSettings -eq $null -and -not $ServicePlanSettings.Organization.PerMBXPlanRoleAssignmentPolicyEnabled) -or ($NewServicePlanSettings -ne $null -and -not $NewServicePlanSettings.Organization.PerMBXPlanRoleAssignmentPolicyEnabled);
$raPolicyName = [Microsoft.Exchange.Data.Directory.SystemConfiguration.RoleAssignmentPolicy]::DefaultRoleAssignmentPolicyName;
$policyDescription = [Microsoft.Exchange.Data.Directory.SystemConfiguration.RoleAssignmentPolicy]::PrecannedRoleAssignmentPolicyDescription;
$raPolicy = $null;
Write-ExchangeSetupLog -info ("PerMBXPlanRoleAssignmentPolicyEnabled Task; unifiedRAP=" + $unifiedRAP);
if($unifiedRAP)
{
#Trying to find local RAP object with default name
$raPolicy = Get-RoleAssignmentPolicy -DomainController $RoleDomainController -Organization $RoleOrganizationHierarchicalPath -IgnoreDehydratedFlag | Where {$_.Name -eq $raPolicyName};
Write-ExchangeSetupLog -info ("PerMBXPlanRoleAssignmentPolicyEnabled Task; raPolicyFound=" + ($raPolicy -ne $null));
}

        if($unifiedRAP)
        {
          if($raPolicy -eq $null)
          {
              Write-ExchangeSetupLog -info ("Creating Default RAP " + $raPolicyName);
              $raPolicy = New-RoleAssignmentPolicy `
                  -Name $raPolicyName `
                  -DomainController $RoleDomainController `
                  -Description $policyDescription `
                  -IsDefault `
                  -IgnoreDehydratedFlag `
                  -Organization $RoleOrganizationHierarchicalPath;
          }
        }
        Write-ExchangeSetupLog -info ("PerMBXPlanRoleAssignmentPolicyEnabled Task; looping through mailboxplans:" + $ServicePlanSettings.MailboxPlans.Count);
        foreach ($mp in $ServicePlanSettings.MailboxPlans)
        {
            if($mp.Instance -eq $null)
            {
              Write-ExchangeSetupLog -error ($mp.Name + " MailboxPlan instance value is not set");
            }

            #MailboxPlan has non-null RoleAssignmentPolicy property only if RAP link is stamped explicitly - no implicit default there
            if($mp.Instance.RoleAssignmentPolicy -ne $null -and $unifiedRAP)
            {
              Write-ExchangeSetupLog -info ("MailboxPlan already with RAP " + $mp.Name);
              continue;
            }
            if(!$unifiedRAP)
            {
              $raPolicyName = "RoleAssignmentPolicy-" + $mp.Name;
              $raPolicy = Get-RoleAssignmentPolicy -DomainController $RoleDomainController -Organization $RoleOrganizationHierarchicalPath -IgnoreDehydratedFlag | Where {$_.Name -eq $raPolicyName};

              if($raPolicy -eq $null)
              {
                  Write-ExchangeSetupLog -info ("Creating RAP for " + $mp.Name);
                  $raPolicy = New-RoleAssignmentPolicy -Name $raPolicyName -DomainController $RoleDomainController -Description $policyDescription -Organization $RoleOrganizationHierarchicalPath -IgnoreDehydratedFlag;
              }
            }

            Set-MailboxPlan -Identity $mp.Instance.Identity -RoleAssignmentPolicy $raPolicy.Identity -DomainController $RoleDomainController;
        }
      }
     was run: "System.Management.Automation.ActionPreferenceStopException: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: The role assignment policy"Default Role Assignment Policy" wasn't found. Make sure that you typed the identity correctly.

at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
at Microsoft.Exchange.Configuration.MonadDataProvider.MonadPipelineProxy.ClosePipeline(MonadAsyncResult asyncResult)"..

Suggested solution to the issue

na

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

instance of MSFT_O365OrgCustomizationSetting as $MSFT_O365OrgCustomizationSetting1ref
{
ResourceID = "[O365OrgCustomizationSetting]Container-58-aff658e9-f570-49d2-9217-e6e99f7bfac2";
 CertificateThumbprint = "abc";
 Ensure = "Present";
 ApplicationId = "abc";
 SourceInfo = "::10::3::O365OrgCustomizationSetting";
 TenantId = ".onmicrosoft.com";
 IsSingleInstance = "Yes";
 ModuleName = "Microsoft365DSC";
 ModuleVersion = "1.21.1117.2";
 ConfigurationName = "MainConfig";
};

[NikCharlebois]

We will need more information to troubleshoot. In what file are you seeing the IgnoreDehydratedFlag being used and on what line? We can't find any reference to that property anywhere in the latest versions.

[T630Dev]

I retested this today. First, I ran the Export-M365DSC Cmdlet for the resource. Technically, that worked fine. Although the ps1 Export file did not contain any information about that res. (Node localhost was empty)

Without modifying the MOF file from yesterday, I ran Start-DSCConfiguration -UseExisting again.
It worked fine this time although it was very slow.

Since I cannot reproduce it today, I suggest we park this item or close it and then reopen it later in case the issue reoccurs.
We will test this again with other vanilla tenants as this IsDehydrated setting cannot be undone.

Thx!

[NikCharlebois]

Thanks

[T630Dev]

I tested the same again on vanilla tenants and I get the same error message. So the issue is reproduceable, unfortunately only one time on a new tenant since that setting cannot be set to its original state.
The IsDehydrated setting is not applied and hence some subsequent settings for EXO fail due to the missing IsDehydrated setting.

I then waited 1h and started the same DSC configuration again. That time, the setting was applied correctly and the subsequent settings for EXO were also applied correctly.

[NikCharlebois]

This is related to the fact that it takes some time for the isDehydrated property to get propagated to the tenant. One option would be to add a Sleep period after setting the property. This is something we are doing in other DSC modules (e.g., SharePointDSC when creating a new farm). @ykuijs thoughts?

[T630Dev]

ok thanks. Yes, that would help. But this sleep command would be something that would need to be done in the code of that particular DSC res. Maybe you can check within MS how long it takes until the IsDehydrated settings becomes active to set the correct sleep time.

[andikrueger]

From my experience, this setting can take up to 24 hours to replicate. Usually it's quicker. As long as we do not know the exact timings I wouldn't think about loops with sleeping threads.

[andikrueger]

@T630Dev Is there any new information to share?

[T630Dev]

@T630Dev Is there any new information to share?

Not really. From my experience, it took a few hours but I do not really have a solution how we will proceed. Either can find a technical solution with MS and can incorporate this in the DSC res or we need to implement a workaround so that after the tenant was provisioned, a ps cmdlet runs to set the IsDehydrated setting for this new tenant and then after one day, the DSC scripts start.
What we cannot use, however, is the DSC config that we need to run one time knowing that it will fail and then run it again another day as we will integrate this in a bigger workflow to automate tenent deployment.

[andikrueger]

I just had a look into the history of this resource. Back then, @NikCharlebois and I had a discussion about the delay (24 hours) for this setting to be replicated across Microsoft 365. (#136)

From my experience with other settings within M365 I would recommend to go with a two phased approach (Like you suggested)

1. Set IsDehydrated in a first step
2. Wait for 24-36 hours
3. Run the configuration

This resource is very "unique" and offers only the option to enable the customization settings. Having a sleep within this resource could cause further issues in pipelines or for users, that are not aware of this delay...

We should add information to the verbose output and event log about this delay.

[NikCharlebois]

For the moment the only thing we can do is warn the user that this setting can take up to 24 hours to apply. This will be included as part of release 1.22.720.1