New-M365DSCReportFromConfiguration: en dash in EXOGroupSettings DisplayName causes DSCParser exception

[nick-waterhouse]

Description of the issue

While attempting to create a report for a configuration, I received similar exceptions to those in the verbose logs.

I was able to reduce the configuration down to the one in the DSC configuration section, where the configuration reliably caused an exception.

My script is as follows:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine

$NetConnection = Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceAlias $NetConnection.InterfaceAlias -NetworkCategory "Private"
winrm quickconfig

New-M365DSCReportFromConfiguration -type html -ConfigurationPath ..\Reports\source.psd -OutputPath ..\Reports\report.html

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

Strangely, the culprit is having the DisplayName contain an en dash, such as "Group – name" - I expect other characters, such as em dash, would behave similarly. If I replace this character with a regular minus character, or remove it completely, the report is successfully created.

I can confirm that my dependencies are up to date, and that I am running this in an elevated terminal.

Is there anything that can be done here?

Microsoft 365 DSC Version

V1.24.1016.1

Which workloads are affected

Exchange Online

The DSC configuration

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

Configuration Microsoft365TenantConfigExport-tenant.onmicrosoft.com-2024-09-17
{
    param (
        [parameter()]
        [System.Management.Automation.PSCredential]
        $Credential
    )

    if ($null -eq $Credential)
    {
        <# Credentials #>
        $Credscredential = Get-Credential -Message "Credentials"

    }
    else
    {
        $CredsCredential = $Credential
    }

    $OrganizationName = $CredsCredential.UserName.Split('@')[1]

    if ($null -eq $Credential)
    {
        <# Credentials #>
    }
    else
    {
        $CredsCredential = $Credential
    }

    $OrganizationName = $CredsCredential.UserName.Split('@')[1]

    Import-DscResource -ModuleName 'Microsoft365DSC' -ModuleVersion '1.24.904.1'

    Node localhost
    {
        EXOGroupSettings "Test Name"
        {
            AccessType                             = "Public";
            AlwaysSubscribeMembersToCalendarEvents = $False;
            AuditLogAgeLimit                       = "90.00:00:00";
            AutoSubscribeNewMembers                = $False;
            ConnectorsEnabled                      = $True;
            Credential                             = $Credscredential;
            CustomAttribute1                       = "";
            CustomAttribute10                      = "";
            CustomAttribute11                      = "";
            CustomAttribute12                      = "";
            CustomAttribute13                      = "";
            CustomAttribute14                      = "";
            CustomAttribute15                      = "";
            CustomAttribute2                       = "";
            CustomAttribute3                       = "";
            CustomAttribute4                       = "";
            CustomAttribute5                       = "";
            CustomAttribute6                       = "";
            CustomAttribute7                       = "";
            CustomAttribute8                       = "";
            CustomAttribute9                       = "";
            DisplayName                            = "Group–name";
            EmailAddresses                         = @("SPO:SPO_076bc706-8bdf-4a49-9402-eb045b8c47e1@SPO_3e26c7b7-e5f0-44a2-b10d-c2eddac91f62","smtp:groupforanswersinvivaengagedonotdelete1823809462b81@tenant.onmicrosoft.com","smtp:groupforanswersinvivaengagedonotdelete1823809462@tenant.onmicrosoft.com","SMTP:groupforanswersinvivaengagedonotdelete1823809462@$OrganizationName");
            HiddenFromAddressListsEnabled          = $False;
            HiddenFromExchangeClientsEnabled       = $False;
            Id                                     = "groupforanswersinvivaengage_78de5c5f-5398-4387-a549-b9493af29acd";
            InformationBarrierMode                 = "Open";
            Language                               = "en-US";
            MaxReceiveSize                         = "36 MB (37,748,736 bytes)";
            MaxSendSize                            = "35 MB (36,700,160 bytes)";
            ModerationEnabled                      = $False;
            Notes                                  = "Group that stores content and metadata for Answers in Viva Engage in network 1823809. Deleting this this group will disrupt Answers in Viva Engage.";
            PrimarySmtpAddress                     = "groupforanswersinvivaengagedonotdelete1823809462@$OrganizationName";
            RequireSenderAuthenticationEnabled     = $True;
            SubscriptionEnabled                    = $False;
            TenantId                               = "tenant.onmicrosoft.com";
        }
    }
}

