Exchange Server 2016 Client Access

This article is part of a series based on my notes during the migration of an Exchange organization from version 2010 to 2016. It's not a complete procedure, but a description of the main points and areas. The examples relate to a specific design, but they can usually be generalized. Also, even though it's a description of migration, the information is useful for new installations or administration as well.

Official documentation for Exchange Server 2016, mainly chapters Client Access services, Clients and mobile in Exchange Server, Client Access protocol architecture, Configure mail flow and client access on Exchange servers.

Client Communication with Server

Several protocols are available for client access to the server. Usually today it's HTTP (Hypertext Transfer Protocol) or encapsulation of another protocol into HTTP. In practice, we always use encrypted (TLS) HTTP, i.e. HTTPS. This means simplification of penetrations, connections, standardization of protocols, but also the need to properly handle certificates. Client connection is now stateless (no need for session affinity). Because processing takes place on the backend Mailbox server, it doesn't matter which server receives the client request. For load balancing, we can use something like DNS Round Robin.

Outlook - MAPI

Microsoft Outlook uses MAPI (Messaging Application Programming Interface) as the main protocol. Previously, it connected using MAPI over RPC (MAPI/RPC), which caused various complications. Today, MAPI/RPC connection is no longer allowed and primarily MAPI over HTTP (MAPI/HTTP) is used. If the client doesn't support it, it can use Outlook Anywhere (MAPI over RPC over HTTP, i.e. MAPI inside RPC and that inside HTTP, also referred to as just RPC/HTTP), which was previously used for internet connections.

Mobile Clients - ActiveSync, OWA

Mobile clients typically use the Exchange ActiveSync protocol, which is based on HTTP and XML. For client-less access, we have the web interface Outlook on the web (formerly Outlook Web App - OWA), which we display using a web browser.

POP and IMAP

Optionally, we can use other clients for working with email that use a combination of POP3 or IMAP4 protocols and authenticated SMTP. By default, the POP and IMAP protocols are blocked. For client SMTP, there's a default Receive Connector.

IIS Virtual Directory

On the Exchange server, several other client services are running, which are used for additional services or special access. Services that use HTTP can be found as IIS Virtual Directory:

• Outlook Anywhere - folder Rpc
• MAPI over HTTP - folder mapi
• Outlook on the web (OWA) - folder owa
• Exchange ActiveSync (EAS) - folder Microsoft-Server-ActiveSync
• Exchange Web Services (EWS) - folder EWS, web services for programmatic access to Exchange (third-party applications)
• Exchange Control Panel (ECP), now Exchange Admin Center - folder ecp, web interface for administration
• AutoDiscover - folder Autodiscover, automatic configuration of user profile
• Offline Address Book (OAB) - folder OAB, downloading offline address book
• PowerShell - folder PowerShell, remote access to PowerShell (Exchange Management Shell) through HTTPS

On IIS we also have special Virtual Directories API and aspnet_client. We won't deal with POP3 and IMAP4 protocols here and we'll discuss the SMTP protocol in the Mail Flow chapter. Below is an official image from Microsoft showing the service scheme.

Client Access Configuration

In the first part, when we discussed addresses for services (Namespace), we concluded that for all services and servers we'll use the same domain name (address), one for internal and one for external connection (or possibly one common overall). This is one part of configuring services for client access - setting addresses. The second part is setting the required authentication method. What authentication to use for various services is (in my opinion) quite a complex question and I haven't found anywhere where it's been discussed.

After installing the Exchange server, internal URLs with the address of the given server are set on individual client services. So typically we change the internal URL and add an external URL. Generally, we can set internal and external URLs and authentication methods for individual services (Virtual Directory), other settings are specific to the given service. However, I haven't found a reasonable description of when external values are used. The client gets information from the Autodiscover service and then can choose which data it wants to use. But for OWA, for example, internal authentication is always used in tests, regardless of where the client is logging in from.

In some places it's stated that the used URL depends on whether the client computer is in the same Site as the server (based on IP address). Or whether it's a member of the same AD DS domain/forest. For example in QuickPost: What do Exchange Virtual Directories Do?. In my practice, however, clients from another Site still use internal URLs.

Microsoft has a description of default values, but they don't address external vs. internal, but IIS - Default settings for Exchange virtual directories. I haven't found anywhere what the default settings for authentication methods for individual services are.

Outlook Anywhere

I found documentation for Outlook Anywhere only for Exchange 2013.

Configuration using Exchange Admin Center is located in a different place than all other services. We'll set more properties using Exchange Management Shell.

