Essentially, this boiled down to two NICS using different DNS servers but why didn’t this affect the SMTP probes to Health Mailboxes? If it didn’t, why did we use local DNS for Health Manager and foreign DNS for delivery? …and, if that’s the case. Is this a bug?

Then, the answer finally arrived in the form of a realization: if we had no queues to the Health Mailboxes, maybe the probe was broken? Alright, time to investigate that piece.

Sure enough, the probe has failed some time back and was marked as poisoned:

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).

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

With the arrival of Exchange 2013 came some design changes and, with those changes, inevitably something was bound to catch us off-guard. To help explain this better, enter the proxy from the CAS Frontend to the Mailbox backend.

All SMTP connections (we’re focusing on SMTP for this post) utilize the proxy of the Frontend Transport to make an SMTP connection. Even on multi-role servers, the incoming request on 25 utilizes the proxy to 2525 for Transport.

Here is a screenshot over-view of Transport from a previous EHLO blog:

The introduction of protocol proxy isn’t limited to SMTP but we’re focusing on SMTP, as it’s relevant to this post.

With the introduction of protocol proxy, there was an introduction of an issue with Transport Agents. Namely, Transport Agents that were installed on a Frontend server (CAS) were actually installed on a backend server. To get around this issue, one had to use local PowerShell and add the Exchange PowerShell Snap-in. However, what wasn’t consider is the following:

User A, external of the organization, composes a message to User B and an invalid recipient, User C, who are internal of the organization. The invalid recipient source isn’t as important as the fact that the invalid recipient exists in the header. When the external mail server connects to the on-premises Frontend, the typical SMTP traffic occurs:

At this point in the session, the proxy connection is sent to the mailbox server that hosts UserB. The server, seeing that UserB exists responds with Recipient o.k. but, due to tar-pit, this doesn’t quite reach the Frontend, yet. When the Mailbox server receives UserC, it responds with 5.1.1 but this is during the data stream. This causes an NDR to be generated for all recipients of the message. This also means that the valid recipient never receives the email.

This is an issue with Exchange 2013 and the fully supported scenario is to only activate the recipient filtering agent on the Frontend server. The Frontend will respond correctly with the “250 2.1.5 Recipient OK” and “5.1.1 Invalid Recipient”, while the correct recipient receives the email and an NDR is generated for the invalid recipient.

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]/