Microsoft365TenantConfigExport-tenant.onmicrosoft.com-2024-09-17 -ConfigurationData .\ConfigurationData.psd1 -Credential $Credential

Verbose logs showing the problem

Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\DSCParser\2.0.0.11\Modules\DSCParser.psm1:548 char:9
	+         $resourceType         = $resource.CommandElements[0].Value                                                      
	+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                          
	+ CategoryInfo          : InvalidOperation: (:) [], RuntimeException                                                      
	+ FullyQualifiedErrorId : NullArray       
	
Cannot index into a null array.                                                                                           
At C:\Program Files\WindowsPowerShell\Modules\DSCParser\2.0.0.11\Modules\DSCParser.psm1:549 char:9                        
	+         $resourceInstanceName = $resource.CommandElements[1].Value                                                      
	+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                          
	+ CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray

Cannot index into a null array.
At C:\Program Files\WindowsPowerShell\Modules\DSCParser\2.0.0.11\Modules\DSCParser.psm1:562 char:35
+ ... foreach ($keyValuePair in $resource.CommandElements[2].KeyValuePairs)
+                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + 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]

That sounds very strange, but somehow I expected something like that. The culprit here might be the fact that en dash is a Unicode character and not all Unicode characters might be available… I‘ll take a look at it if I have time.

[ricmestre]

@FabienTschanz This is a known issue, check out #4824

[FabienTschanz]

Uhmm, "it works on my machine" 😓 Will dig a bit deeper.

[FabienTschanz]

@nick-waterhouse Quick question: Are there multiple versions of Microsoft365DSC installed? Get-Module Microsoft365DSC -ListAvailable. I just had a colleague with the same error message (although without the em dash), and updating the latest version with uninstalling all outdated versions using Update-M365DSCModule solved the issue for him.

[nick-waterhouse]

@FabienTschanz Just the one version for me. Output is as follows:

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Manifest   1.24.1016…            Microsoft365DSC                     Desk      {Assert-M365DSCBlueprint, Compare-M365DSCConfigurations, Confirm-M365DSCDependencies, Export-M365DSCConfiguration…}

[FabienTschanz]

Is the issue still present? I'm unable to reproduce it.

[nick-waterhouse]

It appears to be. I get the following when running against the current version of M365DSC:

