When you are trying to export to PST with the New-MailboxExportRequest cmdlet, the following error occur :The provided ContentFilter value is invalid. ContentFilter is invalid. The value "31/05/2012" could not be converted to type System.DateTime
It turns out this PowerShell Cmdlet only works with US formatted date (MM/dd/yyyy) !
You might be tempted to feed it a date with that format... At first, it will take it but the job will quickly fail. It will result in a
FailedOther state. When investigating further with this command :
Get-MailboxExportRequest | Get-MailboxExportRequestStatistics -IncludeReport | Ft Report -Wrap
You will find this error :Fatal error InvalidContentFilterPermanentException has occurred The attempt to deserialize failed for type: 'System.UnitySerializationHolder'
This error happened because, yes the cmdlet accepted the parameters, but the PowerShell session runs with the configured location (culture) date format which is most likely not in US format. So, PowerShell will give to Exchange what it thinks is a valid date in its current culture but it's actually not in his culture. Of course, Exchange can't process the date and fail.
This weird bug exists since Exchange 2010 and is still in existence in current Exchange 2019 !
Since we are forced to use US culture by this cmdlet, to work around that, we have 3 choice :
- Change the server culture to US... Thanks Microsoft but no !
- Change current PowerShell thread culture to US with those commands :
[System.Reflection.Assembly]::LoadWithPartialName("System.Threading") [System.Reflection.Assembly]::LoadWithPartialName("System.Globalization") [System.Threading.Thread]::CurrentThread.CurrentCulture = [System.Globalization.CultureInfo]::CreateSpecificCulture("en-us")
- Connect remotely with PowerShell to the Exchange Server while changing PSSessionOption to use "en-US" culture
$SessionOption = New-PSSessionOption -Culture 'en-US' $PSSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://<ExchangeServer>/PowerShell/" -SessionOption $SessionOption
That way, PowerShell works totally with the US culture so the Exchange Server will be available to recognize that culture and use it correctly.
This article is a summary of these informations :