During your review of your existing environment as you prepare to migrate to Exchange 2016, you should take the opportunity to review your client access namespace configuration.
The client access namespaces for Exchange are the DNS names that clients connect to with Outlook, web browsers, mobile devices and so on. Most client connectivity to the Exchange namespaces occurs over HTTPS and therefore requires correctly configured SSL certificates. POP and IMAP use their own secure login that is also encrypted using SSL certificates. Namespace configuration and SSL certificates go hand in hand, because the namespaces in use for Exchange need to be included on the SSL certificates being used on the server.
A mis-configured namespace makes a migration to a new Exchange server more difficult, and can result in poor user experience during the transition. So if there is a namespace problem, it’s best to discover it up front.
During the initial deployment of your existing Exchange environment the namespaces should have been reconfigured to use DNS aliases instead of real server names, even for single server deployments. Using DNS aliases allows the namespace to be moved during server replacement, load-balanced across multiple servers if the environment scales out to a high availability deployment, and also allows the namespace to be migrated to a new version of Exchange during an upgrade project. Using DNS aliases is also simpler for end users to remember. Typically users only need to know the URL for Outlook web access, with names such as webmail.notrealuniversity.com or mail.notrealuniversity.com commonly used.
For the Not Real University environment there is an Exchange 2010 server, and an Exchange 2013 server. This provides us with the opportunity to demonstrate the process of reviewing namespaces for both of the versions of Exchange that you can migrate to Exchange 2016 from.
Reviewing HTTPS Namespace Configurations
Both Exchange 2010 and 2013 have the following HTTPS services:
- Outlook Anywhere
- Outlook Web App (OWA)
- Exchange Control Panel (ECP)
- Offline Address Book (OAB)
- Exchange Web Services (EWS)
- Exchange ActiveSync (EAS)
- Autodiscover
Exchange 2013 also has the MAPI-over-HTTP service, sometimes referred to simply as MAPIHttp.
The client access namespaces for HTTPS services in Exchange are configured in several places, depending on the version of Exchange being used. A simple way to retrieve the client access namespaces is to use the GetExchangeURLs.ps1 script. For Exchange 2010 servers you can expect the Outlook Anywhere internal URL to be empty, as well as the MAPIHttp URLs. For Exchange 2013, all servers should 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 output above we can see that the client access namespaces being used for HTTPS services are:
- mail.notrealuniversity.com
- autodiscover.notrealuniversity.com (for Autodiscover)
In some environments you might see different namespaces for each service, if they are not using a unified namespace. It’s also common to see a different Autodiscover namespace being used, as is the case with Not Real University. By default, namespaces use the fully-qualified domain name of the server. For example, the default URL configured on an OWA virtual directory for a server named NREXCH10 in the notrealuniversity.com domain is https://nrexch2010.notrealuniversity.com/owa. If you see any real server FQDNs being used, that is an example of a mis-configured namespace, and it should be corrected before the migration project continues, by re-configuring the server to use a DNS alias as the namespace.
Reviewing MAPI/RPC Namespace Configuration for Exchange 2010
In addition to the HTTPS namespaces, the RPCClientAccessServer (or CAS Array) configuration for Exchange 2010 should be reviewed. First, check the RpcClientAccessServer attribute for the Exchange 2010 mailbox databases, which is the RPC endpoint that internal Outlook clients connect to for mailbox access.
[PS] C:\>Get-MailboxDatabase | Select Name,RpcClientAccessServer Name RpcClientAccessServer ---- --------------------- DB2010 NREXCH10.notrealuniversity.com
If the results show a real server name being used as the RpcClientAccessServer, then it’s likely a CAS Array was never implemented (you can still check anyway, which we’ll look at next). If the results show a DNS alias, such as “casarray.notrealuniversity.com”, then a CAS Array was implemented. You can check for the CAS Array object itself by running the Get-ClientAccessArray cmdlet. There should also be a corresponding DNS entry for the CAS Array name, which resolves to the single Exchange 2010 server’s IP address, or resolves to a virtual IP address on a load balancer. In some environments the CAS Array IP address is found to resolve to the IP address of a database availability group, which is not a valid configuration (although it does happen to work, just badly).
The key issue with the CAS Array is whether the namespace used is different to that used for other Exchange servers, such as Outlook Anywhere. The CAS Array namespace should be unique. If it is not unique, then you have what is known as an ambiguous namespace. Under this condition the migration to Exchange 2016 from Exchange 2010 can’t begin until some remediation work is performed first. Microsoft has documented the solutions to fixing an ambiguous namespace for Exchange 2010 environments here.
The CAS Array, if one was implemented, will continue to be used by Outlook for Exchange 2010 mailbox users until they are migrated to Exchange 2016. The CAS Array itself is not required after the migration has been completed, as there is no CAS Array for Exchange 2016 (although you can still load-balance the client access namespaces across multiple servers, there’s just no CAS Array object used). Outlook clients use Outlook Anywhere or MAPIHttp for internal connectivity to Exchange 2016 instead of MAPI/RPC.
Reviewing POP/IMAP Configurations
Because the POP and IMAP services are not enabled by default, it’s possible they aren’t even being used in your environment. You can use Get-Service to review 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
The values configured in the POP/IMAP settings are visible to end users in OWA, but are not used by Autodiscover, and it’s common to find that they have not been configured even though other DNS names are used for clients to connect. Either way, clients still need to be manually configured. In the example above, the default values are present, which indicates that either POP clients are connecting to the server’s real name, or another DNS alias is used that has not been added to the POP settings on the server. In this case, Not Real University simply does not use POP or IMAP, and the services themselves are not running as you saw earlier.
For SMTP settings used by POP/IMAP clients, you can check the receive connector settings on the Exchange servers to determine whether they are advertising their FQDN for client configuration. For example, on an Exchange 2013 server the following command is used.
[PS] C:\>Get-ReceiveConnector "Client Frontend*" | Select Name,Fqdn,Advertise* Name : Client Frontend NREXCH13 Fqdn : NREXCH13.notrealuniversity.com AdvertiseClientSettings : False
On an Exchange 2010 server, a similar command is used.
[PS] C:\>Get-ReceiveConnector "Client*" | Select Name,Fqdn,Advertise* Name : Client NREXCH10 Fqdn : NREXCH10.notrealuniversity.com AdvertiseClientSettings : False
As with the POP/IMAP settings, the values for SMTP are advertised in OWA and are not used by Autodiscover. Clients are still manually configured for SMTP settings, and could 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
Summary
In this article we looked at reviewing the namespace configuration of your existing Exchange servers. We looked at how to retrieve the namespaces used for HTTPS services, RPC access in Exchange 2010, and also how to determine the namespaces that may be in use for POP, IMAP, and SMTP. In the next part of this series we’ll look at how to review your SSL certificates when planning a migration to Exchange 2016.
[adrotate banner=”51″]
This was my first Exchange 2010 to Exchange 2016 and with your guidance I was able to complete the migration without a glitch. Some people sell these type of migration guides, while you generously share your knowledge with the world. You’re amazing. Thank you, Paul!
In my case, I have the following:
All Internal: mail.xyz. local
All External: mail.xyz.com
Do I face a problem during migration to exchange 2016 (Only I have Exchange 2010)?
” Exchange 2010 can’t proxy Autodiscover requests to Exchange 2016, so if you have Autodiscover resolving in DNS to the Exchange 2010 server, any Exchange 2016 mailbox users will not be able to use Autodiscover.” What if I leave the autodiscover uri for scp 2016 server as the servername.domain.com. Will the outlook (2016 mailbox) client fail when trying the 2010 scp but then try this 2016 scp ? In this case it might work….
“For Exchange 2010 servers you can expect the Outlook Anywhere external URL to be empty”
Do you mean the internal URL should be emtpy?
Hey Paul,
I have Exchange 2010 Environment with Microsoft NLB / Cas Array for internal Users and a Kemp LB for External Users. Kemp has a official Wildcard Cert and the Internal 2010 Servers a Interal Signed CA Cert
Internal CAS Name is cas.domain.lan
External autodiscover.domain.de / cas.domain.de
When we installed the New Exchange 2016 Server we would use for Autodiscover and VirtualURLS:
external email.domain.de
Internal email.domain.de
Autodiscover should be autodiscover.domain.de
OWA ECP and Virtual Directorys woking fine. The Problem is Autodiscover
On a Outlook with a Mailbox on 2010 its working over NLB when i switch DNS to point to KEMP LB with VIP for Exchange 2016 it doesnt work
On a Outlook with a Mailbox on 2016 Outlook Displays the cas.domain.lan in Microsoft Exchange Server and cant connect.
Is it posible to change the .lan through .de during the migration? All Servers are in the same site
Don’t change the CAS Array namespace in DNS. It remains pointing at Exchange 2010. The CAS Array namespace is not used by Exchange 2013 or 2016. Only change the other HTTPS namespaces (Outlook Anywhere, OWA, ActiveSync, etc).
Thank you for taking the time to put everything together. This site is extremely helpful.
I have questions regarding 2010 and 2016 coexist environment,what is default status MAPI over http and rpc over http protocol, is mapi on by default and is there any impact on rpc over http for clients whose mailbox are on exchange 2010?
My environment has a set of 2010 CAS-Array behind a loadbalancer providing all the rpc and all other https services to the clients. When the 2016 servers are introduced to the environment, should the 2010 CAS-Array be taken out of the loadbalancer and replace with 2016 servers provide the sames services to the clients including the Autodiscover service?
Hey Paul,
great article!
I have one question, if the autodiscoverSCP is configured to https://autodiscover.domain.tld/autodiscover/autodiscover.xml for exchange 2010 and also for exchange 2016. That’s not working in my opinion and the autodiscoverSCP must be different if you migrate from exchange 2010 to exchange 2016. Otherwise the Outlook connectivity will fail for mailboxes are still in exchange 2010.
Am I right?
Thanks in advance
Tom
The Autodiscover SCP should be the same for all servers within an AD Site. The Autodiscover SCP must resolve in DNS to the highest version of Exchange in the site as well. So in a 2016/2010 coexistence scenario where both servers are in the same AD Site, they should have the same Autodiscover SCP configured, and that DNS record should point to Exchange 2016, not Exchange 2010. Exchange 2016 proxies Autodiscover requests to the appropriate server, so in effect it can answer Autodiscover queries for mailbox users on both 2016 and 2010. Exchange 2010 can’t proxy Autodiscover requests to Exchange 2016, so if you have Autodiscover resolving in DNS to the Exchange 2010 server, any Exchange 2016 mailbox users will not be able to use Autodiscover.
Hi Paul, and thanks for your great work.
I agree with Tom. If the internal SCP is the same in the legacy Exchange 2010 server than the new Exchange 2016, then it’s like a Ping Pong match between the two environments. At least, I’m unable to get it working. My 2016 server doesn’t proxy the autodiscover back to 2010 if the 2010 SCP points to the same 2016 server.
When I change the 2010 SCP to the 2010 server itself, it begins to work.
Any suggestion? 3 days searching with no solution yet
Regards.
What value were you using for each of the 2010 and 2016 SCP URLs?
The same one:
https://autodiscover.mycompany.com/Autodiscover/Autodiscover.xml
Also, I get “HTTP 500” response when I try to put in a browser this URL and I try to logon with a 2010 mailbox. If I login with 2016 mailbox works good, XML is shown.
The problem is only with Outlook. Not with OWA, Active-Sync, etc.
I’m stuck. 🙁
Something is wrong then. It is supposed to work that way. But there might be something else, perhaps an IIS setting that’s been changed or something like that. I would recommend you open a support case with Microsoft to get some other eyes on the problem.
Hi Paul, In the middle of this migration myself…I have changed the hosts file on one machine to point to my new 2016 server for both mail.domain.com and autodiscover.domain.com. This works fine until I actually migrate that mailbox to the 2016 database. Then, Outlook and autodiscover fail to work. Should this be working with just the hosts file change on the client, or will this not work until I make the system-wide DNS change?
Hi Paul,
When I ran the “Get-MailboxDatabase” again the Exchnage 2016 databases, the “RPCClientACcessServer” point to the Exchange 2010’s CAS array, is this correct or I have to remove it.
Thanks,
Doesn’t matter, Outlook clients for Exchange 2016 mailbox users will ignore it.
I see the same result when I do Get-MailboxDatabase, however I have clients specifically over VPN that are unable to connect to Exchange 2016. I believe it has to do with the CAS Array as that is the URL that resolves even if I put the FQDN of exchange 2016 into Outlook.
I have verified DNS resolves correctly to both Exchange 2010 and 2016. Do I need to remove the cas array config to get my users back working with Outlook over VPN?
We are almost done with our migration Public Folders is moving soon then decommission.
“I have verified DNS resolves correctly to both Exchange 2010 and 2016”
There shouldn’t be any DNS records for Client Access namespaces resolving to *both* 2010 and 2016.
I miss spoke. the casarray.contoso.com and exch16.contoso.com both resolve correctly. We do not have DNS that resolves to both.
I believe we found our problem. Once we removed the cas array on Exch 2010, this allowed our users to autodiscover over VPN and connect successfully to 2016. I’m not sure if this is related to the bug that makes 2016 CAS members of the array or not, but def removing the array corrected our issue.
Well,
I’m in the process of a 2010-2016 migration. On ex2010 a cas array is set. After moving a test mailbox from 2010 db to 2016 db, Outlook cannot connect stays in a disconnected state. This is internal on the domain. SETSPN was removed from 2010 server. Obviously can’t remove the cas array as that would boof all current clients MAPI settings that are pointing to it.
So something is not easy peasy. =D
Do your client access namespaces resolve in DNS to the Exchange 2016 server?
Thanks, Paul
Great article . Thanks!
Great writeup. If a company is on E2010 using mail.company.com (everthing correctly configured) and at the “same time” when moving to E2016 want to change this URL to mail.othername.com (becausr of re-branding), would you recommend doing so before or after the mailbox migration?
Here you go:
https://www.practical365.com/changing-namespaces-exchange-migration/