• EAC - Exchange Admin Center
• Servers - Servers
• select the server and click on the pencil - Edit
• item Outlook Anywhere
• Specify the external host name: mail.firma.cz
• Specify the internal host name: mail.firma.local
• save Save

If we're migrating from Exchange 2010, then for coexistence to work for proxying connections from Exchange 2016 Outlook Anywhere to Exchange 2010, we need to change the authentication method from the default Negotiate to NTLM. After removing Exchange 2010 servers, we can set Negotiate again. This is written about in Outlook Anywhere coexistence or Configure Outlook Anywhere, but it's not written whether it's about external (default is Negotiate) or internal (default is NTLM) authentication. In EAC we only set external authentication.

Another option is if we use authentication on the Firewall for external connections, then we need to set the required authentication on the Exchange service. In case of migration, it's definitely good to save the current settings from all servers. Or set new servers the same. We'll do this best using Exchange Management Shell - Set-OutlookAnywhere, Get-OutlookAnywhere.

[PS] C:\>Get-OutlookAnywhere | fl servername,external*,internal*,iis*

ServerName                         : MAIL1
ExternalHostname                   : mail.firma.cz
ExternalClientAuthenticationMethod : Negotiate
ExternalClientsRequireSsl          : True
InternalHostname                   : mail.firma.local
InternalClientAuthenticationMethod : Ntlm
InternalClientsRequireSsl          : True
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}

Other Services - Virtual Directories

Configuration of other services for client access is located in the same place in Exchange Admin Center. If we use the same external domain name for all services, we can also use bulk setting:

• EAC - Exchange Admin Center
• Servers - Virtual directories
• click on the key icon - Configure external access domain
• select Exchange servers we want to set, and enter the domain name
• setting is done with the Save button

We'll configure individual services:

• EAC - Exchange Admin Center
• Servers - Virtual directories
• we can filter a specific server or service
• in the list we select the service and click on the pencil icon - Edit
• for most services we can set internal and external URL and authentication

For faster setting, we can use Exchange Management Shell and we can find various prepared scripts on the internet, for example PowerShell Script to Configure Exchange Server Client Access URLs.

MAPI over HTTP

Documentation MAPI over HTTP in Exchange Server, Outlook Connectivity with MAPI over HTTP, Set-MapiVirtualDirectory, Get-MapiVirtualDirectory

Finding current settings

[PS] C:\>Get-MapiVirtualDirectory | FL Server,external*,internal*,iis*

Server                        : MAIL1
ExternalUrl                   : https://mail.firma.cz/mapi
ExternalAuthenticationMethods : {Basic, Ntlm, Negotiate}
InternalUrl                   : https://mail.firma.local/mapi
InternalAuthenticationMethods : {Basic, Ntlm, Negotiate}
IISAuthenticationMethods      : {Basic, Ntlm, Negotiate}

Kerberos authentication

When we have multiple Exchange servers and we use a shared domain name for services, that is, we have load-balanced Mailbox servers where the Client Access service runs. And at the same time, we want to use Kerberos for authentication, perhaps for MAPI over HTTP or Outlook Anywhere services. So we need to create a special account that Microsoft calls the Alternate Service Account (ASA), and assign a shared name (Namespace) to it using Service Principal Names (SPN). This logically follows from the Kerberos protocol principle, but I couldn't find any mention of it in any guide. Microsoft describes this in the article Configure Kerberos authentication for load-balanced Client Access services.

Brief procedure using PowerShell, most of the things could be set in Active Directory Users and Computers (ADUC).

We will create a computer account, to which we will later assign the SPN.

New-ADComputer -Name EXCH2016ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'mail.firma.local
 Kerberos Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2016ASA
Set-ADComputer EXCH2016ASA -add @{"msDS-SupportedEncryptionTypes"="28"}

We will set the ASA Credential on the first Exchange server, using an existing script.

Note: The important thing is to run the script under an account that has permissions on Exchange and changes in the domain. Microsoft emphasizes that the script needs to change the password on the account used. But for that, it needs permissions.

[PS] C:\>cd $ExScripts
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\RollAlternateServiceAccountPassword.ps1
 -ToSpecificServer mail1.firma.local -GenerateNewPasswordFor firma\EXCH2016ASA$

========== Starting at 03/22/2019 09:29:05 ==========
Destination servers that will be updated:

Name      PSComputerName
----      --------------
MAIL1 mail1.firma.local

Credentials that will be pushed to every server in the specified scope (recent first):

UserName                            Password
--------                            --------
firma\EXCH2016ASA$ System.Security.SecureString

Prior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the
 destination servers.
Pushing credentials to server MAIL1
Setting a new password on Alternate Serice Account in Active Directory

