Multiple resources failing to return correct result on test

[modfh98]

Hi,

Is anyone aware of any recent changes (possibly November updates) that have started causing issues with this module? We've been using it for some time and I've recently noticed there are multiple resources where the test-targetresource function is continually returning as false. I've started looking further into the ExchExchangeCertificate resource which is one of them but the others listed below are also failing to test correctly on each run
My initial thoughts are that it might be something to do with how it's comparing arrays, but I haven't been able to determine anything conclusive yet. I can start digging further if needs be but I'm wondering if this is a known problem before I do so?

ExchReceiveConnector
ExchOutlookanywhere
ExchDatabaseAvailabilityGroupMember
ExchAutoMountPoint
ExchMailboxDatabase
ExchMailboxDatabaseCopy

[mhincapie]

@modfh98 , I think this relates to the latest Security Updates (SU) changes. In the last one posted here:

• https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2023-exchange-server-security-updates/ba-p/3980209

Microsoft has enabled Powershell Serialization by default. These have brought some known issues that are listed here:

• https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-serialization-payload-sign?view=exchserver-2019#known-issues-with-certificate-signing-of-serialized-data

We utilize this Powershell module quite often. Do you also? We could try to see if we can modify the code so it's compatible with Powershell serialization. What do you think? also, do you have any suggestions @johlju ?

[modfh98]

@mhincapie
The article suggests that the problem is mainly affecting piped cmdlets on management tools boxes, but I think you're right and this has had some other effects. It was also my suspicion. They have mentioned that MS is working on a fix.. so maybe this will be sorted next round of updates?
🤞

[johlju]

Awesome that you help each other finding the cause, I wouldn't have know about this, thanks @mhincapie. If you see the fix from MS i dragging out I'm happy to review a PR that uses the suggested workaround.

@modfh98 maybe you can change the code, according to the suggested workaround, locally for one of the resources (suggest take the simplest one) on one of your nodes just to verify that it actually quick-fixes the problem?

[DelectableMechanisations]

Did anyone have any success implementing a workaround for this?

I spent several hours troubleshooting the ExchExchangeCertificate resource with DSC Debug enabled but wasn't able to make any headway.
When I stepped in via the debugger, I got through to the point where the Get-ExchangeCertificate command is called and found it was returning an object of type:
Deserialized.Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificate

I could successfully convert this object into the standard certificate type:
System.Security.Cryptography.X509Certificates.X509Certificate2
And this allowed me to read the standard properties (Thumbprint, NotAfter, Subject etc).

But I wasn't able to convert it back into its correct type:
Microsoft.Exchange.Management.SystemConfigurationTasks.ExchangeCertificate

Thus, the object was missing the "Services" property was what was causing the Test-TargetResource to fail.
Without the "Services" property, you can't use this resource to bind a certificate to any services (IIS, IMAP etc) so I've had to comment out all sections of my configuration document that relate to ExchExchangeCertificate.

Like @modfh98, I've had issues with some of the resources they referenced including:

• ExchReceiveConnector - Cannot process property ExtendedRightAllowEntries
• ExchOutlookAnywhere - Cannot process properties InternalHostname and ExternalHostname

I haven't done any significant troubleshooting for these so it's possible there's a simpler workaround for these.

When I disabled certificate signing of PowerShell serialization payloads using the method below, this problem disappeared.
https://learn.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/security-best-practices/exchange-serialization-payload-sign?view=exchserver-2019#disable-certificate-signing-of-powershell-serialization-payloads

We enabled certificate signing of PowerShell serialization payloads back in February 2023 and it's been a problem ever since.
I am seriously considering abandoning using DSC for Exchange as my configuration document is going to be full of commented out sections of code for resources that no longer work.

I would have thought Microsoft would have invested some more time in maintaining this resource.
What does Microsoft use to configure its fleet of Exchange Online servers? Surely DSC is the most efficient way to keep the configuration aligned across their Exchange Online fleet.
Or do they have another tool for that?

[gborus]

I have the same concern, was expecting MSFT fix the serialization issue by now.
Many folks using DSC for building and maintaining Xch servers, which is not possible using the module anymore.

Is there any timeline for the SU issue fix, does anybody know?

thanks,

[gborus]

Do you guys know if there is any MSFT internal discussion how the DSC issue caused by ps payload siging will be solved or will be solved at all?
Many thanks,

[raandree]

I am trying to get into this a bit more and need a very simple configuration to start with. So far I cannot reproduce the issue. At the very top it is mentioned that the issue affects the resource ExchReceiveConnector. This configuration is running fine on an Exchange Server 2019 CU14 with EnableSigningVerification.

configuration c1 {

    Import-DscResource -ModuleName ExchangeDsc

    $cred = New-Object pscredential('contoso\install', ('Somepass1' | ConvertTo-SecureString -AsPlainText -Force))

    node localhost {
        ExchReceiveConnector rc1 {
            Identity = 'MSEEx1\rc1'
            Credential = $cred
            Ensure = 'Present'
            Bindings = '0.0.0.0:2525'
            RemoteIPRanges = '192.168.0.1-192.168.0.24'
            Usage = 'Custom'
        }
    }
}

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

c1 -OutputPath c:\dsc -ConfigurationData $cd

Start-DscConfiguration -Path C:\dsc -Wait -Verbose -Force

Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh

RunspaceId  : 125eeb6d-1eb2-4362-9bd5-854356340c77
Result      : <Diagnostics>
                <ProcessInfo>
                  <id>6052</id>
                  <serverName>MSEEx1</serverName>
                  <startTime>2024-05-25T07:55:31.7262229Z</startTime>
                  <currentTime>2024-05-25T08:09:32.9996174Z</currentTime>
                  <lifetime>00:14:01.2733945</lifetime>
                  <threadCount>16</threadCount>
                  <handleCount>1317</handleCount>
                  <workingSet>132.9 MB (139,321,344 bytes)</workingSet>
                  <fastTrainExchangeVersion>15.2.1544.4</fastTrainExchangeVersion>
                </ProcessInfo>
                <Components>
                  <VariantConfiguration>
                    <Overrides Updated="2024-05-25T08:09:33.0056164Z">
                      <SettingOverride>
                        <Name>EnableSigningVerification</Name>
                        <Reason>Enabling Signing Verification</Reason>
                        <ModifiedBy>contoso.com/Users/Install</ModifiedBy>
                        <ComponentName>Data</ComponentName>
                        <SectionName>EnableSerializationDataSigning</SectionName>
                        <Status>Accepted</Status>
                        <Message>This override synced to the server but whether it applies to the services running on
              this server depends on the override parameters, current configuration and the context.</Message>
                        <Parameters>
                          <Parameter>Enabled=true</Parameter>
                        </Parameters>
                      </SettingOverride>
                    </Overrides>
                  </VariantConfiguration>
                </Components>
              </Diagnostics>
Identity    :
IsValid     : True
ObjectState : New

What do I need to do to run into the issue?

[raandree]

@modfh98, is this issue also happening on Exchange 2019 CU14 or only with Exchange 2016? On Exchange 2019 CU14 everything works just fine for me.