Fluid Workplace FLUID WORKPLACE IT Deployment & Automation
← Retour au blog

Microsoft 365

New-MailboxExportRequest : Content Filter est invalide - Exchange Server

Cette cmdlet PowerShell est boguée et fonctionne uniquement avec les dates au format américain. Voyons comment contourner ce bug.

· Exchange Server, PowerShell, Microsoft, PST

Cette cmdlet PowerShell est boguée et fonctionne uniquement avec les dates au format américain. Voyons comment contourner ce bug !

Photo par Ethan Hoover / Unsplash

Lorsque vous essayez d’exporter vers un PST avec la cmdlet New-MailboxExportRequest, l’erreur suivante se produit :

The provided ContentFilter value is invalid. ContentFilter is invalid. The value "31/05/2012" could not be converted to type System.DateTime

Il s’avère que cette cmdlet PowerShell fonctionne uniquement avec les dates au format américain (MM/dd/yyyy) !

Vous pourriez être tenté de lui fournir une date avec ce format... Au début, elle l’acceptera, mais le job échouera rapidement. Il en résultera un état FailedOther. En investiguant plus loin avec cette commande :

Get-MailboxExportRequest | Get-MailboxExportRequestStatistics -IncludeReport | Ft Report -Wrap

Vous trouverez cette erreur :

Fatal error InvalidContentFilterPermanentException has occurred The attempt to deserialize failed for type: 'System.UnitySerializationHolder'

Cette erreur s’est produite parce que, oui, la cmdlet a accepté les paramètres, mais la session PowerShell s’exécute avec le format de date de la localisation configurée, qui n’est très probablement pas au format américain. PowerShell donnera donc à Exchange ce qu’il pense être une date valide dans sa culture actuelle, mais qui n’est en réalité pas dans sa culture. Bien sûr, Exchange ne peut pas traiter la date et échoue.

Ce bug étrange existe depuis Exchange 2010 et existe toujours dans Exchange 2019 actuel !

Comme nous sommes forcés d’utiliser la culture américaine par cette cmdlet, pour contourner cela, nous avons 3 choix :

  • Changer la culture du serveur en US... Merci Microsoft, mais non !
  • Changer la culture du thread PowerShell courant en US avec ces commandes :
[System.Reflection.Assembly]::LoadWithPartialName("System.Threading")
[System.Reflection.Assembly]::LoadWithPartialName("System.Globalization")
[System.Threading.Thread]::CurrentThread.CurrentCulture = [System.Globalization.CultureInfo]::CreateSpecificCulture("en-us")
  • Se connecter à distance avec PowerShell au serveur Exchange en changeant PSSessionOption pour utiliser la culture "en-US" :
$SessionOption = New-PSSessionOption -Culture 'en-US'
$PSSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https:///PowerShell/" -SessionOption $SessionOption

De cette façon, PowerShell fonctionne totalement avec la culture américaine, donc le serveur Exchange sera capable de reconnaître cette culture et de l’utiliser correctement.

Besoin d’un avis concret ?

Transformons le sujet en plan d’action.

Décrivez votre contexte et recevez une réponse claire sur les options possibles.

Demander une intervention Exchange