Error parsing configuration: At line:68 char:63
+             DisplayName                            = "Group–name";
+                                                               ~~~~~~
Unexpected token 'name";
            EmailAddresses                         = @("SPO:SPO_076bc706-8bdf-4a49-9402-eb045b8c47e1@SPO_3e26c7b7-e5f0-44a2-b
10d-c2eddac91f62","smtp:groupforanswersinvivaengagedonotdelete1823809462b81@tenant.onmicrosoft.com","smtp:groupforanswersinvi
[email protected]","SMTP:groupforanswersinvivaengagedonotdelete1823809462@$OrganizationNam
e");
            HiddenFromAddressListsEnabled          = $False;
            HiddenFromExchangeClientsEnabled       = $False;
            Id                                     = "groupforanswersinvivaengage_78de5c5f-5398-4387-a549-b9493af29acd";
            InformationBarrierMode                 = "Open";
            Language                               = "en-US";
            MaxReceiveSize                         = "36' in expression or statement.
At C:\Program Files\WindowsPowerShell\Modules\DSCParser\2.0.0.15\Modules\DSCParser.psm1:472 char:9
+         throw "$($errorPrefix)Error parsing configuration: $parseErro ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Error parsing c...n or statement.:String) [], RuntimeException
    + FullyQualifiedErrorId : Error parsing configuration: At line:68 char:63
+             DisplayName                            = "Group–name";
+                                                               ~~~~~~
Unexpected token 'name";
                EmailAddresses                         = @("SPO:SPO_076bc706-8bdf-4a49-9402-eb045b8c47e1@SPO_3e26c7b7-e5f0-4
   4a2-b10d-c2eddac91f62","smtp:groupforanswersinvivaengagedonotdelete1823809462b81@tenant.onmicrosoft.com","smtp:groupfora
  [email protected]","SMTP:groupforanswersinvivaengagedonotdelete1823809462@$
 OrganizationName");
            HiddenFromAddressListsEnabled          = $False;
            HiddenFromExchangeClientsEnabled       = $False;
                Id                                     = "groupforanswersinvivaengage_78de5c5f-5398-4387-a549-b9493af29acd";

            InformationBarrierMode                 = "Open";
            Language                               = "en-US";
            MaxReceiveSize                         = "36' in expression or statement.

[FabienTschanz]

Alright. Can you share the bit of your configuration that's failing? This seems very much like #5848 that I opened today because those double quotes are not the "standard" ones. If I have the configuration, I'll be able to check against my environment with an export and if the PR does what it's supposed to and escape those "fancy" double quotes as we're calling them.

[nick-waterhouse]

I believe the configuration is the sample one I included in this ticket. The problematic bit is the line:
DisplayName = "Group–name";
If I replace it with DisplayName = "Group-name";, where the dash is a hyphen rather than an en- or em-dash, the report is created correctly.

[FabienTschanz]

Now I see. So the en-dash is silently converted into that "ugly-looking" – bit, correct? What's the encoding of the file if you check it e.g. using VS Code or Notepad++? Is it UTF-8 or anything different? You're executing it in PS5.1, right?

Edit: Yeah, using Windows PowerShell and UTF-8 encoding it fails for me as well. The solution is to save it as UTF-16, or a specific import of the file using Get-Content XXX -Encoding utf8. That solves it as well. I'll check what we can do.

[nick-waterhouse]

The error message looks a lot more comprehensive than what was there before, but yes, it does seem like the en-dash is being converted into –.

Notepad++ claims the PSD I am using is UTF-8 encoded, and I can confirm I am running in a PS5.1 admin session.

Edit: Looking at your edit, it might be a fairly easy workaround to convert the files to UTF-16 before creating reports or comparing configs. Given that the configs are straight exports from M365DSC, would it be possible for Export-M365DSCConfiguration to default to a UTF-16 encoding?

Edit 2: To be exact, Notepad++ is claiming UTF-8 but with no BOM. Is it possible that New-M365DSCReportFromConfiguration is loading the file as ASCII in this case?

[FabienTschanz]

The issue isn't directly related to the file "only" being UTF-8, rather it's because Windows PowerShell uses a different code page (namely Windows-1252, a subset of UTF-8). This means that characters outside of the ASCII range won't be properly handled by Windows PowerShell unless we can somehow configure the default behavior of the terminal. I believe this would be $OutputEncoding or something like that.

PowerShell 7 isn't affected by that because it doesn't use Windows-1252 anymore but rather UTF-8. So no problems there. Checking how we can change the behavior of that so that the default isn't Windows-1252 but rather UTF-8.

[FabienTschanz]

@nick-waterhouse Can you do me a favor please? Save the file again as UTF-8, just as it was before. Then, set the following registry item:

Key: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
Name: ACP
Value: 65001

After that, restart your PowerShell 5.1 session and try to compile the configuration or even generate a report. It should work now.

Alternatively if modifying the registry isn't an option, you can set the following setting in the international language settings intl.cpl:

[nick-waterhouse]

@FabienTschanz Changing that setting did the trick - report was created as expected! I'll keep an eye out as I continue using M365DSC and update if similar errors popup, but I suspect this intervention has cleaned up a whole class of problems.

[FabienTschanz]

@nick-waterhouse Thank you very much for the confirmation. I'll shortly open a PR that adds a warning message if this setting is not configured.