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.
Cette cmdlet PowerShell est boguée et fonctionne uniquement avec les dates au format américain. Voyons comment contourner ce bug !
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.DateTimeIl 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 -WrapVous 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
PSSessionOptionpour utiliser la culture"en-US":
$SessionOption = New-PSSessionOption -Culture 'en-US'
$PSSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https:///PowerShell/" -SessionOption $SessionOptionDe 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.