• Call Toll Free: 1-855-909-3300

Introspecting Client Access Namespaces Making Difference In Exchange Server 2016 Migration

While reviewing your existing environment to migrate to Exchange 2016, you must take the opportunity to review your client access namespace configuration.

The client access namespaces for Exchange are the DNS names which clients connect with Outlook, mobile devices, web browsers, and so on. Mostly client connectivity to the Exchange namespaces happens over HTTPS and hence requires correctly configured SSL certificates. Please note that POP and IMAP use their own secure login which is also encrypted using SSL certificates. The Namespace configuration and SSL certificates go hand in hand, as the namespaces in use for Exchange require to be included on the SSL certificates being used over the server.

A mis-configured namespace adds a migration to a new Exchange server more difficult, and might result in poor user experience during the transition. Therefore, if there is a namespace problem, it’s best to explore it up front.

Host your Accounting Software in secured Cloud

At the time of the initial deployment of your present Exchange environment the namespaces must have been reconfigured to use DNS aliases rather than of real server names, even for single server implementations. Using DNS aliases permits the namespace to be migrated during server replacement, load-balanced across several multiple servers in case the environment scales out to a high availability implementation, and also permits the namespace to be migrated to a brand new version of Exchange during an upgrade project. Utilizing DNS aliases is also easy and simpler for end users to remember. Generally users only require knowing the URL for Outlook web access, with names like webmail.notrealuniversity.com or mail.notrealuniversity.com generally used.

In case you named your Exchange server “mail” or “webmail” as that was the URL which you wanted your users to use that while accessing Outlook Web App, this is going to be a issue now which you are upgrading to a new Exchange server. Two Exchange servers may not have the same name, and you might not do an in-place upgrade of the existing server to Exchange 2016. You are also not allowed to rename the existing Exchange server. Therefore, you might need to switch over to a temporary namespace while you execute the migration, and then re-deploy the preferred namespace later.

In case of the Not Real University environment there is an Exchange 2010 server, also an Exchange 2013 server. This offers an opportunity to illustrate the process of analyzing namespaces for both of the editions of Exchange which you can migrate to Exchange 2016 from.

REANALYZING HTTPS NAMESPACE CONFIGURATIONS

The given Exchange 2010 and 2013 have the following HTTPS services:

  • Outlook Anywhere
  • Outlook Web App (OWA)
  • Offline Address Book (OAB)
  • Exchange ActiveSync (EAS)
  • Exchange Web Services (EWS)
  • Exchange Control Panel (ECP)
  • Autodiscover

Exchange 2013 also includes the MAPI-over-HTTP service, also known simply as MAPIHttp.

The client access namespaces for HTTPS services over Exchange are configured in various places, based on the version of Exchange being used. A simple and easy way to retrieve the client access namespaces is to utilize the GetExchangeURLs.ps1 script. For the case of Exchange 2010 servers you might expect the Outlook Anywhere external URL to be empty, also, the MAPIHttp URLs. For the given Exchange 2013, all servers must return URLs.

[PS] C:\Scripts>.\GetExchangeURLs.ps1 -Server NREXCH10,NREXCH13

—————————————-
Querying NREXCH10
—————————————-

Outlook Anywhere
– Internal:
– External: mail.notrealuniversity.com

Outlook Web App
– Internal: https://mail.notrealuniversity.com/owa
– External: https://mail.notrealuniversity.com/owa

Exchange Control Panel
– Internal: https://mail.notrealuniversity.com/ecp
– External: https://mail.notrealuniversity.com/ecp

Offline Address Book
– Internal: https://mail.notrealuniversity.com/OAB
– External: https://mail.notrealuniversity.com/OAB

Exchange Web Services
– Internal: https://mail.notrealuniversity.com/EWS/Exchange.asmx
– External: https://mail.notrealuniversity.com/EWS/Exchange.asmx

MAPI
– Internal:
– External:

ActiveSync
– Internal: https://mail.notrealuniversity.com/Microsoft-Server-ActiveSync
– External: https://mail.notrealuniversity.com/Microsoft-Server-ActiveSync

Autodiscover
– Internal SCP: https://autodiscover.notrealuniversity.com/Autodiscover/Autodiscover.xml

—————————————-
Querying NREXCH13
—————————————-

