New-MailboxExportRequest fails when content filter is used with non-US date formats

There seems to be a bug when using the New-MailboxExportRequest cmdlet in Exchange 2010 and specifying a content filter using dates in non-US format.

The only solution I've found is to change the region format to US before running the Exchange Management Shell, then change it back (after launching EMS or after running your script/cmdlet).

Here's the detail:

Exchange 2010 has a new two-step method of exporting mailbox data to PST using the New-MailboxExportRequest cmdlet.  A user with the right permissions creates the export request and the Mailbox Replication Service on a CAS server uses the information in the request to export the data.

The user who runs the cmdlet must have the 'Mailbox Import Export' role and you'll probably want to create a new role group for this.

In the parameters of the cmdlet the content filter is specified with a date range.  If you use a variable for the dates you may find that you need to use double-quotes for the content filter instead of curly brackets like so:

New-MailboxExportRequest -Mailbox "Test User" -FilePath "\\Server\Share\TestUser.pst" -ContentFilter "(Received -lt '$DateRangeEnd') -and (Received -ge '$DateRangeStart')"

If the region format of the computer running the script uses a non-US date format (e.g. Australian or English : DD/MM/YYYY) then the cmdlet converts the input to the local format when it is run.  Unfortunately the MRS converts the format to US when it runs.  When the day is greater than 12 the cmdlet will run and the export request will be created but when the MRS processes it, it will fail with messages such as:

FailureCode: -2146233088
FailureType: InvalidContentFilterPermanentExceptionMessage
Error:
ContentFilter is invalid. The value "13/05/2013 12:00:00 AM" could not be converted to type System.DateTime. 

It seems that at each step the date is input or stored as a string and converted to date format.  Even if you use a date-formatted variable in the cmdlet Exchange will convert it to date format as the cmdlet is run.  The MRS then processes the export request and converts the stored date from a string to date format again.

I'm pretty sure of this because I've tried entering dates in lots of different ways, type, formats, cultures, strings, variables etc.  I've even called PowerShell using a hard-set US culture but it still refers to the computer's region format when it creates the export request.

The only solution that worked for me was to make sure the computer's region format is set to US before starting EMS, run my script/cmdlet then change the region format back to the local one.  You only have to have EMS started while the format is US, you can change it back to local as soon as EMS is running.

Caveat: I've only tried this while running the cmdlet on a CAS server.  If you run it remotely you may find you don't need to change any region settings or that you may need to change them on the CAS server.


This post in its entirety is the copyright of Roland Paix. I don't mind if you link to it but if you copy any of the content you must provide a link to the post and credit me appropriately.