SCRetentionCompliancePolicy: No changes possible because of undeployed prev changes

[T630Dev]

ISSUE DESCRIPTION (this template):
When I create a new policy for the first time, the DSC resource works fine.
When I change the comment attribute of the resource manually (without DSC), I receive an error message that no changes can be made due to prev. pending changes.
However, even if I wait 2h and try manually the Set-ComplianceRetentionPolicy -RetryDistribution command, DSC does not run successfully.

When I try to change the res manually in PS, I receive a similar error.

Solution for PS is to use the -force Parameter. When I looked in the DSC res Src code, the Set-ComplianceRetentionPolicy does not have a force parameter. Please add this parameter to the res.

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

Create res as described in issue ID
Change something like the comment in the newly created policy.
Build the MOF and apply the config

Error in DSC Log:
##[error]Previous changes to the policy '1aefdbc5-5987' are being deployed. Once deployed, additional actions can be performed. Please refer to 'https://go.microsoft.com/fwlink/?linkid=2148779' to learn more.

Configuration MainConfig
{
    param
    (
         [Parameter(Mandatory = $true,Position=0)][ValidateNotNull()][System.Management.Automation.PSCredential]$AdminCred
    )
    Import-DscResource -ModuleName "Microsoft365DSC"
    Node localhost
    {
                
        SCRetentionCompliancePolicy 'RetentionCompliancePolicyEXO'
        {
                Name = "EXOPolicyNeverExisted3";
                Comment = "MyComment2";
                RestrictiveRetention = $False;
                ModernGroupLocation = "All"; #in 1012 version is empty, in latest version empty
                ExchangeLocation = "All"; #in 1012 emtpy, in latest version empty
                Ensure = "Present";
                Enabled = $False;
                Credential = $AdminCred;
        }
        SCRetentionCompliancePolicy 'RetentionCompliancePolicyTeams'
        {
                Name = "TeamsPolicyNeverExisted3";
                Comment = "MyComment2";
                RestrictiveRetention = $False;
                TeamsChatLocation = "All"; #in 1012 emtpy, in latest version empty
                Ensure = "Present";
                Enabled = $False;
                Credential = $AdminCred;
        }
    }
}

Suggested solution to the issue

Add -force Parameter to the DSC res and use this with the Set-ComplianceRetentionPolicy cmd in the Set method

The operating system the target node is running
OsName : Microsoft Windows Server 2019 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture : 64-Bit
WindowsVersion : 1809
WindowsBuildLabEx : 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage : en-US
OsMuiLanguages : {en-US, de-DE}

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

[andikrueger]

Thanks for reporting. Would be good to get a better understanding of the impact of using force for this cmdlet.

[T630Dev]

Indeed. That's why I would recommend not to always use "force" but to add force as an additional parameter to the resource. That way, the end user of the DSC res would be able to assess and chose whether he wants to use force or not.

[NikCharlebois]

I am not a big fan of adding properties that don't implement idempotency to a resource. Allowing users to decide to use -Force makes sense in an imperative scenario where the user consciously decides to use the parameter when calling the cmdlet. In the case of DSC, the user defines how it wants the end-result configuration to be and DSC decides "on behalf of the user" how to get to it. If that means using the -Force parameter, then the resource's logic should use it without the user having to implicitly mention it.

In my opinion, even if there are pending actions being performed, if someone deploys a DSC configuration to overwrites these, the changes should be forced no matter what to achieve Desired State. Thoughts?

[T630Dev]

makes sense to me. If a new resource is created, we do not need the force.
If an existing res is altered, we always use the force parameter without offering a choice to the user.
In case the documentation mentions this it should not be a problem.
I also cannot think of a use case where you do not want to change your policy because of pending changes in a DSC scenario.

[NikCharlebois]

Will be submitting a PR for this shortly