Outlook Anywhere
– Internal: mail.notrealuniversity.com
– External: mail.notrealuniversity.com

Outlook Web App
– Internal: https://mail.notrealuniversity.com/owa
– External: https://mail.notrealuniversity.com/owa

Exchange Control Panel
– Internal: https://mail.notrealuniversity.com/ecp
– External: https://mail.notrealuniversity.com/ecp

Offline Address Book
– Internal: https://mail.notrealuniversity.com/OAB
– External: https://mail.notrealuniversity.com/OAB

Exchange Web Services
– Internal: https://mail.notrealuniversity.com/EWS/Exchange.asmx
– External: https://mail.notrealuniversity.com/EWS/Exchange.asmx

MAPI
– Internal: https://mail.notrealuniversity.com/mapi
– External: https://mail.notrealuniversity.com/mapi

ActiveSync
– Internal: https://mail.notrealuniversity.com/Microsoft-Server-ActiveSync
– External: https://mail.notrealuniversity.com/Microsoft-Server-ActiveSync

Autodiscover
– Internal SCP: https://autodiscover.notrealuniversity.com/Autodiscover/Autodiscover.xml

Finished querying all servers specified.

In the above shown output we can observe that the client access namespaces being utilized for HTTPS services are:

mail.notrealuniversity.com
and autodiscover.notrealuniversity.com (for Autodiscover)

In few case you might observe distinguished namespaces for every service, in case they are not using a unified namespace. It’s also very common to observe a different Autodiscover namespace being used, same as is the case with Not Real University. Automatically, by default, namespaces use the complete-qualified domain name of the server. For instance, the default URL configured over the OWA virtual directory for a server named NREXCH10 in the notrealuniversity.com domain ishttps://nrexch2010.notrealuniversity.com/owa.

In case you see any real server FQDNs being used, it is an example of a mis-configured namespace, and it must be corrected before the migration project continues, via re-configuring the server to utilize a DNS alias as the namespace.

Kindly Note: The URL for the Autodiscover service, also known as the Autodiscover SCP, is setup and configured on the Client Access server role by executing the Set-ClientAccessServer cmdlet for Exchange 2010, either/or the Set-ClientAccessService cmdlet for Exchange 2013. The Get- cmdlets are utilized to access the current configuration. And the Autodiscover virtual directory itself, that is visible in IIS Manager and also while running Get-AutodiscoverVirtualDirectory, is not utilized to configure the Autodiscover namespace. You might ignore any URLs setup and configured over the Autodiscover virtual directory.

ANALYZING MAPI/RPC NAMESPACE CONFIGURATION SETUP FOR EXCHANGE 2010

Addition to the HTTPS namespaces, the RPCClientAccessServer (or CAS Array) setup configuration for Exchange 2010 must be reviewed. First, validate the RpcClientAccessServer attribute for the Exchange 2010 mailbox databases, that is the RPC endpoint which internal Outlook clients connect for mailbox access.
[PS] C:\>Get-MailboxDatabase | Select Name,RpcClientAccessServer

Name RpcClientAccessServer
—- ———————
DB2010 NREXCH10.notrealuniversity.com
In a condition when the outcomes display a real server name being used as the RpcClientAccessServer, then it’s very likely a CAS Array was never implemented. For a case the results depict a DNS alias, like, “casarray.notrealuniversity.com”, and then a CAS Array was implemented. You can examine the CAS Array object itself by executing the Get-ClientAccessArray cmdlet. There should be a corresponding DNS entry for the CAS Array name that resolute to the single Exchange 2010 server’s IP address, or addresses to a virtual IP address present over a load balancer. In few environments the CAS Array IP address is playing a vital role to resolute to the IP address of a database present group that is not a valid configuration.

The main key issue with the CAS Array is whether the namespace used is distinguished from that used for other Exchange servers, like Outlook Anywhere. The CAS Array namespace must be unique. In case it is not unique, then you consist of what is known as an ambiguous namespace. In such condition the migration to Exchange 2016 from Exchange 2010 can’t begin till little remediation work is executed first.

The CAS Array, in case one was deployed, will continue to be used by Outlook for Exchange 2010 mailbox users till they are migrated to Exchange 2016. The CAS Array itself is not needed after the migration has been concluded, as there is no CAS Array exist for Exchange 2016 (Though you can still load-balance the client access namespaces throughout multiple servers, there’s just no CAS Array object used). Outlook clients use Outlook Anywhere or MAPIHttp for internal connectivity to Exchange 2016 rather than MAPI/RPC.