Password change
Do you want to change password for firma\EXCH2016ASA$ in Active Directory at this time?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y
Preparing to update Active Directory with a new password for firma\EXCH2016ASA$ ...
Resetting a password in the Active Directory for firma\EXCH2016ASA$ ...
New password was successfully set to Active Directory.
Retrieving the current Alternate Service Account configuration from servers in scope
Alternate Service Account properties:

StructuralObjectClass QualifiedUserName  Last Pwd Update    SPNs
--------------------- -----------------  ---------------    ----
computer              firma\EXCH2016ASA$ 22.03.2019  9:17:20

Per-server Alternate Service Account configuration as of the time of script completion:

   Array: {mail.firma.local, mail.firma.cz}

Identity  AlternateServiceAccountConfiguration
--------   ------------------------------------
MAIL1 Latest: 22.03.2019 9:29:23, firma\EXCH2016ASA$
Previous: <Not set>

========== Finished at 03/22/2019 09:32:28 ==========

        THE SCRIPT HAS SUCCEEDED

We will set the ASA Credential on the other Exchange servers, the script now copies the settings.

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer mail2.firma.local -CopyFrom mail1.firma.local

Verification that the setup was successful

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | FL Name, AlternateServiceAccountConfiguration

We will determine and set the SPN on the account. We will decide whether to use it only on the internal URL or also on the external one (if it makes sense) and possibly on Autodiscover.

HTTP/mail.firma.local
HTTP/mail.firma.cz
HTTP/autodiscover.firma.cz

First, it's a good idea to check that we don't already have this SPN set somewhere.

setspn -F -Q http/mail.firma.local

Setting the SPN on the special computer account.

setspn -S HTTP/mail.firma.local firma\EXCH2016ASA$
setspn -S HTTP/mail.firma.cz firma\EXCH2016ASA$
setspn -S HTTP/autodiscover.firma.cz firma\EXCH2016ASA$

For verification, we can list the SPNs on the account.

setspn -L firma\EXCH2016ASA$

Possible removal of the credential.

Set-ClientAccessServer mail2 -RemoveAlternateServiceAccountCredentials

Outlook on the web (OWA)

Documentation Outlook on the web in Exchange Server, Set-OwaVirtualDirectory, Get-OwaVirtualDirectory

Finding current settings

[PS] C:\>Get-OwaVirtualDirectory -Server mail1 | FL ServerName,externalurl,internalurl,*auth*,LogonFormat

ServerName                    : MAIL1
ExternalUrl                   : https://mail.firma.cz/owa
InternalUrl                   : https://mail.firma.local/owa
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
LogonFormat                   : FullDomain

In the OWA authentication settings, we also have the special Forms-based Authentication (FBA) method, that is, a web form where we enter the login name (we define its format) and password.

In the EAC settings, it is not mentioned whether the authentication method is internal or external. After the setting is changed, the value of the InternalAuthenticationMethods attribute changes. It would seem logical to me that I could set Kerberos (IWA) for internal clients and a form for external ones. But in practice, it doesn't work. Whether I use the internal or external URL in the browser, I connect from a completely different network, the computer is not in the domain, so the internal authentication method is always used.

After changing the authentication method, it is displayed that an IIS restart is required. Some changes take effect immediately without a restart, but for the more fundamental ones, a restart is required. We can use the iisreset command or a combination (which restarts only the web service)

net stop was /y
net start w3svc

Information is also displayed that for OWA and ECP, we should use the same authentication method.

Exchange ActiveSync

Documentation Exchange ActiveSync, Set-ActiveSyncVirtualDirectory, Get-ActiveSyncVirtualDirectory

Finding current settings

[PS] C:\>Get-ActiveSyncVirtualDirectory | FL Server,external*,internal*

Server                        : MAIL1
ExternalUrl                   : https://mail.firma.cz/Microsoft-Server-ActiveSync
ExternalAuthenticationMethods : {}
InternalUrl                   : https://mail.firma.local/Microsoft-Server-ActiveSync
InternalAuthenticationMethods : {}

Setting addresses for client services

To set the internal and external domain names, we can use the Exchange Management Shell and a group of commands. We will set the name of the Exchange server (we can call it for the next ones) and the internal and external addresses.

$s = "mail1"
$urlI = "mail.firma.local"
$urlE = "mail.firma.local"

Get-OutlookAnywhere -Server $s | Set-OutlookAnywhere -InternalHostname $urlI -ExternalHostname $urlE

