Compare-M365DSCConfigurations: Export produces configurations that cannot be compared

[nick-waterhouse]

Description of the issue

If I run the following code with the attached files, I get the following result:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine
$NetConnection = Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceAlias $NetConnection.InterfaceAlias -NetworkCategory "Private"
winrm quickconfig

$delta = Compare-M365DSCConfigurations -Source ".\source.psd" -Destination ".\dest.psd"   
$delta | ConvertTo-Json -Depth 100 | Set-Content -Path ".\Diff-$(get-date -f yyyy-MM-dd).json"

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
Set-NetConnectionProfile -InterfaceAlias $NetConnection.InterfaceAlias -NetworkCategory $NetConnection.NetworkCategory

{
    "ResourceName":  "ODSettings",
    "Key":  "IsSingleInstance",
    "KeyValue":  "Yes",
    "Properties":  [
                       {
                           "ValueInDestination":  null,
                           "ParameterName":  "NotifyOwnersWhenInvitationsAccepted",
                           "ValueInSource":  false
                       }
                   ],
    "ResourceInstanceName":  "ODSettings"
}

So far, so good. This is the correct result - the NotifyOwnersWhenInvitationsAccepted property is not in the destination file. The problem is that I had to modify the two files to make this work.

By default, exported configurations, for me at least, begin as follows:

# Generated with Microsoft365DSC version 1.25.115.1
# For additional information on how to use Microsoft365DSC, please visit https://aka.ms/M365DSC
param (
    [parameter()]
    [System.Management.Automation.PSCredential]
    $Credential
)

Configuration Microsoft365TenantConfigExport-tenant.onmicrosoft.com-2025-01-21
{
    param (
        [parameter()]
        [System.Management.Automation.PSCredential]
        $Credential

        [parameter()]
        [System.Management.Automation.PSCredential]
        $Credential
    )

    <# Rest of config #>
}

See how the Credential parameter is included twice in that second param block? There is no comma separating the two either.

If I leave both files with that second parameter, the comparison code I included above fails to produce any output and produces the error in the verbose logs section (as found in the $Error variable). If only one of the files is correct, I get the following (just swap Absent and Present depending on whether it is the source or destination file that is correct):

{
    "ResourceName":  "ODSettings",
    "Key":  "IsSingleInstance",
    "KeyValue":  "Yes",
    "Properties":  [
                       {
                           "ValueInDestination":  "Absent",
                           "ParameterName":  "_IsInConfiguration_",
                           "ValueInSource":  "Present"
                       }
                   ],
    "ResourceInstanceName":  "ODSettings"
}

 
This is subtly wrong, as it implies the ODSettings resource is missing in the destination, when the underlying problem is that the entire configuration could not be parsed. The wider issue is that Compare-M365DSCConfigurations fails silently in this case and provides no indication that something has gone wrong, meaning that configuration changes can be easily missed.

The workaround is easy: it is only necessary to tidy up the erroneous param block to have a single $Credential parameter, after which things appear to work as they should. Having said that, I though it worth reporting as others may be experiencing this problem with configuration comparisons.

I can confirm that I have the latest version of M365DSC and am running in an administrative PowerShell 5.1 session.

dest.psd.txt
source.psd.txt

Microsoft 365 DSC Version

1.25.115.1

Which workloads are affected

OneDrive for Business

The DSC configuration

Verbose logs showing the problem

Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\DSCParser\2.0.0.14\Modules\DSCParser.psm1:520 char:9
+         $resourceInstances = $Config.Body.ScriptBlock.EndBlock.Statem ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

Environment Information + PowerShell Version

OsName               : Microsoft Windows 11 Enterprise
OsOperatingSystemSKU : EnterpriseEdition
OsArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 22000.1.amd64fre.co_release.210604-1628
OsLanguage           : en-GB
OsMuiLanguages       : {en-GB, en-US}

[FabienTschanz]

@nick-waterhouse The double credential parameter sounds really weird. Can you provide the command line used for the export? What happens if you e.g. use a application id with a secret for the same purpose? Does it show the parameters doubled as well?

Will take a look at the Compare function.

[FabienTschanz]

@nick-waterhouse PR #5659 is open which addresses your concerns about the comparison if an invalid configuration is encountered.

[nick-waterhouse]

@FabienTschanz The command line I am using is this: Export-M365DSCConfiguration -TenantId $TenantId -Path $outputDirPath -FileName $outputFileName -Components $components -Credential $credential.

Looking at the old configuration exports, it seems like all of them exhibit the doubled parameter, going back to April of last year when I started using M365DSC.

I'm afraid I don't have the bandwidth to set up an App Registration for this right now, but I'll report back if I try this out.

Many thanks for the PR - I'll give this one a go with next month's exports.

[FabienTschanz]

Interesting behavior, but I‘m unable to reproduce it. Works without any issues on my end, so I‘m not really sure where to start here. No worries about the app registration, take your time. I don’t think it‘s gonna change anything though. Will take another look tomorrow, but I don‘t think I‘ll succeed in finding the culprit here unfortunately.

[nick-waterhouse]

@FabienTschanz Thanks for your help with this one. Feel free not to spend any more time on this. The workaround is good enough for now, and if I get a chance I'll see if I can dig into why this went down.