xExchMailboxDatabase [1.31.0]: All Parameters Have Type Errors
Closed this issue · 35 comments
Details of the scenario you tried and the problem that is occurring
I am probably missing something easy but it seems that all parameters of xExchMailboxDatabase return type errors. All other resources are working fine. For example:
Cannot process argument transformation on parameter 'Bool2'. Cannot convert value "System.Object[]" to type "System.Nullable`1[System.Boolean]". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
If we comment out boolean parameters, we see the same for TimeSpan:
Cannot process argument transformation on parameter 'TimeSpan'. Cannot convert value "System.Object[]" to type "Microsoft.Exchange.EnhancedTimeSpan".
If we comment out TimeSpan parameters, we see the same but referring to a string.
Verbose logs showing the problem
Logs for a boolean error:
VERBOSE: [CA1-TST-EX01]: LCM: [ Start Resource ] [[xExchMailboxDatabase]MXDB-CA1-2019]
VERBOSE: [CA1-TST-EX01]: LCM: [ Start Test ] [[xExchMailboxDatabase]MXDB-CA1-2019]
VERBOSE: [CA1-TST-EX01]: [[xExchMailboxDatabase]MXDB-CA1-2019] Entering function 'Test-TargetResource'. Notable parameters: Name = 'MXDB-CA1-2019'
VERBOSE: [CA1-TST-EX01]: [[xExchMailboxDatabase]MXDB-CA1-2019] Reusing existing Remote PowerShell Session to Exchange
Cannot process argument transformation on parameter 'Bool2'. Cannot convert value "System.Object[]" to type "System.Nullable`1[System.Boolean]". Boolean parameters accept only Boolean values and
numbers, such as $True, $False, 1 or 0.
At C:\source\TechnologyInfrastructure\dsc_output\Start-Configuration.ps1:31 char:5
Start-DscConfiguration -ComputerName $MachineId -Force -Wait -Pat ...~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- CategoryInfo : InvalidData: (:) [], CimException
- FullyQualifiedErrorId : ParameterArgumentTransformationError,Compare-BoolToBool
Cannot process argument transformation on parameter 'Bool2'. Cannot convert value "System.Object[]" to type "System.Nullable`1[System.Boolean]". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
Suggested solution to the issue
Any help would be appreciated.
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The configuration data for the databases is:
@{
NodeName = "CA1-TST-EX01"
DAGRole = "AdditionalDAGMember"
DAGID = "DAG1"
PrimaryDBList = @{
MBXDBCA1 = @{Name = 'MXDB-CA1-2019'; EdbFilePath = "M:\Data\MXDB-CA1-2019\MXDB-CA1-2019.edb"; LogFolderPath = "L:\Logs\MXDB-CA1-2019\MXDB-CA1-2019.log"};
}
CopyDBList = @{
MBXDBUK1 = @{Name = 'MXDB-UK1-2019'; ActivationPreference = 2; ReplayLagTime = '00:00:00'};
}
}
@{
NodeName = "UK1-TST-EX01"
DAGRole = "FirstDAGMember"
DAGID = "DAG1"
PrimaryDBList = @{
MBXDBUK1 = @{Name = 'MXDB-UK1-2019'; EdbFilePath = "M:\Data\MXDB-UK1-2019\MXDB-UK1-2019.edb"; LogFolderPath = "L:\Logs\MXDB-UK1-2019\MXDB-UK1-2019.log"};
}
CopyDBList = @{
MBXDBCA1 = @{Name = 'MXDB-CA1-2019'; ActivationPreference = 2; ReplayLagTime = '00:00:00'};
}
}
The resource is configured as follows:
foreach ($DB in $Node.PrimaryDBList.Values)
{
xExchMailboxDatabase $DB.Name
{
Name = $DB.Name
EdbFilePath = $DB.EdbFilePath
LogFolderPath = $DB.LogFolderPath
Server = $Node.NodeName
CircularLoggingEnabled = $true
IssueWarningQuota = "7GB"
ProhibitSendQuota = "Unlimited"
ProhibitSendReceiveQuota = "Unlimited"
DeletedItemRetention = "14.00:00:00"
MailboxRetention = "30.00:00:00"
AllowServiceRestart = $true
MountAtStartup = $true
DatabaseCopyCount = 4
Credential = $AdminCredentials
}
}
Exchange Server edition and version the target node is running
Exchange Server 2019 CU5 Enterprise
Version 15.2 (Build 595.3)
The operating system the target node is running
OsName Microsoft Windows Server 2019 Standard
OsOperatingSystemSKU StandardServerEdition
OsArchitecture 64-bit
WindowsVersion 1809
WindowsBuildLabEx 17763.1.amd64fre.rs5_release.180914-1434
OsLanguage en-US
OsMuiLanguages {en-US}
Version and build of PowerShell the target node is running
PSVersion 5.1.17763.1007
BuildVersion 10.0.17763.1007
Version of the DSC module that was used
xExchange 1.31.0 C:\Program Files\WindowsPowerShell\Modules\xExchange\1.31.0\xExchange.psd1
Hi @mhendric,
actually all of my changes in the last month or so are getting released as preview. 1.32.0-preview004 is the latest. I think you should set a tag in the git commit, in order to do an official 'release'. So this bug refers to version 1.31.0, which is the version we released after moving to Azure DevOps.
Hi @SSvilen,
Yeah, we can try that. Will take a bit to get this set up in our test environment but will let you know how it goes.
thanks @acstyche. I'll try it tonight in my home lab too (althought I have run the integration tests and they were all successful )
That definitely has to do with version 1.31 - the Get-MailboxDatabaseInternal has a bug and it gives back all databases - that's why it#s complaining that it can not covert an array (System.Object[]) to Bool or timespan or whatever.
@mhendric - do you think we can now release version 1.32?
Thanks a lot for the update @SSvilen! We have added the preview version to our ProGet (which brought up some PowerShellGet versioning issues and will need some environment tweaks). Will hopefully be able to test today and let you know how it goes.
@SSvilen, yes, 1.3.2 worked for xExchMailboxDatabase!
However, was something changed with xExchSendConnector? It was working fine but is now throwing an error on set:
VERBOSE: [CA1-TST-EX01]: [[xExchSendConnector]ProductionExchange] Creating send connector mail.orbis.com Production Exchange.
Saying "The object...already exists." Shouldn't the test have detected this?
VERBOSE: [CA1-TST-EX01]: [[xExchSendConnector]ProductionExchange] Send Connector should exist, but does not.
@SSvilen , to be honest, I'm not sure what the release cadence for official releases is supposed to be any more. I don't see an issue, other than that if the latest build has a major bug in xExchSendConnector, we may want to resolve that first. Adding @johlju and @gaelcolas for insight on when/how to do a new release.
@mhendric you as a maintainer decide when to release a full version. The pipeline now uses continuous delivery so every merge to master will release a new preview version. To release a full release a tag should be pushed, see the Release section in the maintainer guidelines https://dsccommunity.org/guidelines/maintaining/
Hello all,
Just as an update, we pointed back to 1.31.0 and xExchSendConnector ran successfully again.
Please let me know if you need any more information.
Actually, subsequent applications of xExchSendConnector fail in 1.31.0. Even using a previously successful deployment. But only on the first server in the deployment. The deployment succeeds on the second server, with both having the same settings.
The error is different than the one in 1.32.0-preview004. Do you want me to create a new issue or post the logs here?
Hi @acstyche ,
please open another problem tracker for the send connector. But tbh I'm using send connector resource in production and never faced any problems. May be there is a problem with one of your servers?
I'll check exactly what I have as configurations in my prod and test env and which version of xExchange I'm using.
let's wait and see if the send connector also has a problem in it and then you can decide whether to publish a new version or not.
Haha...yes, given the amount of changes to the server while testing, that is actually very likely. It does work on the other servers on 1.31.0. Not on 1.32.0-preview004.
We are going to remove Exchange from that server and revert it to a base image to start again. Will open a new issue if necessary.
Thanks.
So the mailboxdatabase resource is working fine for you now? And the problem with the send connector resource is what you mentioned in #452 ? No other problems observed on your side?
I'll open today 2 PRs, which contain only one-line changes and I believe we should publish version 1.32 officially.
I can not reproduce the problem you are experiencing. Just created (and tested) new send connector with the latest version. Can you show me your config?
Sure:
xExchSendConnector ProductionExchange
{
Name = $Node.ProdSendConnector
Ensure = "Present"
AddressSpaces = $Node.ProdAddressSpace
ConnectionInactivityTimeout = "00:10:00"
ConnectorType = "Default"
DNSRoutingEnabled = $false
DomainSecureEnabled = $false
Enabled = $true
ErrorPolicies = "Default"
ForceHELO = $false
FrontendProxyEnabled = $false
IgnoreSTARTTLS = $false
IsScopedConnector = $false
MaxMessageSize = $Node.MaxMessageSize
Port = "25"
ProtocolLoggingLevel = "None"
RequireTLS = $false
SmartHostAuthMechanism = "None"
SmartHosts = $Node.SmartHosts
SmtpMaxMessagesPerConnection = "20"
SourceIPAddress = "0.0.0.0"
SourceTransportServers = $Node.SourceTransport
UseExternalDNSServersEnabled = $false
Credential = $AdminCredentials
}
You can see the test doesn't detect it:
VERBOSE: [CA1-TST-EX01]: [[xExchSendConnector]ProductionExchange] Importing function 'Get-SendConnector'.
VERBOSE: [CA1-TST-EX01]: [[xExchSendConnector]ProductionExchange] Send Connector should exist, but does not.
VERBOSE: [CA1-TST-EX01]: LCM: [ End Test ] [[xExchSendConnector]ProductionExchange] in 2.0710 seconds.
But then it tries to create it and fails because it's already there:
VERBOSE: [CA1-TST-EX01]: [[xExchSendConnector]ProductionExchange] Importing function 'Set-SendConnector'.
VERBOSE: [CA1-TST-EX01]: [[xExchSendConnector]ProductionExchange] Creating send connector mail.orbis.com Production Exchange.
Active Directory operation failed on DC-VC1.ad.orbis.im. The object 'CN='I removed the name' already exists.
Sorry, just to add this does not happen in 1.31.0.
what happens when you do:
$name = 'mail.orbis.com Production Exchange'
Get-SendConnector -ErrorAction SilentlyContinue | Where-Object -Property 'Identity' -eq $Nameon that CA1-TST-EX01 server?
P.S. - the name of the send connector is still in verbose output :)
I'll git the new preview version a try tomorrow in my test env at work and if case of problems, I'll just open a PR.
Hi @SSvilen, will give that a try tomorrow.
The name of the resource is in verbose, the name of the actual send connector contains our domain info, so was removed.
Hi @SSvilen, that returns the send connector, as expected. If you can't reproduce the issue, I'm fine with moving forward with 1.32.0. It is probably something squirrelly with our config we need to dig into. We also aren't too concerned with xExchSendConnector, xExchMailboxDatabase is much more important.
Thanks for taking a look!
OK @acstyche, the other thing you can try is to debug the DSC config. link
That way you can see what exaclty get-targetresource returns and why the test-targetresource is failing.
I've tested the new preview - the commit for xExchAddressList was not included, but otherwise everything works as expected.
@johlju , I just created a new tag via the Release instructions in the Maintainer Guidelines. Can you confirm whether everything has been done correctly for this release? Not sure if I need to manually combine the Added / Changed notes from all the previews, or if automation will handle that. Also not sure if I need to do anything for this to be pushed to PowerShellGallery.
You can follow the build here https://github.com/dsccommunity/xExchange/commits/master on the latest commit. It starts with an orange dot and then goes to a green checkmark when all the pipeline steps have ran. The pipeline will make a github release, and deploy to the gallery automatically. It will also get the correct change log entries into the releases. It will finally send a PR with the update change log.
In this case one of the deploy steps failed (red x). I'm looking at why. If you click on the red x you can click your way to the Azure Pipeline and see what happened.
Scratch that. It runs https://dev.azure.com/dsccommunity/xExchange/_build/results?buildId=1989&view=results
Not sure why I can't see it from the commit history on master (as mentioned above)
Ah the previous build failed on the deploy step for that commit, that is why is shows a red x instead of the orange dot. Hopefully the deploy step will pass once the release build you triggered gets to the deploy step. Currently it is running tests.
Thanks @johlju ! The steps to do a Release felt almost too simple. I thought I had to be missing something :)
It is very simple and fast to release now! 😄
Thanks a lot all! Hoping to test the release today or tomorrow.
All looks good, thanks a lot for getting this sorted.