We had a big Microsoft Office 2016 upgrade project this fall. The main reason for this was a non-consistent Office environment with versions dating all the way back to MS Office 2007. The whole upgrade process was done using a System Center Configuration Manger application package, which I also happen to be the author for. The upgrade process went mostly fine, even though it was quite a long process involving many (stubborn) users and computers.
Anyhow, now that a new MS Office version was deployed, it was finally time to think about changing the Outlook protocol and authentication to a more modern one. RPC over HTTP (and basic/ntlm authentication) was getting dated, and the main reason for not using MAPI over HTTP were the old clients. That problem is now gone 🙂
So, what’s up with this MAPI-thing then? I’ll just copy/paste a few things and you can read more about MAPI in the provided links.
“MAPI over HTTP is a new transport used to connect Outlook and Exchange. MAPI/HTTP was first delivered with Exchange 2013 SP1 and Outlook 2013 SP1 and begins gradually rolling out in Office 365 in May. It is the long term replacement for RPC over HTTP connectivity (commonly referred to as Outlook Anywhere). MAPI/HTTP removes the complexity of Outlook Anywhere’s dependency on the legacy RPC technology”.
“The primary goal of MAPI/HTTP is provide a better user experience across all types of connections by providing faster connection times to Exchange – yes, getting email to users faster. Additionally MAPI/HTTP will improve the connection resiliency when the network drops packets in transit. Let’s quantify a few of these improvements your users can expect. These results represent what we have seen in our own internal Microsoft user testing.”
Source: https://blogs.technet.microsoft.com/exchange/2014/05/09/outlook-connectivity-with-mapi-over-http/
MAPI over HTTP is also the default protocol in Exchange 2016 which clearly shows the way Microsoft is going. More information about MAPI:
https://technet.microsoft.com/en-us/library/dn635177(v=exchg.150).aspx
http://markgossa.blogspot.fi/2015/11/exchange-2013-and-exchange-2016-mapi.html
http://searchexchange.techtarget.com/definition/MAPI-over-HTTP-Messaging-Application-Programming-Interface-over-HTTP
What are the requirements for MAPI then?
Main Prerequisites
Complete the following steps to prepare the clients and servers to support MAPI over HTTP.
-
Upgrade Outlook clients to Outlook 2013 SP1 or Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015).
-
Upgrade Client Access and Mailbox servers to the latest Exchange 2013 cumulative update (CU). For information about how to upgrade, see Upgrade Exchange 2013 to the latest cumulative update or service pack.
Source: https://technet.microsoft.com/en-us/library/dn635177(v=exchg.150).aspx
No problem, these prerequisites were now in order for us.
Other Prerequisites
Check/Set the MAPI Virtual Directories
Clients can’t connect if you don’t have working MAPI Virtual Directories. Just follow the above TechNet article and you’ll be fine. Our original MAPI virtual directories looked like this:
Sorry for the blur. All I can say is that the InternalUrl had the Exchange server’s hostname specified instead of the (single) namespace. Changing and verifying the new url’s is done in the following screenshot:
I changed the ExternalUrl on one of our Exchange servers. I then used the same command for the InternalUrl, replacing the word “External” with “Internal”. I also made the same change to our second Exchange server. The end the result would have both external and internal url’s listed, like so:
Again, sorry for the blur. We’re using a single namespace so all url’s are basically identical.
Enable MAPI over HTTP in your Exchange Organization
This is easily done with one command:
Set-OrganizationConfig -MapiHttpEnabled $true
In theory, this isn’t needed if the user mailboxes already have MAPI enabled:
“To enable or disable MAPI over HTTP at the mailbox level, use the set-Casmailbox cmdlet with the MapiHttpEnabled parameter. The default value is Null, which means the mailbox will follow organization-level settings. The other options are True to enable MAPI over HTTP and False to disable. In either case, the setting would override any organization-level settings. If MAPI over HTTP is enabled at the organization level but disabled for a mailbox, that mailbox will use Outlook Anywhere connections”.
Source: https://technet.microsoft.com/en-us/library/mt634322(v=exchg.160).aspx
Checking if enabled on user level (we had it enabled already):
That said, it’s still a good idea to enable it organization wide (if you have old migrated room mailboxes or public folders). See the following link:
We enabled it organization wide and It was now time to do some tests.
Testing
Still following the TechNet article:
All good 🙂
The change isn’t instant. A recycle of the MSExchangeAutodiscoverAppPool make things happen faster however. After a MSExchangeAutodiscoverAppPool recycle and a coffee break plus a restart of my own Outlook client, I had a look at the Outlook Connection Status:
Well, well, well. All connections are now using MAPI over HTTP instead of the old RPC over HTTP.
You’ll see several changes:
- First change is in the “Server name” column. It’s now a real server name instead of a mailbox GUID.
- Notice also that the server path includes /mapi/.
- The protocol (column) has changed from RPC/HTTP to just HTTP.
- The “Authn” column have changed values from NTLM to Nego* (Kerberos)
Further check-ups
Now that we’re using up2date clients, there’s no need to use old authentication methods for Outlook Anywhere either. (Outlook Anywhere authentication and MAPI authentication are configured/can be configured separately btw). The main reason for sticking with the old Basic/NTLM authentication (at least externally) is when using an Exchange 2010/2013 co-existence environment (and sticking with old “best practices”). This hasn’t been the case for us for a long time. Another reason for still sticking with “Basic” is, well, old clients. A third reason would be a mix of both old clients and an Exchange 2010/2013 co-existence environment. Luckily for us, we now have a “pure” Exchange 2013 environment and (almost) all Windows clients are using Outlook 2016.
Even though Outlook clients are now configured to connect via the MAPI protocol, there will still be some clients connecting via RPC over HTTP. This will probably be the case for quite some time, as the clients are gradually moving towards MAPI. (The change isn’t instant as already stated). Many users don’t restart their Outlook client so often either, which in turn means that they’re using RPC over HTTP until restart (at least from my experience). Correct me if I’m wrong.
As a side note, the MAPI protocol is only used for Windows Outlook clients. The Mac version of Outlook use EWS, and mobile phones use ActiveSync. So yes, you’ll still have many different active protocols in your organization. Don’t disable them 🙂
If you want to read more about the Outlook Anywhere authentication types, have a look at http://msexchangeguru.com/2013/01/10/e2013-outlook-anywhere/ for example.
A checkup of our old settings for Outlook Anywhere:
As you can see, the servers were still using Basic for external authentication method. Time to change that! This time I’ll use EAC:
You’ll get a warning that you shouldn’t enable Negotiate if you’re having Exchange servers older than version 2013 in your environment. Again, no problem!
I did the same for the internal url (must be done from EMS):
Like so. All authentication methods pimped to modern standards 🙂
This should cause no problems at all (and still haven’t). A good referral:
For Exchange 2007/2010
Set-OutlookAnywhere -Identity ‘SERVER\Rpc (Default Web Site)’ -SSLOffloading $true -ClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM
For Exchange 2013+ with backwards compatibility with Outlook 2010 and 2007
Set-OutlookAnywhere -Identity ‘SERVER\Rpc (Default Web Site)’ -SSLOffloading $true -ExternalClientAuthenticationMethod NTLM -InternalClientAuthenticationMethod NTLM -IISAuthenticationMethods Basic,NTLM,Negotiate
For Exchange 2013+ with Outlook 2013+
Set-OutlookAnywhere -Identity ‘SERVER\Rpc (Default Web Site)’ -SSLOffloading $true -ExternalClientAuthenticationMethod Negotiate -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Basic,NTLM,Negotiate
Source: https://community.spiceworks.com/topic/1979514-outlook-auto-discover-issue
Lastly, if you’re having trouble with the famous and dreadful Outlook credential-popup, changing the authentication methods should help.
“Basic authentication: If you select this authentication type, Outlook will prompt for username and password while attempting a connection with Exchange”.
Source: http://msexchangeguru.com/2013/01/10/e2013-outlook-anywhere/
Similar information can be found at:
http://www.sysadminlab.net/exchange/outlook-anywhere-basic-vs-ntlm-authentication-explained
https://community.spiceworks.com/topic/1979514-outlook-auto-discover-issue
for example. I’ve seen this mentioned on other sites as well, I just can’t remember them right now. We’ve also seen the “popup dilemma” here, but luckily gotten rid of it by now.
Get-ActiveExchangeUsers script
If you want to get some nice details about how your users connect (per protocol), I’d suggest you grab the script from
https://gallery.technet.microsoft.com/office/Get-ActiveExchangeUsersps1-f1642024
As seen in my screenshots below, not everyone is connected over MAPI (yet). Old RPC connections are still used, and that will probably be the situation for a while. If someone wiser than me care to explain why this is the case, please do.
The user activity was fairly low when these screenshots were taken.
Checking logs
Finally, if you feel like deep diving into the logs, the MAPI-stuff gets logged in:
C:\Program Files\Microsoft\Exchange Server\V15\Logging\MAPI Client Access for the CAS and
C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Mapi for the Mailbox.
If you see any suspicious things in here, do Google (or use common sense 🙂 ).
A random blog from a sysadmin 