RE-ANALYZING POP/IMAP CONFIGURATIONS

Attractive Plans Available for Application Hosting

As the POP and IMAP services are not enabled automatically by default, it’s probable that they aren’t even being used in your environment. You can utilize Get-Service to analyze the POP and IMAP service status for your Exchange servers.

[PS] C:\>Get-ExchangeServer | % {Invoke-Command -ComputerName $_.Name {Get-Service MSExchangeImap*;Get-Service MSExchangePop*}}

Status Name DisplayName PSComputerName
—— —- ———– ————–
Stopped MSExchangeImap4 Microsoft Exchange IMAP4 NREXCH10
Stopped MSExchangePop3 Microsoft Exchange POP3 NREXCH10
Stopped MSExchangeImap4 Microsoft Exchange IMAP4 NREXCH13
Stopped MSExchangeIMAP4BE Microsoft Exchange IMAP4 Backend NREXCH13
Stopped MSExchangePop3 Microsoft Exchange POP3 NREXCH13
Stopped MSExchangePOP3BE Microsoft Exchange POP3 Backend NREXCH13
If POP or IMAP services are running, you can inspect the settings to try and determine what namespaces are used by clients for POP, IMAP, and SMTP. For POP and IMAP, the internal and external connection settings can be reviewed by running Get-PopSettings or Get-ImapSettings. You can also get a hint from the X509CertificateName setting, which should be configured to a DNS alias that has been included on an SSL certificate installed on the server. For example, to view the POP settings for the Exchange 2013 server in Not Real University, the following command is used.

[PS] C:\>Get-PopSettings -Server NREXCH13 | Select *ConnectionSettings,X509*

InternalConnectionSettings : {NREXCH13.notrealuniversity.com:995:SSL, NREXCH13.notrealuniversity.com:110:TLS}
ExternalConnectionSettings : {}
X509CertificateName : mail.notrealuniversity.com

Those values which are configured over the POP/IMAP settings are visible to end users in OWA, however, are not used by Autodiscover, and it’s common to explore that they have not been configured even though other DNS names are mainly used for clients to connect. In both ways, clients still require to be manually configured. In the given example above, the default values are available, which depicts that either POP clients are connecting to the server’s actual real name, or another DNS alias is used which has not been added to the POP settings over the server.

Host your Accounting Software in secured Cloud

For SMTP settings generally used by POP/IMAP clients, you can verify the receive connector settings on the Exchange servers to find out whether they are advertising their FQDN for client configuration. For instance, on an Exchange 2013 server the following mentioned command is used.

[PS] C:\>Get-ReceiveConnector “Client Frontend*” | Select Name,Fqdn,Advertise*

Name : Client Frontend NREXCH13
Fqdn : NREXCH13.notrealuniversity.com
AdvertiseClientSettings : False
In case of Exchange 2010 server, a same type of command is used.
[PS] C:\>Get-ReceiveConnector “Client*” | Select Name,Fqdn,Advertise*

Name : Client NREXCH10
Fqdn : NREXCH10.notrealuniversity.com
AdvertiseClientSettings : False

In the case of the POP/IMAP settings, the values for SMTP are advertised in OWA and are not utilized by Autodiscover. And the Clients are still get manually configured for SMTP settings, and might be connecting to a DNS alias instead.

No matter what results you get for POP/IMAP and SMTP as shown above, it’s still worth checking your DNS zone for any obvious DNS aliases that might be in use by your clients, such as pop.notrealuniversity.com. Similarly, reviewing the configuration of some POP/IMAP users (if you know of any) would also be useful. If you need to identity some POP/IMAP users, you can temporarily enable protocol logging and look for usernames that are logging on. For example, to enable protocol logging for POP, use the following command.

[PS] C:\>Set-PopSettings -Server NREXCH10 -ProtocolLogEnabled $true

Note: Don’t leave POP or IMAP protocol logging enabled longer than you require to. There is no by default automatic log retention for POP/IMAP protocol logging, hence the log files will easily continue to grow till they utilize all available disk space.

Leave a Reply

Techarex NetWorks Products