How msExchRecipientDisplayType and msExchangeRecipientTypeDetails Relate to Your On-Premises

Updated 22 Jan 2019:

In order to foster open community knowledge and growth, I’ve moved the values to being listed in GitHub, here.

You’re more than welcome to make a pull-request, in order to keep the list up-to-date, should you find any new values in the wild.

O365: CDN Change Causes OWA Client Error

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

Recently, we’ve seen a pattern of escalations wherein users are no longer able to access OWA. Specifically, the error will be similar to the following:

In the details, we’ll see the error we’re concerned with:

X-OQA-Error: ClientError;exMsg=’_g’ is undefined; file=https://pod51048.outlook.com/owa/:362

If we use Network Tracing (F12 in Internet Explorer) [or Fiddler] we’ll see a failure to connect to the CDN:

The connection to ‘r1.res.office365.com‘ failed. <br />Error: ConnectionRefused (0x274d). <br />System.Net.Sockets.SocketException No connection could be made because the target machine actively refused it 23.221.8.9:443

Using ARIN, we can check to make sure that the CDN (Content Delivery Network) we’re trying to hit is owned by Akamai.

The return we’re receiving, highlighted, is because the client cannot load ‘boot.worldwide.0.mouse.js’ from the CDN. This is evidenced by the refusal to connect to the RES server, highlighted.

The root cause of this issue is the configuration of the customer-owned firewall. This is evidenced by the client’s inability to connect to specific CDN and other users are able to use OWA sans issue; notably, because they are connecting to another CDN (‘r4.res.office365.com’, for example).

Since the CDN is controlled by a third-party and we have no way to predict which hosts will be up/in use/referred, our recommendation is to use URL-based filtering. You can read the EHLO blog post (written by our very own Tim Heeney) on the recommendation for URL-based filtering, here: http://blogs.technet.com/b/exchange/archive/2013/12/02/office-365-url-based-filtering-is-just-better-and-easier-to-sustain.aspx

O365: Accessing Another Mailbox via OWA URL

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

It may become necessary for an admin or delegate to access a mailbox (other than their own) in OWA. There’s two ways to do this and most people are familiar with the change in the URL method, which is what I’ll be covering in this post.

In Wave14 (Exchange 2010), you merely had to append the user’s smtp address to the suffix the OWA URL. So, for example, to access Amy Luu‘s mailbox in my test tenant, I would add the following: [email protected]

In Wave15 (Exchange 2013), we merely need to add another character at the end of the URL for this to work: [email protected]/

Hybrid Configuration Wizard: Exchange server “” was not found. Please make sure you typed the name correctly.

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

When you decommission an Exchange Server in your Organization and have a Hybrid Configuration, one of the things that does not occur is that the server is not removed from the Hybrid Configuration (msExchCoexistenceRelationship) to reflect this. When you run the Hybrid Configuration Wizard, after the decommission, you’ll see the following error:

The wizard did not complete successfully. Please see the list below for error details.
Exchange server “<Server>” was not found. Please make sure you typed the name correctly.

 

Given the above, you’ll see something similar to the following in Exchange Management Shell for the Hybrid Configuration:

SendingTransportServers   : {UNDERJORDISKE
                            DEL:416ba20c-62c1-4a28-95e5-8dbb6430dc96, LJUSALFER
                            DEL:89bf8a7d-144f-43b8-8aee-b8ac6f98721f}

 

One method to resolve this issue is to do a modification of the object in Active Directory. Using ADSIEdit, browse to the configuration container and either go to the object’s path (Config container > Services > Microsoft Exchange > Organization Name > Hybrid Configuration) or just create a new query (objectClass=msExchCoexistenceRelationship). Once you have the object, look for the property you want to fix (in this case, it was ‘msExchCoexistenceTransportServers’). I removed the two defunct values.

I, then, used Exchange Management Shell to get the DistinguishedName of the current Transport Servers in the Organization:

Get-TransportService | FL DistinguishedName

DistinguishedName : CN=HYLDA,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=minvan,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=minvan,DC=se
DistinguishedName : CN=STROMKARLEN,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=minvan,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=minvan,DC=se

I copied these values into the same property I removed the defunct values, previously. After doing so, I re-ran the Hybrid Configuration Wizard.

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

O365: PST Export Tool Issue and Possible Resolution[s]

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

It has been discovered that some customers experience a problem with the PST export tool in the Wave15 version of the cloud. Specifically, the symptom is:

When a Tenant Admin attemptsto download the PST file, he or she receives “Microsoft.Exchange.eDiscovery.ExportTool.exe has stopped working” and their only option is to terminate the process.

This can be resolved in one of two ways:

1. Add outlook.com and office.com to trusted sites in Internet Explorer.

2. Install the .NET 4.5 package.

This should resolve the issue with the PST export tool.

 

Special thanks to mbarta for the tip!

O365 & EWS: EmailMessage.SetExtendedProperty() Introduces Undesirable Behavior for Cloud

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 Office 365, there is a known issue where Item.SetExtendedProperty() will prevent ResponseMessage.SendAndSaveCopy() from working correctly. Instead of sending the messaging and placing the item in the ‘Sent Items’ folder, the message will be sent and remain in the ‘Drafts’ folder.

This issue can be corrected by changing the source code of the EWS application in either of the following two ways:

1. Specify the ‘Sent Items’ folder via passing ‘SENTFOLDEREWSID‘ in the method (Note: WellKnownFolderName.SentItems will not work for this case):

var messageToSend = responseMessage.Save();

// This is our method that is introducing our repro scenario in O365.
messageToSend.SetExtendedProperty(newExtendedPropertyDefinition(newGuid(“{00000000-0000-0000-0000-000000000000}”), “<String>”, MapiPropertyType.String), 1);

// Send and save a copy of the replied email mesage in the default Sent Items folder.
messageToSend.SendAndSaveCopy(SENTFOLDEREWSID);

 

2. Use Item.Update() before the SendAndSaveCopy() method:

 var messageToSend = responseMessage.Save();

// This is our method that is introducing our repro scenario for the cloud.
messageToSend.SetExtendedProperty(newExtendedPropertyDefinition(newGuid(“{00000000-0000-0000-0000-000000000000}”), “<String>”, MapiPropertyType.String), 1);

// We update the item before sending it.
messageToSend.Update(ConflictResolutionMode.AlwaysOverwrite);

// Send and save a copy of the replied email mesage in the default Sent Items folder.
messageToSend.SendAndSaveCopy();

 

With this, you should be able to work-around this EWS issue until a fix is found. Happy coding!

 

Attached, you will find the repro code with the fix (Program.cs).

Program.cs