CODEWITHSUNDEEP
powershelloffice365
Dewey
Dewey

Reputation: 37

O365 PShell similar recipient search does not return correct results using Where {$_.RecipientAddress -like

Good morning!

Have a curious quirk with Microsoft's Office365 EOL powershell cmdlets where the "-like" filter does not seem to report accurate results.

Here's an example:

get-messagetrace -startdate 08/20/2018 -enddate 08/30/2018 -senderaddress [email protected]

I get four results which are expected.

However, if I use the -like filter:

get-messagetrace -startdate 08/20/2018 -enddate 08/30/2018 | Where {$_.SenderAddress -like '*diversified*'}

I get zero results. The expectation would be anything with "diversified" in the sender domain address would be returned. I should see at least four results.

Any thoughts on this? I believe I'm missing something very simple but just can't quite figure it out.

Thank you in advance; have a wonderful week!

Update 09/26/2018: A ticket is active with MS as I was able to replicate the issue on several domains including large ISP's. MS acknowledges the behaviour is odd and should not be producing the results I'm seeing. Will update once the fix is found.

Curiously, the Search and Compliance GUI does return the expected results. We have ruled out different Powershell and .NET versions (For reference, PS 5.0 / .NET 4.7)

Update 10/03/2018: Continued progress with MS. As an example using a major local ISP:

get-messagetrace -startdate 09/03/2018 -enddate 10/03/2018 | Where {$_.SenderAddress -like '*telus*'}

Result here is 10 when I exported to CSV and counted manually. MS suggested declaring this as a variable and counting it:

PS U:\> $messages = get-messagetrace -startdate 09/03/2018 -enddate 10/03/2018 | Where {$_.SenderAddress -like '*telus*'}
PS U:\> $messages.Count
10

I later found that a month's worth of email is limited to 1000 results by default; I can expand the results up to 5000:

PS U:\> $messages = get-messagetrace -startdate 09/03/2018 -enddate 10/03/2018 -PageSize 5000 | Where {$_.SenderAddress -like '*telus*'}
PS U:\> $messages.Count
46

Going to keep poking. If I'm on the right track, the "discrepancy" may not be a discrepancy at all but a forced limit by MS skewing my results in PS versus eDiscovery.

Upvotes: 2

Views: 864

Answers (2)

Dewey
Dewey

Reputation: 37

I have a final answer for what was an exercise in frustration.

What I've discovered is everything before the pipe character | is direct to the server(s), whereas everything else is manipulating the gathered data local to PowerShell.

When running this:

get-messagetrace -startdate 09/03/2018 -enddate 10/03/2018

The results can be misleading as there may be multiple events for each message. A really good example would be where the recipient is a distribution list. Rather than the cmdlet counting every result, only the original item is counted. This has the net effect of appearing to have "fewer results" than what is expected.

The get-messagetrace cmdlet can be combined with historical message tracing to fully expand gathered results.

In short:

  • On-premises will see the expected results without issue
  • Hybrid solutions are a mixed bag depending on which server is connected (prem vs cloud)
  • Fully cloud based solutions will have a "watered down" version of the results and admins will need to take this into account.

Upvotes: 0

postanote
postanote

Reputation: 16116

Are you sure you are signed into MSOL and remoted into EXO?

If you are just on your internal Exchange server doing this, then you are using the local Exchange cmdlets and those will not bring anything back from O365.

If you are on your internal Exchange server and imported the EXO cmdlets via remoting and did not uniquely identify them, and / or did not use -clobber, then you can have other issues.

I just did a quick hit of my tenant and get the expected results...

Connect-MsolService -Credential $MSOLCreds
Connect-AzureAD -Credential $MSOLCreds

$ExchangeOnlineSession = New-PSSession -ConfigurationName 'Microsoft.Exchange' `
-ConnectionUri 'https://outlook.office365.com/PowerShell-liveid/' `
-Authentication Basic -Credential $MSOLCreds -AllowRedirection
Import-PSSession $ExchangeOnlineSession -Prefix 'EXO'

Get-EXOMessageTrace -startdate 08/01/2018 -enddate 08/30/2018  | 
Where {$_.SenderAddress -like '*MyO365VanityDomain*'} | 
Format-Table -AutoSize

# Results

Received             Sender Address                       Recipient Address   Subject                   
--------             --------------                       -----------------   -------                   
8/29/2018 8:48:10 AM SomeEXOUsername@MyO365VanityDomain SomeRecipientAddress  Undeliverable: Your Off...
8/28/2018 3:00:30 PM SomeEXOUsername@MyO365VanityDomain bounce-108_html...    Undeliverable: Your Off...
8/22/2018 8:55:10 AM SomeEXOUsername@MyO365VanityDomain SomeRecipientAddress  Undeliverable: Weekly d...

If you are doing this from a remote workstation and testing this for Exchange on-prem and O365, you need to setup to different implicit remote sessions and when using the commands, use the right cmdlet associated with the right session.

I use prefixes (all on-prem uses EXP and online as EXO) regularly to avoid confusion as shown above, whether I am on the Exchange server directly or via remoting.

So, with prefix, the cmdlets noun part gets renamed:

Get-EXPMessageTrace
Get-EXOMessageTrace

Upvotes: 1

Related Questions