Get-MapiVirtualDirectory -Server $s | Set-MapiVirtualDirectory -InternalUrl https://$urlI/mapi -ExternalUrl https://$urlE/mapi
Get-OwaVirtualDirectory -Server $s | Set-OwaVirtualDirectory -InternalUrl https://$urlI/owa -ExternalUrl https://$urlE/owa
Get-ActiveSyncVirtualDirectory -Server $s | Set-ActiveSyncVirtualDirectory -InternalUrl https://$urlI/Microsoft-Server-ActiveSync -ExternalUrl https://$urlE/Microsoft-Server-ActiveSync

Get-EcpVirtualDirectory -Server $s | Set-EcpVirtualDirectory -InternalUrl https://$urlI/ecp -ExternalUrl https://$urlE/ecp
Get-WebServicesVirtualDirectory -Server $s | Set-WebServicesVirtualDirectory -InternalUrl https://$urlI/EWS/Exchange.asmx -ExternalUrl https://$urlE/EWS/Exchange.asmx
Get-OabVirtualDirectory -Server $s | Set-OabVirtualDirectory -InternalUrl https://$urlI/OAB -ExternalUrl https://$urlE/OAB
Get-PowerShellVirtualDirectory -Server $s | Set-PowerShellVirtualDirectory -InternalUrl https://$urlI/powershell -ExternalUrl https://$urlE/powershell

Autodiscover service

Documentation Autodiscover service in Exchange Server, Autodiscover for Exchange, Mastering Autodiscover

Autodiscover is an important service that provides information for configuring the client connection to the mailbox using various protocols. It is an XML document with a number of data. It is assembled by the Exchange server to which I connect, based on the settings for the individual client services of the given user. The address of the Autodiscover service is determined in several places.

For Autodiscover, a Virtual Directory is also used, and we can view the settings. Here there are no URLs, they are set in another place.

[PS] C:\>Get-AutodiscoverVirtualDirectory | FL Server,*AuthenticationMethods

Server                        : MAIL1
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

[PS] C:\>Get-ClientAccessService | FL Name,AutoDiscoverServiceInternalUri,AutoDiscoverSiteScope

Name                           : MAIL1
AutoDiscoverServiceInternalUri : https://mail.firma.local/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope          : {Praha}

Service Connection Point (SCP) in AD DS

For clients who are domain members, the SCP record is first searched in AD DS. Sites are used. We can view the current data using the script Retrieving Exchange Autodiscover SCP information from AD via PowerShell or use the Active Directory Sites and Services tool and navigate to Services - Microsoft Exchange - Firma - Administrative Groups - Exchange Administrative Group (FYDIBOHF23SPDLT) - Servers - MAIL1 - Protocols - Autodiscover - object properties MAIL1

• attribute serviceBindingInformation - contains the Autodiscover address
• attribute keywords - contains the GUID by which this object is searched, a list of Sites for which it will be used

We update the SCP object by setting the URL on CAS. We don't need to set the Site.

Set-ClientAccessService mail1 -AutoDiscoverServiceInternalUri https://mail.firma.local/Autodiscover/Autodiscover.xml
Set-ClientAccessService mail1 -AutoDiscoverSiteScope Praha

Standard URLs

The next step is to search for predefined URLs that are based on the domain from the SMTP address

• https://<SMTP-address-domain>/autodiscover/autodiscover.xml
• https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml

SRV record

In the final stage, if the previous steps failed, an unauthenticated (unencrypted) query will first be tried at https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml.

Then an SRV record is searched for in DNS _autodiscover._tcp.<smtp-address-domain>. When using this option, we can use the same URL from the internet for other services as well as Autodiscover. And thus have a certificate with only one name.

Autodiscover during migration

If we are migrating from Exchange 2010 to 2016, it is a good idea to redirect the Autodiscover service to the new Exchange servers before moving the first mailboxes. Because if the client has a mailbox (mailbox) on the Exchange 2016 server and connects to get Autodiscover information on Exchange 2010, it will not get the information, but a redirect (redirect) to the Exchange 2016 server. And that can sometimes be troublesome. Whereas when connecting to Exchange 2016, it doesn't matter if the client has a mailbox on 2010 or 2016, but they will always get the configuration file with the data according to the server where their mailbox is.

Before I made this change, the problem was repeatedly manifested. In many cases, the redirect (Status 302) to Exchange 2016 was successful and the Autodiscover was correctly downloaded (Status 200). But occasionally Exchange 2016 returned 302 instead of 200, nothing was downloaded, and Outlook tried other options to find Autodiscover.

If we want to set the SCP address on Exchange 2010, we must do it on it with the command

Set-ClientAccessServer MAILOLD -AutoDiscoverServiceInternalUri https://mail.firma.local/Autodiscover/Autodiscover.xml

Autodiscover tests and troubleshooting

