Multiple resources failing to return correct result on test
modfh98 opened this issue · 11 comments
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
@modfh98 , I think this relates to the latest Security Updates (SU) changes. In the last one posted here:
Microsoft has enabled Powershell Serialization by default. These have brought some known issues that are listed here:
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 ?
@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?
🤞
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?
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?
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,
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,
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 -ForceGet-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument RefreshRunspaceId : 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?
@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.
I am not an expert in Exchange, so I cannot comment on the cause. This is why for example the ExchMailboxDatabase resource doesn't work anymore:
The object type of some values has been changed, probably because of what @mhincapie explained above. In
PathName property which does not exist anymore as $db.LogFolderPath is a string.
The same happens here:
- .
The solution would be to change the code so that is uses the value stored in the property PathName if that property exist, otherwise it uses the value of $db.LogFolderPath.
@gborus, can you give it a try and change these 3 lines, please?
Given the fact that there has been no feedback so far, is ExchangeDsc still being used at all?
Hi @raandree , the suggested solution would solve this particular problem, although this would mean all resources' script would need to be review line by line to spot similar problems, not mentioning cases like the DB copies' activation preference query which data is available at the 3rd level, like database.databasecopies.activation preference, which data gets lost when database.databasecopies gets converted to string. And the trick with this value, activation preference, that it is really hard to collect it from elsewhere other than the get-mailboxdatabase cmdlet.
thanks,