Link to home
Start Free TrialLog in
Avatar of DP230
DP230Flag for United Kingdom of Great Britain and Northern Ireland

asked on

Change Exchange domain name

Dear Experts, we are having 1 Exchange Mail server and 1 AD server with domain: oldone.com, with about 1000 users and 10 TB of mail data

Now we'd like to change the domain to: newone.com, and remain the same users' data

Is it possible? If so, how can we do it?

Many thanks!
ASKER CERTIFIED SOLUTION
Avatar of Aaron Guilmette
Aaron Guilmette
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of DP230

ASKER

Hi Arron, yes i knew and already did it.

But as you may know, the SSL issue in MS Outlook appeared after configured Accepted domain: newone.com

So our users have 2 SMTP addresses: newone.com and oldone.com, both can receive mails but outside can only see us as newone.com

The problem is if we can NOT purchase the multiple-domain wildcard SSL cert, what should we do to fix the SSL issue? We'd like to change the domain to newone.com completely.
So, the problem you're actually facing is an Autodiscover problem.  Outlook clients will perform autodiscover using the SMTP suffix of the user's email address.  If you change UserA's primary SMTP address from UserA@oldone.com to UserA@newone.com, the next time Outlook starts, it will attempt to look up a server name for autodiscover.newone.com.  If you don't have a matching cert and still have an SCP record in AD, you'll get a cert warning.

The best solution will be to request a certificate to say:

autodiscover.oldone.com
autodiscover.newone.com

And whatever other names you had on there.  For domain-joined machines, you could also configure an SRV record for _autodiscover._tcp.newone.com.  SRV records bypass cert errors.

https://blogs.technet.microsoft.com/rmilne/2014/10/02/how-to-check-exchange-autodiscover-srv-record-using-nslookup/ gives an example of configuring an autodiscover SRV record.  Queries outside your domain will still result in cert errors unless you configure external SRV records as well.

The overall best answer is to make sure your cert name holds an autodiscover record for all of the domains you answer for.
Avatar of DP230

ASKER

User generated image
Yes you are right, we already configured the SRV in internal DNS (AD server) but did not know how to configure it in public DNS. Can you help?

" For domain-joined machines, you could also configure an SRV record for _autodiscover._tcp.newone.com.  SRV records bypass cert error"

But our DNS server also is AD server of the oldone.com; and I don't think we can configure the SRV of newone.com here
That doesn't matter.  You need to create a new AD DNS zone for newone.com.  You'll be adding _autodiscover._tcp to the new zone.  You'll keep the existing STV record for _autodiscover._tcp.oldone.com, since it's for the old domain.
You may also want to look at suppressing the autodiscover warning messages, if the STV record or new very don't solve it.  This is how to do it for a single user; you can also deploy the settings via Group Policy Preferences.  

https://support.microsoft.com/en-us/help/2480582/how-to-suppress-the-autodiscover-redirect-warning-in-outlook-2010-and
Avatar of DP230

ASKER

Hi, but how can I teach my Server to use the SRV record of newone.com when it is using DNS of oldone.com?

As my understanding, are you suggesting us to new AD DNS zone for newone.com in the same DNS server with oldone.com? If so, which type of zone should we choose?

User generated image
Yes, that's correct for the zone.

The DNS record isn't "teaching the server."  It's so the server returns a valid response to the client.

Your Outlook clients are trying to find the answer to a lookup, "where do I go for newone.com?"  Your environment responds, "here, try oldone.com."

You need to give your environment a way to answer, "here, try this for newone.com."

I went through this process for about 200,000 mailboxes for 60 agencies at a state government last year. ;)
The redirect warning pop up sometimes happens when your autodiscover redirect happens from http to https. It probably won't fix this issue by itself, but it's useful if you certain other environmental variables.  I typically recommend it when you don't have a cert that matches the SMTP domains.
Avatar of DP230

ASKER

Wow, 200000 mailboxes were a huge number :) but it did not work for me.

Which environment variable do I need to modify? I tried to import a cert of newone.com into oldone.com Exchange server, then assign SMTP service to that new cert, but it did not work
You still probably should configure a DNS zone for newone.com, and configure an A record for autodiscover.newone.com to point to your Exchange server.

You probably should review how to configure Autodiscover: https://technet.microsoft.com/en-us/library/mt441779(v=exchg.150).aspx

In general:

- You should have a certificate applied to your Exchange server.  The certificate should have, at a minimum, a CN or SAN name entry for autodiscover for every domain that you have configured as a primary SMTP suffix.  If you have 500 domains (domain1.com..domain500.com), but only domain1.com and domain5.com are used as primary SMTP address domains for your users, your certificate should have:

autodiscover.domain1.com
autodiscover.domain5.com

- The default lookup order for Autodiscover depends on your version of Outlook (you can read more at Rhoderick's blog: https://blogs.technet.microsoft.com/rmilne/2015/04/29/office-365-autodiscover-lookup-process/ as well as the older Exchange 2010 whitepaper on how autodiscover works: https://blogs.technet.microsoft.com/rmilne/2015/04/29/office-365-autodiscover-lookup-process/):

•SCP lookup
•HTTPS root domain query
•HTTPS Autodiscover domain query
•Local XML file
•HTTP redirect method
•SRV record query
•Cached URL in the Outlook profile (new for Outlook 2010 version 14.0.7140.5001 and later versions)
•Direct Connect to Office 365 (new for Outlook 2016 version 16.0.6741.2017 and later versions)

- SCP is configured by using Set-ClientAccessServer -AutodiscoverServiceInternalUri (https://docs.microsoft.com/en-us/powershell/module/exchange/client-access-servers/Set-ClientAccessServer?view=exchange-ps).

- Along with the certificate having the right names on it, you also need DNS zones to answer for those names.  If you have domain1.com and domain5.com being used as primary SMTP address suffixes for your users, *no matter what your Active Directory FQDN is,* you need DNS records for domain1.com and domain5.com.  If your AD domain is domain.local, your AD DNS server will have 3 primary DNS zones configured: domain.local (which contains all of your servers and workstations that automatically register), and then domain1.com and domain5.com, which have been configured potentially with an A or CNAME record to autodiscover.domain#.com > exchangeserver.domain.local and potentially an SRV record that points _autodiscover._tcp.domain#.com > exchangeserver.domain.local.

- You can control which methods get queried for Autodiscover by Outlook by modifying a series of registry keys (either individually or via Group Policy Objects / Group Policy Preferences): https://support.microsoft.com/en-us/help/2612922/how-to-control-outlook-autodiscover-by-using-group-policy

- If you use a SRV record for autodiscover location, most cert errors will be ignored (such as if you had a certificate for domain1.com and your Outlook clients are attempting to autoconfigure for user@domain5.com), but in order for you to use the SRV record lookup method, you need to disable SCP lookup (either by disabling SCP in your forest via Set-ClientAccessServer -AutodiscoverInternalServiceUri $null or by disabling SCP via registry/group policy on workstations).

Before making changes to your environment, I would recommend going through all of the reading on how the server-side configurations for Autodiscover work (autodiscover internal and external URLs, SCP, SRV lookup, HTTPS redirect method) as well as how Outlook clients process autodiscover.