We can test the Autodiscover functionality directly from MS Outlook and view the process of finding the information.

• launch Outlook
• click Ctrl + right mouse button on the Outlook icon in the notification area (next to the clock)

• we have the Connection Status option here, which will show a lot of information about the current connection (we can see the connection to Exchange 2010 RPC/TCP protocol and to Exchange 2016 HTTP) On Exchange 2010 we saw a few connections to various services. On Exchange 2016, we will probably see many connections and often for other email addresses, this is connecting to shared calendars

• the second option is Test E-mail AutoConfiguration, where we can test the Autodiscover service, the log will show the process of finding the URL and downloading the XML, the results include the content of the configuration data

In Outlook, we can enable Debug, where we will learn even more information. Description How to enable global and advanced logging for Microsoft Outlook

In the registry HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Mail we create a DWORD item EnableLogging with a value of 1. We turn on Outlook. A number of logs will be created in the %temp% folder. Outlook 2010 has a nice Autodiscover log in the olkdisc.log file, but Outlook 2016 doesn't seem to have anything like that.

Outlook client connection issues

With some clients, various problems occurred after the transition to Exchange 2016. On the internet, they are often discussed and usually have different solutions. In general, I was able to solve the problems, even though an occasional problem with Outlook connection still occasionally appears. The main problems for users:

• Public Folders - slow display of items in public folders (the larger the size, the slower the display)
• Public Folders - when we add some public folders to our Favorites, they sometimes all disappear and we have to add them again
• Outlook is sometimes Disconected, no operation changes anything (not even restarting the station), it connects by itself after about 10 minutes

Maximum Allowed Sessions Per User

When I was investigating the problems, I encountered a regularly logged event with Event ID 9646 in the Application log of the Exchange server.

Mapi session /o=Firma/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user81faa068 with client type MoMT
 exceeded the maximum of 32 objects of type Session.

The log does not show which user it is, which we can find out with the command:

[PS] C:\>Get-Mailbox "/o=Firma/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user81faa068"

Name                Alias        ServerName  ProhibitSendQuota
----                -----        ----------  -----------------
Bouška Petr         bouska       mail2       Unlimited

If we want to generally increase the connection limit, we can do it in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem, where we create a value (DWORD 32) Maximum Allowed Sessions Per User and set it to maybe 500. Afterwards, it is necessary to restart the Microsoft Exchange Information Store service.

People often solve this error in connection with public folders, for example Exchange 2016- EVENT ID 9646 - MoMT exceeded the maximum of 32 objects of type Session, Exchange16/ Outlook16 - client type MoMT exceeded the maximum of 32 objects of type Session.

It is mentioned in some places that the problem with the number of connections (sessions) appears if we have Exchange Cached Mode. Now when shared calendars are opened, a connection is created for each calendar we have stored. It is recommended to turn off Download shared folders (in the account settings, Advanced tab). But sessions for calendars are still created, so it probably has no effect.

In some places (Exchange 2016 MapiExceptionSessionLimit, Exchange 2016 Defaults) there is talk of increasing two more limits under the MaxObjsPerMapiSession key, the values objtFolder and objtFolderView.

But it is questionable whether some of the above settings have an impact on the described problems. Public Folder issues are solved in the next chapter. Client connections were helped by adjusting the authentication methods and configuring DNS resolution in the internal network so that the public names of Exchange were translated to internal addresses.

Public Folders - slow display of each message

To solve various Outlook problems, it is recommended to switch it to Online Exchange mode. In general, there are various discussions about whether it is better to operate in Cached vs. Online Exchange mode. By default, Cached Exchange Mode is used (but only with a year's history) and it will probably be more advantageous. In Online mode, each message must be downloaded from the server on each access.

I solved the problem of very slow display of items in public folders, the own mailbox worked fine. But when I switched the account to Online mode, the display of items in the mailbox slowed down in the same way. Access through the OWA web interface worked without problems.

When searching, people often find the referenced article Outlook in Online mode is slow connecting to Exchange 2013, where the adjustment of TCP acknowledgement is discussed, which is quite a drastic thing and I didn't even try it. Various other mentions also lead to network problems and maybe a bug in VMware Tools Outlook Slow in Online Mode.

I tried a simpler thing, running Outlook without plugins

Outlook /safe

And presto, everything worked fine. After a few attempts with disabling plugins, it turned out that the problem was with the Kaspersky Outlook Anti-Virus Addin. Then I also found the article and discussion Exchange 2016 - Poor Outlook 2016 Performance - Troubleshooting, KES 11 - Slow outlook app after installing KES 11, where there is also advice on adjusting the KES settings so that the plugin doesn't have to be turned off.