C# + EWS: Autodiscover Test (Exchange and O365)

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

In times of troubleshooting client-side issues, it may become necessary to query for the autodiscover response the user is receiving from either Exchange on-premises or Exchange in O365 – or, in the case of a redirection, both on-premises and O365 Exchange. This is a sample C#.NET Console Application, which will query for the Autodiscover response and use the TraceListener class to write the response to files.

There are two things the code doesn’t take into account for:

1. The condition wherein the user’s SMTP address and UPN are different.
2. ALL of the possible returns from Autodiscover for the UserSettings.

 

Thus, I have included the the source code for two reasons:

1. Promotion of writing .NET programs for both on-premises Exchange and O365 Exchange.
2. Customization of both the UserSettings one is targeting and the target delivery folder for which the files should be saved.

 

If you have any problems, questions, or concerns, feel free to reach out to me and I’ll try to address them as soon as possible.

The source code can be found here: http://gallery.technet.microsoft.com/C-EWS-Autodiscover-Test-870b4a8e

Server 2012: Using PowerShell to Check for KB2878635

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

In the course of an investigation, it became necessary to write a PowerShell script to check the current file version of the kernelbase.dll. I needed to compare it against the file version of a KB that was pushed for better resiliency (http://support.microsoft.com/kb/2878635).

The script uses some basic logic to get the file version and compare it with the known published version of the file, at the time the KB was published, and determine if we were below, at, or above that file version. I’m including links to the MSDN articles that helped me to write the script.

$FileVer = ([System.Diagnostics.FileVersionInfo]::GetVersionInfo(“C:\Windows\System32\kernelbase.dll”)).FileVersion
$pattern = ” ”
$intVer = [Regex]::Split($FileVer,$pattern)
$intFileVer = $intVer[0]
[version]$DLLVersion = $intFileVer
[version]$Target = “6.2.9200.20712”
$DLLVersion.CompareTo($Target)

For the return values, here’s the table from MSDN:

Return value Meaning
Less than zero The current Version object is a version before value.
Zero The current Version object is the same version as value.
Greater than zero The current Version object is a version subsequent to value.

O365/Exchange 2013: Obtaining Move Report After The Move Request Has Been Removed

NOTE: This post – drafted, composed, written, and published by me – originally appeared on https://blogs.technet.microsoft.com/johnbai and is potentially (c) Microsoft.

Often times, we will get an issue, where we need to check if any issues have occurred due to a move request but the move request (and seemingly any information related to it) has been removed.

Luckily, we also write/log this information for later retrieval. We can obtain the log and place it in a text file on the desktop (assuming the ‘~’ signifies the default home directory in PowerShell) via the following method:

((Get-MailboxStatistics <user alias OR smtp> -IncludeMoveHistory -IncludeMoveReport).MoveHistory).Report | Out-File C:\Users\johnbai\Desktop\report.tx

The report will need some clean-up, for readability-sake. I have attached a sample from my O365 tenant for reference.

report.txt