When you first install Exchange Server 2016 it is pre-configured with default URLs for the various HTTPS services such as OWA (Outlook on the web), ActiveSync (mobile device access), Exchange Web Services (the API used for a variety of client communications), and others.
The default URLs contain the fully qualified domain name of the server. So for example if your server name is “exchange01.domain.com” then the default URL for OWA will be “https://exchange01.domain.com/owa“.
These default URLs allow the services to function but they are not suitable for production deployments for several reasons such as:
- They are difficult for end users to remember (this primarily impacts Outlook on the web, where users tend to find it easier to remember a URL such as “webmail.domain.com“)
- A URL containing a specific server name can’t be load-balanced across multiple servers in a high availability deployment
- The internal AD namespace for many organizations is not a valid domain name on the internet, for example domain.local, which makes it impossible to acquire SSL certificates for Exchange 2016 (I’ll cover SSL certificates in a separate article coming soon)
The recommended practice is to change the URLs configured on your Exchange 2016 servers to aliases or generic host names such as “mail.domain.com” after you first install the server.
While there are a variety of namespace designs that apply to different deployment scenarios I will demonstrate here the simplest approach, which is to configure the same namespace (URL) for all services. I’ll be demonstrating with a single Exchange Server 2016 server, but this approach can also be used if you have multiple Exchange servers that you want to load balance (which I’ll cover in a future article).
In my example scenario:
- The server’s real name is demoex16.exchange2016demo.com
- The namespace I’ll be using is mail.exchange2016demo.com
- Internal and external namespaces will be the same
Using my GetExchangeURLs.ps1 script I can see the current configuration of the server.
PS C:\Scripts\> .\GetExchangeURLs.ps1 -Server DEMOEX16 ---------------------------------------- Querying DEMOEX16 ---------------------------------------- Outlook Anywhere - Internal: demoex16.exchange2016demo.com - External: demoex16.exchange2016demo.com Outlook Web App - Internal: https://demoex16.exchange2016demo.com/owa - External: Exchange Control Panel - Internal: https://demoex16.exchange2016demo.com/ecp - External: Offline Address Book - Internal: https://demoex16.exchange2016demo.com/OAB - External: Exchange Web Services - Internal: https://demoex16.exchange2016demo.com/EWS/Exchange.asmx - External: MAPI - Internal: https://demoex16.exchange2016demo.com/mapi - External: ActiveSync - Internal: https://demoex16.exchange2016demo.com/Microsoft-Server-ActiveSync - External: Autodiscover - Internal SCP: https://demoex16.exchange2016demo.com/Autodiscover/Autodiscover.xml Finished querying all servers specified.
In this article we’ll look at:
- Configuring DNS records for the new namespace
- Configuring the namespaces via the Exchange Admin Center
- Configuring the namespaces via PowerShell
- Using a PowerShell script to speed up the configuration of Client Access namespaces
Configuring DNS Records for the Client Access Namespaces
Before changing your server’s namespace configuration you should make sure that the DNS records for the new namespaces already exist in DNS. Some of the virtual directory configuration tasks can fail if the name you specify isn’t resolvable in DNS.
In this example scenario I’ll be using split DNS, which is a recommended practice for Exchange Server 2016 deployments. Split DNS means I will host a DNS zone on my internal DNS servers, and use that to resolve mail.exchange2016demo.com to the internal IP address of my Exchange server (or load balancer if this was a high availability deployment).
Meanwhile, the public DNS zone also has a mail.exchange2016demo.com record that resolves to the public IP address of my firewall or router, which will then NAT any external connections to the Exchange server’s internal IP.
Add the records to both of the zones in your split DNS configuration and make sure they are resolving correctly before you continue.
PS C:\> Resolve-DnsName mail.exchange2016demo.com Name Type TTL Section IPAddress ---- ---- --- ------- --------- mail.exchange2016demo.com A 3600 Answer 192.168.0.126
Configuring Exchange Server 2016 Namespaces Using the Exchange Admin Center
After logging in to the Exchange Admin Center in your organization navigate to Servers -> Virtual Directories and select the server you want to configure. There are two approaches you can take. The first is clicking the wrench icon to configure the external namespace for one or more servers.
A window appears that allows you to add one or more servers and specify an external namespace to use.
The outcome of this approach is that all of the external URLs are configured to use that namespace, but the internal URLs remain untouched. This is not ideal for our goal of configuring all services to use the same internal and external namespace.
Instead you can edit the configuration of each virtual directory listed in the Exchange Admin Center by clicking the edit icon.
From here you can edit both the internal and external namespaces for the virtual directory, as well as additional settings such as authentication.
This will achieve the desired outcome, but it is a slow and tedious task. For a single server it would be annoying, for multiple servers it would be downright frustrating. Also, if you ever needed to reconfigure the server you’d need to manually repeat the task.
Instead let’s look at using PowerShell to make the namespace configuration changes.
Configuring Exchange Server 2016 Namespaces Using PowerShell
In a previous article on avoiding server names in SSL certificates I demonstrate how to configure each virtual directory in Exchange Server using PowerShell. You can read that article for a full demonstration but in summary you can run cmdlets such as Set-OWAVirtualDirectory to configure the OWA virtual directory internal and external URLs. Each of the other virtual directories has its own cmdlet for configuring settings, including the Autodiscover virtual directory even though we don’t actually need to configure that one (instead we configure the AutodiscoverServiceInternalUri on the Client Access server).
For example, to configure the same URLs for OWA as shown in the screenshot above:
[PS] C:\>Get-OwaVirtualDirectory -Server DEMOEX16 | Set-OwaVirtualDirectory -InternalUrl https://mail.exchange2016demo.com/owa -ExternalUrl https://mail.exchange2016demo.com/owa
As with the Exchange Admin Center this task can become quite tedious as you move through each virtual directory on every server. But of course if the task can be performed in PowerShell it can be scripted!
Using a PowerShell Script to Configure Exchange Server 2016 Client Access Namespaces
Automating boring tasks is one of PowerShell’s great strengths, and this task is no different. Since every virtual directory (and the Autodiscover service URI) can be configured in PowerShell we can write a script to perform the task quickly.
In your own environment you could manually write out each of the PowerShell commands for your server names and simply save them in a script file. Or you can use my ConfigureExchangeURLs.ps1 script with a few easy to use parameters.
Here’s an example of how I can apply my desired namespace configuration to my Exchange 2016 server using ConfigureExchangeURLs.ps1.
PS C:\Scripts\> .\ConfigureExchangeURLs.ps1 -Server demoex16 -InternalURL mail.exchange2016demo.com -ExternalURL mail.exchange2016demo.com ---------------------------------------- Configuring demoex16 ---------------------------------------- Values: - Internal URL: mail.exchange2016demo.com - External URL: mail.exchange2016demo.com - Outlook Anywhere default authentication: NTLM - Outlook Anywhere internal SSL required: True - Outlook Anywhere external SSL required: True Configuring Outlook Anywhere URLs Configuring Outlook Web App URLs WARNING: You've changed the InternalURL or ExternalURL for the OWA virtual directory. Please make the same change for the ECP virtual directory in the same website. Configuring Exchange Control Panel URLs Configuring ActiveSync URLs Configuring Exchange Web Services URLs Configuring Offline Address Book URLs Configuring MAPI/HTTP URLs Configuring Autodiscover
Now let’s look at the output of GetExchangeURLs.ps1 again.
PS C:\Scripts\> .\GetExchangeURLs.ps1 -Server DEMOEX16 ---------------------------------------- Querying DEMOEX16 ---------------------------------------- Outlook Anywhere - Internal: mail.exchange2016demo.com - External: mail.exchange2016demo.com Outlook Web App - Internal: https://mail.exchange2016demo.com/owa - External: https://mail.exchange2016demo.com/owa Exchange Control Panel - Internal: https://mail.exchange2016demo.com/ecp - External: https://mail.exchange2016demo.com/ecp Offline Address Book - Internal: https://mail.exchange2016demo.com/OAB - External: https://mail.exchange2016demo.com/OAB Exchange Web Services - Internal: https://mail.exchange2016demo.com/EWS/Exchange.asmx - External: https://mail.exchange2016demo.com/EWS/Exchange.asmx MAPI - Internal: https://mail.exchange2016demo.com/mapi - External: https://mail.exchange2016demo.com/mapi ActiveSync - Internal: https://mail.exchange2016demo.com/Microsoft-Server-ActiveSync - External: https://mail.exchange2016demo.com/Microsoft-Server-ActiveSync Autodiscover - Internal SCP: https://mail.exchange2016demo.com/Autodiscover/Autodiscover.xml
Now that the namespaces are configured the next step is to configure an SSL certificate for the server. I’ll cover that in an upcoming article.
Summary
In this tutorial we looked at the default namespace configuration of a newly installed Exchange 2016 server, and discussed why we should configure Client Access namespaces for the server. As you can see there are several methods available for making the configuration changes, with the PowerShell script being the easiest by far. If it is your first time configuring a server it is worth doing the task manually the first time to gain some understanding of what is involved, but if you’re planning to deploy multiple servers then using a script such as ConfigureExchangeURLs.ps1 is highly recommended.
Paul,
Thank you so much for your effort and tremendous explanations. It cleaned up my configuration and is a tutorial for me. I learned allot from your articles .
Thanks again!
Hi Paul,
thanks for u great site.
One question. Script used old command The Get-ClientAccessServer cmdlet
You have plane for update scripts for using new command Get-ClientAccessService ?
how about edit the command yourself and do a find-replace for Get-ClientAccessServer to Get-ClientAccessService?
excellent approach. I did so.
Ive always used your script when setting up new Exchange boxes, saves a lot of time and hassle, But now I come to a very odd issue, with one specific user I cannot get Outlook 2016/19 to connect to the Exchange server 2016 (migrated from 2010, either through the wizard or via the 32 bit client app, its doesn’t want to find the EAS, yet with other accounts its fine. removing the profile doesn’t work, Ive had to roll back to Outlook 2013 to get it to work, the only difference with this user AD is that it was renamed ages ago, CAS is setup as should be as per your script work fine for other accounts, Any ideas guys?
Thanks for Your great post Paul.
We have one Q. Recently we modified our company name. We updated all user primary mail IDs with new name and also created Autodiscover SRV record which points to old Autodiscover (_Autodiscover._tcp.newdomain.com = Autodiscover.olddomain.com). Also the UPN has been configured for the new domain. The autodiscover works fine with Outlook anywhere, but for ActiveSync it doesn’t work as we have to change the server URL manually. We didn’t modify the external and internal URLs, still uses the same old and also the wild card doesn’t contain new SMTP domain name. What might be the cause for this, do we need to include new domain name with wild card SAN (we will modify all URL in another weeks with new name)
Dear Paul,
i have installed exchange server 2019 3 month back,
I am very upset because i am not able to stop spammer to use my smtp relay.
i have created the new receive connector for smtp rely for anonymous users for external use.
below are the permission for this new receive connector
User ExtendedRights
—- ————–
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
{ms-Exch-SMTP-Submit
ms-Exch-Accept-Headers-Routing
ms-Exch-SMTP-Accept-Any-Sender
ms-Exch-SMTP-Accept-Any-Recipient
User ExtendedRights
—- ————–
MS Exchange\Externally Secured Servers
ms-Exch-SMTP-Submit
ms-Exch-Accept-Headers-Routing
ms-Exch-Bypass-Message-Size-Limit
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
ms-Exch-SMTP-Accept-Any-Sender
ms-Exch-SMTP-Accept-Exch50
ms-Exch-Bypass-Anti-Spam
ms-Exch-SMTP-Accept-Any-Recipient
ms-Exch-SMTP-Accept-Authentication-Flag
daily i am fighting with alot of external spammer.
they have shoot 1 lacs mail daily through my SMTP relay server
i have installed the GFI essential , but still not able to find the proper solution.
please provide the best solution for external SMTP relay so no body can access the same from outside.
please provide the solution asap.
my domain is seasia.in
Thanks a lot Paul
We are looking for best way to re-configure the namespaces with new domain name.
We have changed our company name and modified primary mail address to @newdomain.com and kept old address @olddomain.com as secondary. Created MX records and SRV record with external DNS which points to old as _Autodiscover._tcp.newdomain.com = Autodiscover.olddomain.com and all users can connect with @newdomain.com. As of now all users are using old address space olddomain.com for mail access. We bought new wild card certificate with *.newdomain.com & *.olddomain.com as SANs and want to re configure the name spaces with minimum interruption for end users.
Our setup consists of 2 X Exchange 2016 servers with F5 load balancer and published the URLs using Firewall. Internally & externally we are using same name space (mail.olddomain.com, internally it points to the load balancer IP and externally to the Firewall IP).
Thanks in advance
Two questions, if you would:
1. I have a machine who’s current FQDN is mail.contoso.com. I want external name of new exhcange to be mail.contoso.com. Is it ok to do the external name setup? the external name will not be updated in public DNS and firewall until after new server is all setup. if that is an issue, I can use another name.
2. Do you setup namespace before or after setting up SSL certificates? If you change external name, do you need to reissue CSR & setup new SSL cert?
Hi Paul,
I migrated from 2010 to 2016, but after uninstalling the 2010 Exchange, i cannot access Exchange by OWA OR Outlook from our braches (connected by IPSec and RED, Sophos).
InternalUri and Stuff are set to mail.domain.ch/owa (mapi to outlook.domain.ch/mapi for internal).
When I access OWA through autodiscover-domain.ch/owa or servername.domain.local/owa, everything works perfectly fine. Do you have any idea, where the problem could be?
Kind regards
Manuel
Hi,
Thank you for all your great work. It has helped me a lot in setting up my Exchange 2016 environment.
I have a question regarding the namespace. I used the config script you published and i setup “autodiscover.domain.com” as both internal and external URLs, on both my Exchange servers. Everything works fine except that sometimes i can’t access the ECP directly from the servers (by going to https://localhost). It redirects me to the autodiscover page which fails to load. Sometimes it works just on one server at a time, sometimes on neither.
Any idea on this? Also, what would be a best practice regarding the ECP access? The customers don’t seem too keen on having the ECP accessible from the internet therefore I had to block it on the firewall level. However if it’s not always reachable internally it presents a big issue. Even if I can do most of the management through PS, the ECP helps a lot.
Thanks and keep up the great work!
Hi Rafael,
As described above, you will typically achieve this by using Split DNS as part of your configuration, so that traffic from internal clients reaches IP addresses/load balancers that are on internal only IPs, allowing you to provide additional security when publishing ECP externally without affecting internal clients.
Steve
Hi Paul,
Thanks for te excellent article.
I think I have to use two different URL’s for OWA because we want to use SSO for our domain joined users, and want Form based authentication for our external mail users.
So I have an internal URL https://internalmail.domain.nl and an external URL https://outlook.domain.nl
We use roundrobin. So for each URL 2 DNS records pointing to the 2 Exchange 2016 servers.
I have the following authentication set up.
Name : owa (Default Web Site)
ClientAuthCleanupLevel : High
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication : True
WindowsAuthentication : True
DigestAuthentication : False
FormsAuthentication : False
LiveIdAuthentication : False
AdfsAuthentication : False
OAuthAuthentication : False
ExternalAuthenticationMethods : {Fba}
For our external clients everything works fine, they get a logon page and can access their mail.
But our internal users get the same form, and have to log in. I expect that they get a seamless experience and can get to their mail without logging in.
Any idea whats wrong whit my config? Thanks in advance.
Thank you for your article. I have a question about SSL settings and URLs
my exchange 2016 servers are setup with a subdomain corp.mycompany.com and I mistakenly purchased a *.mycompany.com certificate thinking it will work with subdomains. I configured my owa settings to be owaus.mycompany.com and the SSL works out fine, however when I attempt to connect and setup using outlook 2016, I get a certificate error saying exch1.corp.mycompany.com is not a valid hostname. My question is there some way I can configure the hostname for outlook configuration to be exch1.mycompany.com instead, or do I have to get another certificate? If I change the dns suffix of my exchange server it breaks even more things.
The Real Person!
The Real Person!
That sounds like you haven’t actually configured all the client access namespaces, and one or more of then is still using the server FQDN. I would start by reviewing that again, if I were you.
On prem users, are finally working fine, as they should be, no cert issues, and the autodiscover works in Outlook.
Off prem users will connect properly when first using the proxy setup method, but then once Outlook validates the user with Exchange, it updates to point it to:
https://exchange.public.net/mapi/emsmdb/Mailboxid=xyz@email.com
That is exactly what it should do, as far as I believe. The issue comes in when after the user has connected to the Exchange for a few minutes, the SSL cert warning pops up saying that autodiscover.email.com is not a valid name. Why does it keep popping this up, and what do I need to do to clear this error? All autodiscover settings for email.com are set to point to autodiscover.public.net.
If I run the built in Test E-Mail configurations tool, every line comes up green and using the exchange.public.net URL that I want it to. So why does Outlook keep popping up the SSL error for an address it doesn’t need to connect to?
Thanks for the article Paul. I’m trying to reconcile Microsoft’s two seemingly contradictory recommendations around Exchange namespaces and Active Directory names. They strongly recommend using a subdomain of your public DNS name for your internal AD name, for example ad.domain.com, where your services and website would be published publicly with the domain.com name.
However, they also recommend using split DNS for Exchange URLs, which would mean I’d have to add, in this example, the domain.com zone into internal DNS, defeating the purpose of using a subdomain for the internal AD name. Do you have a recommendation around how to approach this?
The Real Person!
The Real Person!
It doesn’t defeat the purpose. Your AD namespace and your Exchange namespace are two different things that can be entirely separate domains.
Thanks for the reply. I realize they’re different domains and don’t necessarily match. My question was more are the situation where the namespace you use to publish your Exchange services does match the parent domain of your internal AD domain name.
Example (using @domain.com as the primary SMTP address for users)
Exchange: autodiscover.domain.com
Public corporate website: http://www.domain.com
Internal AD name: ad.domain.com
Internally I’d be forced to add the domain.com zone in DNS to support a split-brain scenario for internal Exchange IPs.
I think I’ve found a solution recommended online in Ace Fekay’s response below. Add service specific zones in internal DNS instead of the entire domain.com zone. For example, add an autodiscover.domain.com DNS zone that resolves to our internal VIP. Do this for other specific service records too.
https://social.technet.microsoft.com/Forums/windows/en-US/148259cc-dfd9-454f-b1ad-7c3468eea6a7/dns-structure-zone-overlap?forum=winserverNIS
Appreciate your time.
Great article. I have pieced this stuff together over the years and still don’t think I have a solid setup. 🙂
Do you have a tutorial for internal and external DNS being separate namespaces. Plus, internal clients (laptops) come in and out of the office network frequently? The confusing part I always get into is the certificate generation and then then the virtual directory settings. Setting the external/internal autodiscover, blah, blah, blah. Makes my head hurt. 🙂
Example:
Internal: mail.aaa.bbbb.com
External: mail.bbbb.com
The key is to make this work for the mobile phones, laptops, etc.
The Real Person!
The Real Person!
Make sure both names are on the certificate. Configure the internal and external URLs as desired. Use DNS to make them resolvable in the appropriate network. Internal URLs should only be internally resolvable, if you’re using different namespaces. Otherwise the client can’t tell the difference and will just the external namespace (which is a problem if you’re expecting to use different internal and external auth settings).
But then you leak internal infrastructure information via the SANs on the certificates.
Thanks as always Paul, the set-clientaccessservice item, is one of the few you can’t fron the console, so that’s important.
But… is it important to change the OutLookAnywhere for any reason?
I mean… shouldn’t anyone who is using that service/technology be on the “outside” already anyhow?
The Real Person!
The Real Person!
Outlook Anywhere is used internally since Exchange 2013. It is being deprecated in favor of MAPIhttp, but it’s still there, so I still recommend you configure the namespace consistent with your overall namespace design.
Autodiscover woes.
From previous comments about how Outlook resolves email addresses to Exchange, there is a sequence that autodiscover follows – if 1 fails go to 2 etc. the problem is if 1 resolves but doesn’t work it never goes to 2.
For example if “autodiscover.domain.com” fails – it looks for “_autodiscover._tcp.domain.com.” – BUT if the first returns anything then it never moves on.
In our latest case the first was returning a hotel guest wifi landing page and so Outlook never moved on to the second – so it just wouldn’t work.
It was so nice in the day when we could manually enter the server details and not have to rely on autodiscover.
Hi!
Thank you very much for such a good article!
My question is a bit out of scope of the article, but googled all the internet and couldn’t find any close information. How do you manage users two different domains if your usernames suffix differs from email suffix? For example, we have domain like ABC.local and out email domain is ABC.com. Outlook 2016 uses email address as username for authentication. Thus UPN != Email. Do you have any expierence regarding this issue?
Thank you very much!
The Real Person!
The Real Person!
Change their UPN to match their primary email address.
Hello Paul,
We have exchange 2016 introduced with exchange 2010 same forest and same exchange organization. Now we are using UAG 2010 to publish OWA and active sync of exchange 2010 (External HTTPS >>> UAG 2010 >>> Exchange 2010 CAS/HT) and to meet the co-existence client access have internal pointed client access to 2016 and working fine.
now our concern is to publish OWA and active sync trough UAG 2010 and pointed exchange 2016 mailbox server. (External network HTTPS >>>> UAG 2010 >>>> Exchange 2016) Does it will work ?
Goal : To use existing UAG 2010 for exchange 2016 OWA and Active sync publishing.
Concern : Does UAG 2010 support 2016.
Regards,
Samim
The Real Person!
The Real Person!
I’ve never deployed UAG, so I don’t know whether it will work with 2016. I think there is some examples online for using UAG with Exchange 2013. I would guess that those articles will work for Exchange 2016 as well.
Thanks paul.
I have raised this concern to microsoft and they answered me that UAG 2010 can be used for exchange 2016 with pass through authentication.
Otherside they also recommends to replace WAP (Pre-Auth) with UAG.
Hello Paul,
I recently concluded a successful installation of Exchange 2016 (Mailbox Role) using Windows 2012 R2 Standard, couldn’t get it installed using Windows 2016 as i was encountering too many errors. Anyways I have two questions:
1. I followed your article to the fullest and I was able to change the namespace to my desired internal URL mail.example.net. I’m able to browse the Exchange Admin Center (EAC) & the DNS i created (ALIAS) is resolved properly. My problem now is that whenever I run the Exchange Management Shell, it won’t connect as it is still pointed to the previous/original namespace when Exchange 2016 was installed
2. I cannot login to the EAC after the installation as the user credentials or my domain account is not being accepted. I read on another article (https://social.technet.microsoft.com/Forums/Lync/en-US/545958bb-6ffb-4568-b238-5b746d7ccf85/exchange-2016-post-install-cant-access-ecp-invalid-username-or-password?forum=Exch2016SD) that I need to run in powershell the command “enable-mailbox “administrator” “. I cannot do this anymore because of the error in #1.
Appreciate your help on this.
Hi Paul
I have scenario that I migrating exchange 2010 to 2016 at two sites, and I need to use bound model.
I have the following:
1. VIP on site A
2. VIP on site B
3. Name spaces are “autodiscover.domain.com, mail.domain.com, mail.sitea.domain.com, mail.siteb.domain.com”
My quarries are:
1. Should I use one autodiscover name space for two sites, and if so which VIP should I point it for DNS record.
2. Should I use Mail.domain.com name space, and if so which VIP should I point it for DNS record.
3. Should I use SRV record for autoiscover, and if so which VIP or DNS record should I point it for DNS record.
The Real Person!
The Real Person!
Does what still apply? Configuring namespaces? Sure. I don’t know your environment or requirements, but I don’t see why you would complicate your DR solution by requiring extra steps for a site failover.
Hey Paul
Does this still apply if you are using GSLB in a multi site configuration with a DR?
If databases are activated on the DR servers, without shutting down the exchange servers in the primary site, will this cause relay or proxy issues for mail access?
Should we be keeping the DR External URL blank until performing a Datacenter failover?
hi Paul
i really appreciate your articles ,it’s very detailed,helpful , organized ,thanks for your great explanation .
i just have some question regarding the ConfigureExchangeURLs.ps1 script
why you assign the externalclientauthenticationmethod parameter with the value of the variable $outlookanywhwre as long as the external method already had the same value as the variable $outlookanywhwre in configuring outlookanywhere
as long as we can configure url of autodiscover with the internal url variable in case we didn’t specify a value to the variable $AutodiscoverSCP what the need of dedicating a variable like $AutodiscoverSCP to configure the autodiscover or you use this variable in case you want to use a url name that differ from the internal url name
The Real Person!
The Real Person!
The -ExternalClientAuthenticationMethod parameter needs to be used when running Set-OutlookAnywhere to set URLs, so it’s included in the command and it just sets it to whatever the configuration setting is already set to (in other words, it doesn’t change the setting that is already in place).
The $AutodiscoverSCP parameter is optional. Some environments set a different Autodiscover URL, some don’t. That is a design decision for you to make.
thanks for you kind support
First can I say that having just done an Exchange 2010 to 2016 migration, your website is a mine of well presented and useful information.
I’m hoping that you might be able to help on a specific namespace issue we are having difficulty understanding. We have two Ex 2016 servers – (Bill and Ben for arguments sake). We have all our external URLs pointing at Ben and the internal ones pointing at themselves – so Bill on Bill and Ben on Ben.
Internally this works just fine – Outlook opens a raft to connections to Bill and/or Ben as it sees fit – there seems to be no pattern.
Externally however, despite the fact that all externals are pointing at Ben, Outlook running on a laptop outside the company still opens connections to Bill.
This is only an issue because we don’t want Bill to be visible on the internet and therefore the connections will fail.
Why does Outlook not just use the external addresses when on an external network?
The Real Person!
The Real Person!
If the connections to Bill (or Ben) by their real server name are possible externally, that suggests that they are publicly resolvable DNS names. If that’s the case, the client will connect to them, because it’s going to try the internal namespace first. If you don’t want internal namespaces being used externally, you should config DNS so that they are not externally resolvable.
Also, it’s not recommended to leave server names as internal URLs. You should still use an alias.
As a test we blocked access to Bill on the firewall and our external test machine running Outlook 2016 just hung – even after restart it didn’t try and access Ben at all.
Does it require that Bill is not resolvable externally to force it to try the alternate?
The Real Person!
The Real Person!
Yeah I don’t think just blocking at the firewall is the right way to go about fixing this.
Correct, as usual, making it un-resolvable forces Outlook to put all connections to Ben.
Not sure why Microsoft didn’t use the same logic when something is un-reachable, probably the same rationale as making an Outlook phone app that won’t allow you to update Contacts.
Cheers
The Real Person!
The Real Person!
The logic is fine. Internal names shouldn’t be externally resolvable. And there’s a difference between something being completely unresolvable vs being resolvable but not contactable (which could just be a transient issue).
Sorry, But why does that limitation exist? how come a L4 VIP cannot check more than 1 service?
Hey Paul
In you CAS – Load Balancer video on pluralsight, you say that a L4 loadbalanced VIP cannot check more than 1 CAS service using the healthcheck.htm check.
I understand how to work around it (multiple namespaces or use L7). But does that limitation exist? how come a L4 VIP cannot check more than 1 service?
Thanks,
Robert
The Real Person!
The Real Person!
It’s not a question of whether the load balancer can check multiple services or not for a L4 service (maybe some can, I don’t know, there’s a lot of load balancers out there).
Layer 4 means all the LB can see is the server IP and port that the client is requesting. It has no awareness of individual vdir that the client is requesting. So no matter what awareness the LB might have about individual service health, it can’t know what the client is requesting, so it can’t make accurate per-protocol/per-service decisions about where to send that client connection.
So in L4, you have the LB health check a single service, and if that service is down, treat the entire server as unhealthy, because you can’t tell whether the client is requesting that service or another one.
tl:dr – if you want per-protocol health awareness in your load balancing, use L7.
Hi Paul,
I have a test lab with 2 Exchange 2016’s EX01 & EX02 in DAG and RoundRobin DNS. My goal is to test a failover solution if fx. one of them is taken offline.
What is the best practise for setup if EX01 is offline and I want EX02 automatically to take over all functions until EX01 is back online??
Have searched the entire web, but no actual sites describes in detail what to setup other than Mailbox availability DAG.
Rgds
TT
The Real Person!
The Real Person!
The DAG provides the mailbox HA. Your client access namespace design and load balancing (or DNS RR) provides the client access HA. There’s also transport (mail flow) HA to consider, which you control through your inbound routes (MX records, NATing on firewall/edge router) and outbound routes (send connectors), as well as any internal SMTP relay (e.g. a receive connector that permits specific devices to relay mail).
Paul,
A great article, thank you for this. I have question about split-dns. I’ve setup autodiscover.companyname.com and mail.companyname.com on our Internal DC DNS to point to the Exchange 2016’s internal IP. Externally, the same names point to the external IP. InternalURL and ExternalURL’s are set to the same name on all services.
Our Exchange server is at our HQ and all our branch users have site to site VPNs to the HQ. If a VPN goes down then users will still be able to resolve the Exchange/Autodiscover names due to each site having a DC running DNS, however the internal IP of the Exchange server wont’ be available. Will clients Outlook somehow figure out to go externally (Like Outlook Anywhere is used by our field based staff)? If not, do I need to create different Internal and External URLs? I was just trying to get away from that is all since we can’t (Or can’t soon) have both Internal and External Domains on a SAN cert I believe and I didn’t want too many Certs to complicate things.
Hi Paul,
Great article and very helpful.
I am currently in the migration process from 2 Exchange 2010 servers to 4 Exchange 2016 servers in different sites. All Exchange servers are Internet facing.
I do not have any DAGs set up.
Should the namespaces for both internal and external be the same for all Exchange servers?
How do clients access their mailbox?
Thanks.
The Real Person!
The Real Person!
Not enough info to give advice for your situation, but generally speaking you can choose one namespace for all sites, or choose unique namespaces for each site. It’s up to you, and depends on many factors such as available bandwidth, whether you’re doing HA across the sites, and so on.
Hi Paul,
Thanks for the prompt response.
All sites but 1 has a 20/20 Fibre connections, the other 1 has a 50/50 Fibre connection.
At the moment there is no HA set up, but might set this up in the future if that will change how to configure it in the first place.
At the moment, we have migrated some users to the new Exchange 2016 servers do some testing, but are having issues with some accounts and not with others.
Some users Outlook profile setups are trying to point to the old Exchange 2010 server, however others work fine.
At the moment I have set all Exchange servers up with the same internal and external namespaces (mail.domain.com.au) and and set up internal DNS to point to the site with the 50/50 Fibre connection.
All users in the 50/50 site are fine but some users in the other sites are having issues.
Thanks.
The Real Person!
The Real Person!
There’s a few things that you need to consider for co-existence.
For Autodiscover, there should either be one Autodiscover namespace for all sites, and that DNS record should resolve to the 2016 server(s) only. Or, there should be one Autodiscover namespace per site, and the Autodiscover site scopes configured appropriately. In each site the AutoD namespace should resolve in DNS to the highest version of Exchange.
For other namespaces, check that your Outlook Anywhere namespace is not the same as the RPCClientAccessServer name for each of the 2010 databases (aka, the CAS Array namespace). If so, you’ve got an ambiguous namespace issue (search that term and you’ll find Microsoft’s blog post for what to do).
Also, if there’s 2010 public folders, the 2016 mailbox users will still connect to 2010 for PF access. If you’ve got Kerberos auth enabled, there’s additional config required for legacy PF access (again, Google for Microsoft’s guidance).
Aside from that, you’d need to be more specific about the issues you’re seeing.
Hey Paul,
Just a note. I was fighting with my external clients not being able to connect after enabling MAPI over HTTP while installing E2016 into my E2013 environment. My servers have Active Directory names ending in .local, while I’m using a .edu name for my internal and external URLs. For a couple hours, it appears my autodiscover was somehow still feeding my .local names to my clients. Then suddenly, as I was beginning to type up the question to you, I tried one more time and things started working. Is there some kind of update delay when changing these URLs before the clients actually see the changes?
I’m not actually at work right now to test it, but I’m hoping my internal clients will finally stop trying to use the .local names as well and stop giving my users those annoying certificate name mismatch errors.
The Real Person!
The Real Person!
The Autodiscover service caches some information for a few hours. You can recycle the Autodiscover app pool in IIS to have changes to namespaces and other configs take effect faster.
Hey Paul,
I have a company that has been renamed. They want to change their OWA link to represent the new company name. I understand how to change the internal and External URL’s and am using split DNS. They are currently using a Wildcard cert for all URLs. I have purchased a new mail.newcompanyname.com cert that I want to use for the OWA. My understanding is that in order to assign the new cert it needs to be assigned to the IIS services via ECP. In doing so it will change the cert for OWS, as well as ECP, active-sync and outlook anywhere.
My concerns are, if I assign the new cert the IIS services and change the URLs, will the Outlook clients pick up those changes automatically? And for any mobile devices, users will need to change their server settings to mail.newcompanyname.com in order to connect without a cert error.
Trying to minimize the end user impact as much as possible.
Thanks in advance!!
The Real Person!
The Real Person!
I think the best approach will be to generate a new certificate that has both the old and new names on it (a SAN or UCC certificate, depending on who you buy it from they might call it different things).
That way you can get the cert in place and deal with the transition without risking users connecting to the wrong name at the wrong time.
If the Internal URL and the External URL’s are exactly the same (i.e. because we implemented the split DNS approach) for:
OwaVirtualDirectory
EcpVirtualDirectory
ActiveSyncVirtualDirectory
WebServicesVirtualDirectory
OabVirtualDirectory
MapiVirtualDirectory
Is there actually any purpose for, or benefit to, setting both the ExternalURL and the InternalURL? What purpose does it serve? Are these not, in essence, setting different paths (URL’s) for IIS to recognize these various Exchange functions — so what benefit is there in having a second path (the ExternalURL) defined that has exactly the same value as the first (the InternalURL)?
I’ve read through all the questions & answers on this thread, and on some of the other threads, and can’t see where this question was asked or answered.
I’m in the process of setting up a like-for-like migration and so far I’ve only configured the internal URL for these settings on the new server (to use the commercial certificate via split DNS for internal access) and it seems to be working fine. Outside access is working, and no certificate errors from inside hosts.
Many thanks again for providing this site and service!
The Real Person!
The Real Person!
IIS doesn’t care what the URLs are.
The internal and external URLs are provided to clients via Autodiscover. The ability to have separate URLs means that all scenarios are catered for, whether the org needs them to be the same or different.
Paul, this article was exteremely helpful, especially since we have been chewing up three out of 4 names in our Digicert SAN.
Your config script generates an error for the External MAPI url assignment. It wants an authentication method. Any suggestion as to what to use: NTLM, oAuth, Negotiate?
Thanks >> Joe
The Real Person!
The Real Person!
I haven’t seen the error myself. Which build of Exchange are you running?
My MAPI vdirs have NTLM, Oauth, and Negotiate all enabled.
Hi Paul
I realized today that no available servers appear in the menu -> configure external access domain -> select the servers to use with the external URL and then click on + sign. No servers appear their
this is exch 2016 CU3
is it a bug?
The Real Person!
The Real Person!
It’s been broken for a while. But there’s better ways to configure the namespaces, that method is not worth using in my opinion.
Thanks for this. Thought I’d configured something wrong.
Hello
I found the reason. I just wrote a small article on this issue.
http://www.weeta.net/post/exchange-2016-cu3-configure-external-access-domain-server-list-empty
Rgds
Stéphane
Hi Paul,
When I run script ConfigureExchangeURLs.ps1 to config owa, ecp,..
When configuration step mapi script ask IISAuthenticationMethods[0]:
Which authentication values ?
Basic
Negotiate
NTLM
Thanks
The Real Person!
The Real Person!
Did you modify the script?
I run on exchange 2016 modify virtual directory owa, ecp,..
Thanks
I have the same issue come up when running on Exchange Server 2013 Service Pack 1 15.0.847.32.
Requests an authentication value same as Phuong above and Joe below “Your config script generates an error for the External MAPI url assignment. It wants an authentication method. Any suggestion as to what to use: NTLM, oAuth, Negotiate?”
Any suggestions?
The Real Person!
The Real Person!
Exchange 2013 SP1 is waaaaay out of date. Step 1, update to the latest build.
We have an existing Exchange 2013 environment with 2 Exch2013 servers having different internal and external namespaces.
I am currently deploying a third and fourth Exchange 2016 servers and would like to standardise namespaces to match, both internal and external for all servers.
Eventually all Exch 2013 mailboxes will be moved onto the Exch 2016 servers with a DAG.
If I change all existing servers to have the internal and external namespaces matching, what will be the impact on existing connections from Outlook clients? And what can I do to mitigate any issues?
Many Thanks and keep up the good work! Bought the Exch Server 2016 Quick start guide which I’m finding really helpful.
Hi Paul,
This is invaluable and thank you! One question – aside from the difficulty configuring/troubleshooting – is there any other reason to NOT use separate internalURL and externalURL
Our company policy is to not use internal namespaces externally so we were planning to setup like,
InternalURL : mail.contoso.com
ExternalURL: mail.contosogroup.com
The Real Person!
The Real Person!
The most common reason is if you want different internal and external authentication methods to be used.
If you have a company policy to comply with that’s fine. I’d suggest it’s probably just as simple in your case to use the external URL for both, but if the internal URL is what people are used to using for OWA access internally then stick with that.
Keep in mind that both names will need to be on the SSL certificate anyway, so it’s not like you’ll be completely hiding your internal namespace from the world.
i need it with basic authentication not NTLM
could you let me know where i can find it
Hi Paul,
I installed the Exchange 2016 in an existing Exchange 2010 environment with split DNS, when I update the webmail.domain.com and autodiscover to point to Exchange 2016 server, mailbox on 2010 took 2 to 3 minutes to startup.
Regard.
TLN
I’m unable to get the GetExchangeURLs script to run properly. Do I need to have some Java Script engine installed on the server?
Below is the Red errors that show when trying to run it.
At C:tempGetExchangeURLs.ps1:119 char:13
+ <a href="/open-source" class="js-selected-navigation-item nav-item n …
+ ~
The '<' operator is reserved for future use.
At C:tempGetExchangeURLs.ps1:121 char:13
+ <a href="/business" class="js-selected-navigation-item nav-item nav- …
+ ~
The '<' operator is reserved for future use.
At C:tempGetExchangeURLs.ps1:123 char:13
+ <a href="/explore" class="js-selected-navigation-item nav-item nav-i …
+ ~
The '<' operator is reserved for future use.
At C:tempGetExchangeURLs.ps1:125 char:11
+
+ ~
The ‘<' operator is reserved for future use.
At C:tempGetExchangeURLs.ps1:138 char:8
+ <!– –><form accept-charset="UTF-8" action="/cunningh …
+ ~
The '
+ ~
The ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an ampersand in double
quotation marks (“&”) to pass it as part of a string.
At C:tempGetExchangeURLs.ps1:1065 char:11
+ © 2016 <span title="0.04655s from github-fe165-cp1-prd.iad.github …
+ ~
The ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an ampersand in double
quotation marks ("&") to pass it as part of a string.
At C:tempGetExchangeURLs.ps1:1065 char:23
+ © 2016 <span title="0.04655s from github-fe165-cp1-prd.iad.github …
+ ~
The '<' operator is reserved for future use.
At C:tempGetExchangeURLs.ps1:1065 char:29
+ © 2016 GitHub’ in expression or statement.
At C:tempGetExchangeURLs.ps1:1065 char:100
+ … “>GitHub, Inc.
+ ~
Missing argument in parameter list.
Not all parse errors were reported. Correct the reported errors and try again.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : RedirectionNotSupported
The Real Person!
The Real Person!
You’ve downloaded a bunch of HTML from Github instead of just the PowerShell code.
Of Course! Thanks for the DUH! moment of the day.
The Pluralsight course is great by the way!
The Real Person!
The Real Person!
Thanks, I appreciate the feedback.
Hello Paul,
great series you have provided. Many thanks for that.
You may want to update your cmdlets, as Exchange 2016 CU1 has recommended to use “Get-ClientAccessService” and “Set-ClientAccessService” instead of “Get-ClientAccessServer” / “Set-ClientAccessServer”. Cmdlets are marked to be removed in future releases.
Regards
SK
Hi paul,
thanks for your Quick response.
just one more singal question about changing the internal URL on the exchange 2010 Server.
can i use this your script to Change only the internal URL and if i change the Internal URL for the running system , how is going to affect the running enviroment?
will there be any Security warning or Connection time out error ?
https://github.com/cunninghamp/ConfigureExchangeURLs.ps1
thanks
The Real Person!
The Real Person!
The script is a basic tool for setting URLs on new servers that are being deployed. In your situation, you’re changing an existing server in production, so there’s more at stake.
I would suggest that you first document all of your client access URLs, internal and external. Then, create two scripts of your own. The first is going to make the changes to your server configuration. The second is to revert the changes to their original settings. The scripts don’t need to be fancy, it’s just a set of PowerShell commands. But that gives you a rollback method if something goes wrong. Next, double check that your SSL cert includes the name you’re about to change the internal URLs to (just to be sure).
When you’re ready to make the change, run the first script, then check the results. Recycle the Autodiscover app pool in IIS, and test with your clients. If there’s any issues, you can run the second script to roll back (and recycle the app pool again). Do all this at a low impact time for your customers, and all should be fine.
Hi Paul,
Thank you, I am going to make the scripts with the Power shell Command. I think i dont need to make any Changes to the External URl, because the External One is running as it should be. I think , only Thing i need to change is Internal Url.
my internal URL looks like this.
https://svv-ex2010.domain.com/owa
https://svv-ex2010.domain.com/ecp
https://svv-ex2010.domain.com/OAB
https://svv-ex2010.domain.com/Micorsoft-Server-ActiveSync
https://svv-ex2010.domain.com/Autodiscover/Autodiscover.xml
and I have problem Understanding the SSL Certificate topic.
We are having the Internal AD CS Certificate authority and private CA Certificate is being used for Internal Clients but i just checked it , this was assigned to the Exchange server itself.
and my target to have Internal name spaces as follow:
https://mail.domain.com/owa
https://mail.domain.com/ecp
https://mail.domain.com/OAB
https://mail.domain.com/Micorsoft-Server-ActiveSync
https://mail.domain.com/Autodiscover/Autodiscover.xml
and here MAIL is only the DNS Host entry which is bound with the Same IP as Exchange CAS server IP.
I am confused here a bit and i am about to make the changes to Prodution system so trying to make all doubts clears.
thank you for you Help.
Hi paul,
I have bought your Migration book for exchange server 2010 to exchange 2013 and planning to make the migration according it.
I have a question about the Namespaces. currently we have exchange 2010 Servers.
1: cas server
2: mailbox and hub transport server.
and the external name space is mail.domin.com and internal namespace is https://svv-ex2010.domain.com.
so before i start the migration i do need to change the Internal name space and make standard internal namespace.
and then i have to start the migration of it.?
thanks
The Real Person!
The Real Person!
Yes, my normal approach is to fix up the internal namespace first, before trying to migrate. It makes things easier, in my experience.
Hi Paul,
I have Exchange 2013 MB & CAS server with same URL for both internal and external.
I am adding Exchange 2016 [DAG configuration] to existing environment to be able to migrate the mailboxes from Exchange 2013 to Exchange 2016.
I will install the new Exchange 2016 on 2 servers.
Create the DAG
Create the Exchange 2016 server round robin DNS [internal DNS]
Install the external SSL certificate.
Update the virtual directories with the external and internal URL.
Start the mailbox move
Is this the right approach without causing any issues to the existing 2013 environment.
Thank You in advance and we multiple Exchange 2016 articles.
Raed
Hope you can and will answer my question.
– Is it wise to keep internal & external authentication on VDIR the same and what is most common configuration (keep the same)?
And if we have a KEMP or TMG or F5 reverse proxy for external users and we just NLB the CAS servers internally , should we keep internal & external authentication the same?
How would this work if you have several AD sites in a single forest and a distributed Exchange deployment with a 2016 server in each site? One server is internet facing, the rest are just internal.
To clarify internet facing, it’s not an Edge server, just a regular mailbox server.
The Real Person!
The Real Person!
If you have only one internet facing site, then you can configure external URLs for that site, and leave the external URLs blank for the other sites.
Thanks!
Hi Paul,
By using a unique namespace for autodiscover (https://demoex16.exchange2016demo.com/Autodiscover/Autodiscover.xml) what DNS records are required for external users ?
Because, If I’m not wrong, Outlook will try :
1) “autodiscover” + “user smtp domain name” which is https://autodiscover.exchange2016demo.com/Autodiscover/Autodiscover.xml.
= Fail
2) http redirect method with http://autodiscover.exchange2016demo.com/autodiscover/autodiscover.xml
= Fail
Thanks
Hello, GetExchangeURLs.ps1 doesn’t run on our Exchange 2010 Server. We receive the following error in the Management Shell:
[PS] D:Tools>.GetExchangeURLs.ps1 -server rzsrv21
< : Der Operator "<" wird noch nicht unterstützt.
+ CategoryInfo : ParserError: (<:OperatorToken) [], ParseException
+ FullyQualifiedErrorId : RedirectionNotSupported
Any idea, Thanks
The Real Person!
The Real Person!
You haven’t copied/downloaded the PowerShell script correctly from Github.
Yes, from site https://github.com/cunninghamp/ConfigureExchangeURLs.ps1
The Real Person!
The Real Person!
Yes. So if you’re just right-clicking on the script and doing a “Save as” or similar with you browser, what gets downloaded is a whole bunch of HTML and not just the PowerShell code. Click on the “Download Zip” button instead.
Donwload Zip works fine, script runs, Thanks
The following article recommends using different internal and external URLs because of using Kerberos authentication internally and Outlook preferring the internal settings when both URLs are the same: https://blogs.technet.microsoft.com/exchange/2015/10/26/client-connectivity-in-an-exchange-2016-coexistence-environment-with-exchange-2010
Maybe it would be a good idea to update your article to include these recommendations.
Regards,
Han.
Of course only for RPC/HTTP and MAPI/HTTP.
Hey,
As you know exchange 2010 use rpc cliient access array, and exchange 2013/2016 use https,
how the name mail.abc.com of client access of 2013/2016 will communicate with that rpc client access array name of mail.abc.com during migration if we wantto use the same name/ssl cert ?
kindly clarify.
Hi Paul
I have set the internal and external URLs to be the same, however all Outlook internal user traffic is going out to the internet to retrieve there email.
Paul,
Thanks very much for the article, it was very thorough and helpful. This is our first install of Exchange 2016 and I have a few bridges not yet crossed.
Our previous Exchange 2013 environment was a split DNS .local implementation and it had a few pain points when it comes to internal/external DNS resolution. I’ve seen an abundance of documentation suggest abandoning the .local naming convention for AD namespaces and using a subdomain of the .com – or in our case, ad.domain.com.
What are the internal/external DNS implications of this setup? Our domain host is resolving mail.domain.com to our public IP. Our firewall forwards traffic on that IP to the private IP of our Exchange server, which has a FQDN of EXCH.ad.domain.com. Does that create any issues with internal DNS resolution or with certificate naming? I have a UC Certificate with 3 SAN’s but I haven’t researched which SAN’s we’ll need in this go around.
Any advice to get us off on the right foot?
Thank you for the post !!!
I have 2 mail box servers load balanced by KEMP.The internal and external url s are same. Now I am planning to deploy 1 edge transport server, so what all changes I need to take care for internal and external DNS?
Currently external DNS have A record mail.xyz.com which will NAT to my KEMP, also MX associated with it.
I can’t find the name space design for an environment with Edge transport server. It will be helpful if u can guide me on the name space, DNS and certificate requirement s for an environment with Edge server also.
The Real Person!
The Real Person!
Edge transport and client access namespaces are two different things. There’s lots of guidance available for setting up Edge Transport if you search on Google or TechNet. If you want to use mail.xyz.com for your MX record, and that currently NATs to your Kemp, then you just need to have Kemp send the SMTP traffic to your Edge Transport server.
Thanks for the reply Paul. I applied certificate and services with same name on passive server. During the process I realized that IMAP was the only service that did not have common FQDN, therefore, I did not change in on passive either.
The only issue I noticed was Outlook 2011 for MAC was unable to connect after the above change. Therefore, I have shut passive server down to restore client connection for Outlook 2011 for MAC
If I am using same name to services on active server to passive server. Do I need to export SSL certificate from active server and apply imported certificate to imap, pop, audiscover etc? Or it is not required after I changed connection point to mail.domain.com as defined on active server and certificate will automatically recognize it.
Also, I would like to included a question about the another forum about DNS round robin of CAS service on two exchange with all roles –
Do I also need round robin in internal DNS zone for mail.domain.com along with external round robin
The Real Person!
The Real Person!
Yes, you should use the same SSL certificate on all servers that are configured with the same namespaces.
DNS round robin, or any load balancing for that matter, is not mandatory. You should use DNS round robin or load balancing wherever you want high availability. So if you want high availability for your internal network clients connecting to Exchange, then yes you should use DNS RR or load balancing.
Hi,
Thanks for this article. We want to use separate urls for services OWA and ECP. We want to do that because we want to go trough a Kemp reverse Proxy (in DMZ) and have Internet users and Internal users have the same OWA/ECP experience (use same forms based logon page)
Would it be possible to configure internal DNS to point owa and ecp to the Kemp reverse proxy and the other services to the Exchange Server directly?
Configure Internal DNS and Exchange Internal URLS:
owa.company.com -> Kemp in DMZ
ecp.company.com -> Kemp in DMZ
mail.company.com -> Exchange server directly for all other services like rpc, autodiscover and ews.
Configure External DNS and Exchange External URLS:
mail.company.com -> NAT’ed internet IP to Kemp in DMZ.
Question: Do you know if that setup will work ok? Or recommend something else?
Thanks.
The Real Person!
The Real Person!
You can use separate URLs for each service, and on each service you can also use separate internal and external URLs. So there is complete flexibility when it comes to how you want to design your namespaces.
However, everything you do that adds complexity will make your configuration harder to implement, manage, and troubleshoot.
Hey Paul,
Great article! I have used it as a reference twice when setting up Exchange environment.
My question is related to certificate warnings when I am attempting to configure Outlook 2013 to connect to my Exchange mailbox.
I have Split-DNS configured and have used the script ConfigureExchangeURLs to set internal and external URLs to the same name (e.g. mail.company.com).
When setting up Outlook account, the certificate warning shows (servername.company.local).
What am I missing? Is there an AD setting that determines where the autoconfiguration of Outlook should look to find the Exchange Server name?
Keep doing what you do!
Wes
Got it.
Set-ClientAccessService did the trick.
In the article you show using GetExchangeURLs.ps1 to pull the current server info. The link points to ConfigureExchangeURLs.ps1. I do not see the GetExchangeURLs.ps1 on your github. These scripts should help clean up our current problems.
The Real Person!
The Real Person!
It’s definitely there in the repo.
Yes I found it, thank you for the articles. The information has been a great help.
Thank you Paul for the post.
If my Internal and external namespaces are not the same as your example, What is the Best practice for the Client Access Namespace Configuration ? For instance, suppose that I have demo.local as my internal domain name and company.com as external namespace and I have 3 exchange servers in DAG: exch01.demo.local, exch02.demo.local and exch03.demo.local
I assume I can have for Internal url https://mail.demo.local/owa or ecp or oab ect… and for External url https://mail.company.com/owa or ecp or oab ect.. What do you say about it ?
The Real Person!
The Real Person!
Your internal Exchange URLs don’t need to match the AD namespace. They can be whatever you want them to be.
The recommended practice is to use the same internal and external namespace, with split DNS.
I don’t recommend trying to use any .local or other domain that you don’t own, because it is going to complicate things with your SSL certificates.
Dear Paul,
I am facing the same issue with the above post.
I have a domain “x.com” that was deployed in the past, and the external domain is x.com.lb.
I am facing issues with the internal users as the Outlook is asking for credentials every time the user opens it. if I remove the outlook profile and recreate it it works for the first time, then when i close outlook and then reopen it, it asks for credentials again, and providing the credentials doesn’t work.
I have Exchange 2016 MBX role, and have configured split DNS.
Please advise.
The Real Person!
The Real Person!
What else have you checked?
Hi,
simply create new forward lookup zone in your DNS named mail.company.com and create an empty A record, pointing to IP address of exchange.
Works for me also with round robin ?
Hi,
simply create new forward lookup zone in your DNS named mail.company.com and create an empty A record, pointing to IP address of exchange.
Works for me also with round robin 🙂
Paul, you are simply THE MAN! I’ve been using your articles for years. Whenever I’m googling around for an Exchange solution, I always append exchangeserverpro to the search term. Thanks for everything you do!
DAG 2016 provides failover of client connections?
The Real Person!
The Real Person!
You need to load balance the client access namespaces. You can do that by using DNS round robin, or by using a load balancer such as a Kemp or F5 appliance.
Hello Paul,
We have a unique requirement where we do have same internal and external URLs however we want to block a certain set of users from accessing from internet, however at the same time allow others.
If I used Set-CASMailbox UserEmailAddress -MAPIBlockOutlookRpcHttp $true I am unable to connect even within the org.
The above command per my understanding and discussions with Microsoft should only block connections coming from internet however, it blocks from internal as well and outlook client gets disconnected even when on LAN. Is there any way to achieve what I am trying to? We are using UAG to publish Outlook Anywhere however we cannot join UAG to our internal Production domain because of some company policies.
Regards,
Alpesh
The Real Person!
The Real Person!
All Outlook connectivity to Exchange 2013 and 2016 is RPC over HTTP (Outlook Anywhere), unless you’ve also deployed MAPI over HTTP. But either way, there’s no distinction between internal and external protocols now, it’s the same protocol being used for both.
So in your case, you’ll need to work out a way to pre-authenticate users coming in externally and allow/block before they reach Exchange.
It appears there is a way to block external only, from https://technet.microsoft.com/en-us/library/mt634322(v=exchg.160).aspx
I’m still not exactly sure how it determines if you’re ‘Internal’ or ‘External’ since in many organizations (including ours) the URLs are the same for both of them.
Hi Paul,
why not add a control that allows the script to configure the autodiscover scp as autodiscover.domain.com (if specified as parameter) instead of sharing the URL with all the others virtual directories?
Already edited the script 😉
Bye,
GM
The Real Person!
The Real Person!
Why make it different to the other namespaces?
Hi,
usually, I (and, AFAIK, most Exchange admins) use an autodiscover.domain.something record in DNS to point to the autodiscover service, and I (don’t know if anyone else is doing the same thing) configured the autodiscover SCP to that same DNS value (https://autodiscover.domain.something/Autodiscover/Autodiscover.xml).
This allows me to preserve a logic by matching SCP/Virtual Directory with DNS record name.
Given your reply, I’m beginning to doubt my standards… was I doing something wrong?
Thanks.
GM
The Real Person!
The Real Person!
I prefer fewer namespaces to manage, but it’s your decision.
Thank you for share this excellent scripts with us.
Hi Paul,
Thanks for providing this script 🙂
Maybe an idea to also add IMAP and POP3 although not always used?