# 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.

Auteur : Frédéric Gilson

Date : 2023-10-24

Catégorie : Microsoft 365

Étiquettes : Exchange Server, PowerShell, Microsoft, PST

Source : https://test.fluidworkplace.be/blog/new-mailboxexportrequest-content-filter-invalide-exchange-server.html

![Enveloppe kraft et feuille blanche posées sur une surface claire.](https://test.fluidworkplace.be/static/assets/blog/messagerie-1440.491ef1dc71fa.webp)

Photo : [Kate Macate](https://unsplash.com/@katemacate) / [Unsplash](https://unsplash.com/photos/white-paper-and-brown-envelope-xmddEHyCisc).

**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](https://images.unsplash.com/photo-1508769941802-a6ca19d19e08?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDQ2fHxzZXJ2ZXIlMjBtYWlsfGVufDB8fHx8MTY5ODEzNzE2NHww&ixlib=rb-4.0.3&q=80&w=2000)

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

```text
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 :

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

Vous trouverez cette erreur :

```text
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 :

```powershell
[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"` :

```powershell
$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.

[Demander une intervention Exchange](/contact.html)