Exchange Online: The end of RPC over HTTP

And that’s it, more than 3 years after Microsoft launched MAPI over HTTP (the replacement for RPC over HTTP – aka Outlook Anywhere), now it’s time to announce that in October 31st 2017 the RPC over HTTP feature will be deprecated in Office 365.

Some of my thoughts on this, and things you should consider..

How about Exchange On-Premises?

The deprecation of RPC over HTTP is announced just for Exchange Online. What does that mean to Exchange on premises deployments? Probably that in a future Cumulative Update the feature will be discontinued, but for now, all stays the same with on-premises.

When Microsoft launched Exchange 2016 they listed the RPC over HTTP feature as de-emphasized and not discontinued.  That basically meant that it still works and it’s still supported.

That doesn’t mean that this will always be the case, and with this announcement coming now to Exchange Online, maybe a new Exchange 2016 CU will remove the RPC over HTTP feature, or maybe this is just Microsoft not publishing the rpc virtual directory anymore, in Exchange Online. I guess that at some point we will find out, but for now all supported versions of Exchange also support RPC over HTTP in an on-premises deployment.

My personal opinion is that it won’t take long for RPC over HTTP to be also deprecated i

Check the matrix below for current connectivity supportability:

Product Exchange 2016 RTM Exchange 2013 SP1 Exchange 2013 RTM Exchange 2010 SP3
Outlook 2016 RTM
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 SP1
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 RTM Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015)
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and earlier Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2007 Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere

Any versions of Outlook being affected?

The simple answer is yes. All versions will be affected. Outlook 2007 will stop working (remember Office 2007 is out of extended support), and all other versions need to be properly updated, to the minimum versions described on the table below:

Office version Update Build number
Office 2016 The December 8, 2015 update
  • Subscription: 16.0.6568.20xx
  • MSI: 16.0.4312.1001
Office 2013 Office 2013 Service Pack 1 (SP1) and the December 8, 2015 update 15.0.4779.1002
Office 2010 Office 2010 Service Pack 2 (SP2) and the December 8, 2015 update 14.0.7164.5002

Read the Microsoft article for more details on the above.

Why MAPI over HTTP?

Let me bullet point some main reasons:

  • Better connection resiliency
  • Additional secure sign-in scenarios (multi-factor authentication)
  • Better foundation for third-party identity providers
  • Less complexity as it doesn’t depend on RPC technology
  • With less complexity the Exchange team can innovate more quickly
  • Fits into today’s reality with clients connecting from all sorts of different networks

So in a nutshell, it’s more secure, more flexible and reliable in terms of connectivity, and it’s less complex.

For more information read this amazing blog post from the Exchange product team, around MAPI over HTTP.

What should an Exchange Online administrator start doing, right now?

Identify the Microsoft Outlook versions and builds that his users have and use to connect to Exchange Online.

How? Using the PowerShell is the best method. Here’s an example command that you can run:

Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like “*Outlook*” } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv .\OutlookConnections.csv

I will write a blog post soon with more details, screenshots and eventually a script to gather and export all if this information.

 

Advertisements

Office 365: Outbound conditional (per source domain) mail flow routing

Imagine this scenario: You have an anti-spam appliance in front of your Office 365 tenant, and you want outbound mail flow from your tenant to go via that appliance, but depending on what the email domain of the sender is. For example you have domainA.com and domainB.com as two vanity domains in Office 365, and you want User1@domainA.com outbound email to go via the mail appliance, but user2@domainB.com outbound email to go direct to the Internet.

The scenario above requires conditional routing, meaning the outbound mail flow path will be different depending on what the email domain of the source user (the sender) is. The example above is just one of several that might lead you to apply such configuration.

Now the important part: How do you configure it? Well, you can do it via PowerShell or via the UI, and to do the configuration you will need the following:

  • A Transport Rule
  • An Outbound Connector

Create the Outbound Connector

The first thing you need to create is the Outbound connector.

Via Exchange Online PowerShell

To create the connector via the PowerShell, connect to Exchange Online and run the following:

New-OutboundConnector -Name “To Internet Direct” -ConnectorType Partner -UseMXRecord $true -IsTransportRuleScoped $true

The command above creates a connector that goes directly to the Internet and it’s scoped to the transport rule we will create next. If you want to create a connector that goes via an appliance run the following:

New-OutboundConnector -Name “To Internet via Appliance” -ConnectorType Partner -UseMXRecord $false -SmartHosts <Appliance IP> -IsTransportRuleScoped $true

Via the Exchange Online Admin Center

Navigate to Mail Flow > Connectors and click “+”

1

Select Office 365 as source and Partner Organization as destination

2

Enter a name and description

3

Select “Only when I have a transport rule set up that redirects messages to this”

4

Select “Use MX Record” or “route email through these smart hosts” depending on if you want the email to go direct or via an appliance/smart host

5

Remove the always use TLS selection, unless the appliance or server your sending the email to is configured to use TLS

6

Confirm the settings and click next

7

Validate the connector and save

Create the transport rule

Once you have the outbound connector created, you can now create the transport rule.

Via Exchange Online PowerShell

To create the transport rule via the PowerShell, connect to Exchange Online and run the following:

New-TransportRule -Name “UseAppliance” -SenderDomain <Source Domain> -SentToScope NotInOrganization -RouteMessageOutboundConnector “To Internet Via Appliance”

The command above creates a transport rule, that uses the “To Internet Via appliance outbound connector, and that applies when the source domain is specific and the destination recipient is outside of the organization (very important setting).

Via the Exchange Online Admin Center

Navigate to Mail Flow > Rules and click “+ Create a New rule”

8

Click on more options

Give the rule a name

In the Conditions select “Apply this rule if..” > The recipient is located > Outside of the Organization

Click in Add Condition

Select “Apply this rule if..” > The Sender > Domain is > Enter the domain name of the source user

In the “Do the Following…” section select “Redirect the message to..” > The following connector. Select the outbound connector from the drop down list

Make sure the enforce rule option is selected

9

Now that you have both the transport rule and the outbound connector created, lets test and see if it’s being applied.

Test the routing

The first thing you should do is simple: Send an outbound email from the user that should have conditional routing applied to his domain. Make sure the email is to an external recipient.

Once you sent the email, in the Exchange Admin Center go to Mail flow > Message trace, select the sender you want to trace the message for and click on “search”

10

Note: It might take a few minutes after you sent the message before it shows in the message trace

Once you can see the message there, double click on it to see the details

11

In the details you can see if the transport rule was applied and the transport rule name

13

You will also be able to see if the message was delivered, is pending or has failed. This is key for you to troubleshoot the mail flow and see if the correct rules are applied and the correct outbound connectors are being used.

And that’s it. Job done! As always if you have questions let me know.