We had a case come in a few months ago where we were restoring Message Tracking Logs from backups and couldn't use the Get-MessageTrackingLog properly when specifying an -EndDate parameter. Consequently, we run into this same problem when trying to load up logs from other servers as well.
You can't copy the message tracking logs from an Exchange server and then use the Get-MessageTrackingLog cmdlet or the Message Tracking tool to search the copied logs on a different Exchange server. Also, if you save an existing message tracking log, the change in the date-time stamp of the message tracking log file breaks the query logic that is used to search the message tracking logs.
If the CreationTime and/or LastModified time stamps of an old message tracking log change, unexpected behavior can arise. Without going into details, the Log Search service uses this information to help speed up search requests within specified date ranges. These times can be off by copying the files from one server to another, restoring the logs from certain backups, opening a log up in notepad and saving it, etc,.
I wrote the powershell script below to help work around this problem. It goes through each tracking log in the message tracking log directories for both Hub and Mailbox roles, fixes the CreationTime and LastModified time based on the first and last entry in the log and restarts the Log Search service so that the changes will be picked up.
Note: This script requires that you stop the Information Store and/or Transport Service before running the script. A small price to pay for fixing the log files. The point of requiring the service to be stopped is to get exclusive access to the files lest one is being written to by the service when we try to modify it.