Monday, 20 May 2013

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.

16 comments:

  1. Hi,

    I spent a lot of time troubleshooting the same issue. Your solution was the only which worked for me.

    THX

    Michel

    ReplyDelete
  2. Below you can see my Exporting script. When I run this script by Exchange PS, script runs, exports the mailbox without problem, but exports the whole mailbox. It denies the Content Filter Date variable. Do you have any idea why it doesn't work?

    [DateTime] $Today = Get-Date -Format d

    $Today = $Today.adddays(-90)

    $Path = "\\172.20.143.100\DestekServis\" + "soltest" + $Today.tostring("yyyy-MM-dd") + ".pst"

    Write-Host $Path -ForegroundColor Green
    Write-Host $Today

    New-MailboxExportRequest -Mailbox soltest -ContentFilter {(Received -le $Today)} -FilePath $Path

    ReplyDelete
    Replies
    1. Try using double-quotes instead of curly brackets for the content filter.

      Delete
  3. Had same issue and this is the only page the got the problem right. Worked for me, thx.

    ReplyDelete
  4. Thank you! This was extremely annoying issue and amazing this worked. God damn microsoft!

    ReplyDelete
  5. Neater resolution than changing the region for the whole PC.
    http://occasionalutility.blogspot.com.au/2014/03/everyday-powershell-part-17-using-new.html
    Just change it for the thread you are running!

    ReplyDelete
    Replies
    1. Ah, nice work. I knew someone would figure out how to do that eventually but it wasn't me!

      Delete
  6. Worked for me ... Thanks !!!!

    ReplyDelete
  7. I'm using Exchange 2010 in French language and I could make it work like this :
    -Store in a String variable the filter date in this format : 'MM/DD/YYYY hh:mm:ss'
    -then use this variable in the ExportRequest filter
    Ex : $FilterDate = '12/31/2016 15:00:00' ; New-MailboxExportRequest -FilePath '\\fs\pst$\_exports\Juhn.Smith.pst' -MailBox John.Smith -ExcludeDumpster -ContentFilter {(Received -gt $FilterDate)}

    ReplyDelete
  8. Sorry, my mistake in my previous post. It doesn't work...

    ReplyDelete
  9. Exchange 2010 SP3 RU10 environment. Failed to run the command on a server which has EN-GB settings. Same command running on a server with EN-US settings worked.

    Definitely a bug. I have seen the requirement of using US date format when running Get-MessageTrackingLogs command too.

    ReplyDelete
  10. Exchange 2013 CU9, Issue is same, Still failing with the suggested pattern of running script.

    ReplyDelete
  11. See this page here, but look at my comment at the bottom about using a function - https://occasionalutility.blogspot.co.uk/2014/03/everyday-powershell-part-17-using-new.html

    ReplyDelete
  12. Hi! Thanks very much!!!!!!!!!

    ReplyDelete
  13. Hi, thanks a lot for your tip, I had the same issue and changing locale then restarting Exchange powershell console fixed it.
    Thanks a lot for all !

    ReplyDelete
  14. Exchange 2013 CU 19. Same story.
    Thank you for your solution!

    ReplyDelete