DP230
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!
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
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.
ASKER
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.
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
https://support.microsoft.com/en-us/help/2480582/how-to-suppress-the-autodiscover-redirect-warning-in-outlook-2010-and
ASKER
ASKER
We also tried this link but it did not help:https://support.microsoft.com/en-us/help/2480582/how-to-suppress-the-autodiscover-redirect-warning-in-outlook-2010-and
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 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.
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
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.co m), 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 -AutodiscoverServiceIntern alUri (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.loca l and potentially an SRV record that points _autodiscover._tcp.domain# .com > exchangeserver.domain.loca l.
- 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 -AutodiscoverInternalServi ceUri $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.
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.co
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 -AutodiscoverServiceIntern
- 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.loca
- 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 -AutodiscoverInternalServi
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.
ASKER
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.