One of the risks during Exchange Server 2013 deployment is that the installation of a new Client Access server may cause certificate warnings to begin appearing in the Outlook client of your end users.
This is similar to the certificate warning issue often seen during Exchange Server 2010 installation, which was caused by the Outlook client making Autodiscover or Exchange Web Services connections to an Exchange server with a self-signed (ie, untrusted by the client) SSL certificate.
If there is going to be a delay in SSL certificate provisioning for the new Exchange 2013 servers (which is common when third party certification authorities are used) then steps should be taken to mitigate this risk.
This issue can be avoided with a little bit of planning before you deploy the first server. Let’s take a look at the existing Exchange Server Pro organization.
First, a quick review of existing Autodiscover configurations should be performed.
From the information gathering stage where we ran the Get-VirDirInfo.ps1 script we already know that the following Autodiscover URLs are configure:
- autodiscover.exchangeserverpro.net
- br-ex2010-mb.exchangeserverpro.net
Another view of this information can be seen by running Get-ClientAccessServer.
[PS] C:\>Get-ClientAccessServer | Select Name,AutodiscoverServiceInternalURI,AutodiscoverSiteScope | Fl
Name : BR-EX2010-MB
AutoDiscoverServiceInternalUri : https://br-ex2010-mb.exchangeserverpro.net/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope : {BranchOffice}
Name : HO-EX2010-MB1
AutoDiscoverServiceInternalUri : https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope : {HeadOffice}
Name : HO-EX2010-MB2
AutoDiscoverServiceInternalUri : https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope : {HeadOffice}
Notice the AutoDiscoverSiteScope value above. This is also referred to as “Site Affinity” and is used to tell Outlook clients which Client Access servers to prefer when they are looking for an Autodiscover service to connect to. For more on configuring site scope refer to this article:
In a migration scenario where new servers are being introduced to the organization, the site scope can be used to avoid having Outlook clients connecting to your new servers for Autodiscover. If you have not configured site scope it is recommended to do so before installing the first Exchange 2013 server.
However, this solution requires that the new Exchange 2013 servers are being deployed in an Active Directory site that is different to the existing site(s). In our Exchange Server Pro deployment scenario this is true; the new servers are being deployed into new datacenters that have different IP subnets and different Active Directory sites configured.
If you are not deploying into a new site you can still use this method by establishing a temporary AD site where Exchange 2013 is provisioned, then move it into your production AD site when it is ready to go live.
If neither of the above options is available to you then you can use DNS to avoid the issue instead. For example, if a single site exists and the Autodiscover namespace is autodiscover.exchangeserverpro.net, then as long as the Exchange 2013 server is also configured with that Autodiscover namespace, you can use DNS to only resolve that name to your existing Exchange servers only, or resolve to a load balanced VIP that distributes the traffic only to those Exchange 2010 servers.
To achieve this you would need to configure the Autodiscover URL on the Exchange 2013 server immediately after it is installed. You can see a demonstration of this in the following article:
To summarize, the primary objectives here are to use Autodiscover namespace and site scope configurations to prevent Outlook clients from connecting to an Exchange 2013 server that has not been full provisioned, to avoid SSL warning dialogs appearing, and also to optimize the Autodiscover configuration in larger environments.
In the next article in this series we’ll look at reviewing the offline address book configuration for the existing Exchange 2010 environment.
Hey Paul,
Thanks for the great post!
We have 3 exchange servers 2010 in our environment. We recently installed 2 exchange server 2016.
We want to run 2016 in coexistence with 2010.
All the 3 exchange 2010 servers have different autodiscover names, xcg12010.domain.com, xcg22010.domain.com and xcg32010.domain.com
I am a bit confused about the autodiscover names for my xcg12016 and xcg22016 servers
Can you please share your thoughts on this.
Thanks.
The Exchange 2010 servers should not have different Autodiscover SCP URLs, they should all be configured with the same Autodiscover SCP URLs. The Exchange 2016 servers, if they are installed in the same site as the 2010 servers, should also use the same Autodiscover SCP URL.
If we update the SCP of our current exchange servers to have the same Autodiscover SCP URLs (autodiscover.domain.com), what would be the impact on the users?
If a user’s outlook is using xcg12010.domain.com to connect to the exchange server, on updating the SCP (autodiscover.domain.com), will the user have to manually update to the new SCP or restarting outlook should do it automatically?
Thanks.
As long as there is a DNS record for the Autodiscover name, and the Autodiscover name is also on the SSL certificate that the Exchange servers are configured to use, there will be no impact. It will take a few hours for all of the Outlook clients to start using the new Autodiscover SCP, but there is no manual steps required.
But that’s just the Autodiscover name. If you’ve got different Outlook Anywhere, OWA, ActiveSync, etc URLs for the different servers as well, then that namespace configuration would also need to be fixed up.
Hi Paul,
We have updated all the URLs on our old exchange 2010 servers and configured the exchange 2016 servers with the same URLs. Now, Exchange 2016 acts as a proxy for 2010.
We migrated few mailboxes to 2016 for testing. We are experiencing issues with employees whose mailbox is on Exchange 2016 and are using outlook 2010. It takes too long to connect to the exchange server and freezes at times.
On checking the connection status, we see it is trying to connect to the exchange 2010 server-
server name: old URL name of exchange 2010 server
protocol: RPC/TCP
status: connecting
type: public folder
We checked the public folder, it is empty.
This issue is only with outlook 2010. Outlook 2013 and 2016 works fine.
Is this because of incompatibility of outlook 2010 with exchange 2016 or we are missing some configuration?
Can you please share your thoughts on this.
Thanks.
Ankit, make sure your Outlook 2010 clients are fully patched.
If you aren’t using public folders in the org, consider decommissioning them entirely.
If you have Kerberos auth enabled, refer to this article:
https://blogs.technet.microsoft.com/exchange/2015/02/20/exchange-2013-and-exchange-2010-coexistence-with-kerberos-authentication/
(My apologies. I originally posted this on the wrong page)
Paul,
I purchased your guide and have read this section over and over but I’m still confused. Here’s my scenario:
Single Exchange 2010 server with autodiscover as https://exchange2010server.domain.com/Autodiscover/Autodiscover.xml.
I want to make the new uri: https://autodiscover.domain.com/Autodiscover/Autodiscover.xml, as I don’t want to include that “exchange2010server” name in the new 2013 cert. The name autodiscover.domain.com is already a part of the existing cert as well.
Since the new 2013 servers are in the same data center, should I still follow your advice: “This means that using the same Autodiscover SCP URL for the new servers, so it matches the Autodiscover SCP URL of the existing servers, is the best approach.”
I’m considered changing the 2010 uri to match what we will be using for the new uri, but I’m not sure how Outlook clients will react to that.
Thanks in advance for your help.
Short answer, yes you should change the AutoD URI on 2010 to an alias before deploying the new server. Clients will handle the change fine as long as the name is on the SSL certificate.
Paul,
Thanks for posting this. I’m working on an upgrade from 2007 to 2013 and ran into some autodiscover issues right away. I didn’t install into a dedicated site, but to one of my internet facing sites. I hadn’t changed the autodiscover back to the original dns name and started seeing some authentication issues with Outlook Anywhere. I haven’t seen this documented anywhere, so I wanted to thank you for your insight on it.
Thanks again.
Adam
Hi Paul,
Thanks for your posts, very helpful.
I’m running a 2010/2013 coexistance. We haven’t switched mail.domain.com to point to 2013 internally or externally. Currently, mail2.domain.com is pointing to 2013.
All Virtual directories are mail.worldwinner.com for 2010
mail2.worldwinner.com for 2010
When do I change the VD URLS to point to 2013? Before or after I change DNS? When that happens do I leave the URLs to be the same on 2010 and 2013?
For autodiscover it’s currently setup like this:
2010
autodiscoverinternaluri: https://CAShostname.domain.com/Autodiscover/Autodiscover.xml
Autodiscover-Site-Scope: {Default-First-Site}
2013
autodiscoverinternaluri: https://CAShostname.domain.com/Autodiscover/Autodiscover.xml
Autodiscover-Site-Scope: {Default-First-Site}
I think what I need to do is change external and internal DNS to point autodiscover.domain.com to the 2013 CAS and change the internaluri to “https://autodiscover.domain.com/…/Autodiscover.xml” is that correct? Do I make that the internaluri for 2010 and 2013?
There is no load balancer. I didn’t have to option to create a temp domain to test 2013. Should I configure the autodiscover-site-scope?
I already moved some test mailboxes and they’re working properly but I think the 2010 CAS is proxying for the 2013 and I need it the other way around.
I appreciate the help.
-Nick
Pingback: Exchange 2013 coexistence environment and Outlook infrastructure | Part 2/2 - o365info.com
Pingback: Exchange 2013 coexistence environment | Autodiscover infrastructure | Part 2/2 - o365info.com
Hi Paul,
Thanks for the great write up, although some parts are not real clear to me. Especially the “If neither of the above options is available to you then you can use DNS to avoid the issue instead” part. I am not sure on how to set this up. Furthermore I am also confused about when do you move over to use the autodiscover of exchange 2013?
We are in the middle of a migration from Exchange 2010 to Exchange 2013, until now it has been a real pain in the *ss. Ever since we enable outlook anywhere on Exchange 2010 and Exchange 2013, al kinds of certificate errors started to occur, despite the fact that all URL settings are pointing to external domain names in combination with a wild card certificate. For some reason some clients, especially those still on Exchange 2010 mailbox server, still try to connect to the local domain name of the server instead of the external domain name.
But regarding the autodiscover part. If I am interpreting this specific article correctly, exchange 2010 user need to use the exchange 2010 autodiscover and exchange 2013 users need to use the exchange 2013 autodiscover. How can this be arranged on a per user basis? We are facing the problem that the 7 users that already have been moved to Exchange 2013 can’t use the Exchange 2010 CAS to connect to Exchange 2013 (which makes sense to me). And the other way around it doesn’t work either, Exchange 2010 users connecting through the Exchange 2013 CAS are unable to connect to their Exchange 2010 mailbox neither use the autodiscover of Exchange 2013.
I have been troubleshooting this for 4 days straight, without any promising progress. I am pretty lost on where to look next or on how to fix these issues.
Certificate warnings means you’ve got a virtual directory URL or SCP configured with a name that isn’t on the cert.
I recommend reviewing them all again:
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
This article is just a review. There’s no cutover yet. That is covered later in the article series. You can see an index of the whole series here:
https://www.practical365.com/exchange-2010-to-exchange-2013-migration/
The Autodiscover (and other) namespaces eventually get cutover to the Exchange 2013 server(s). They then proxy requests from 2010 mailbox users to a 2010 CAS. That is also covered in the cutover article.
Pingback: bottle calgary
Pingback: More Tips
Pingback: microsoft course london
Pingback: ISM
Pingback: enlighteneddemocracy.no
Pingback: door problem
Pingback: Ebon Talifarro
Pingback: centralhacks.com
Pingback: city airport
Pingback: heating cooling supply
Pingback: tv production Companies
Pingback: thoi trang tre em
Pingback: crucial data
Pingback: visit site
Pingback: miami white hot jersey
Pingback: natural acne treatment medicine
Hi Paul, thanks for the great article. Sorry for a real dumb question here, which part of the DNS settings to I need to follow? Is it the autodiscover SCP?
To confirm, its currently a two server exchange 2010 environment, one hosting CAS the other MBX.
Presumably I am reading correctly in that we modify the autodiscover dns record internally to point soley at the existing CAS server, once the autodiscovery record for 2013 has been created?
The SCP is updated when you use Set-ClientAccessServer to modify the AutoDiscoverServiceInternalUri attribute for each CAS.
The AutoDiscoverServiceInternalUri can be any name, autodiscover.domain.com, mail.domain.com, somethingelse.domain.com. Domain joined clients will look up the SCP, then look up that name in DNS to resolve it to CAS IP address(es).
The “autodiscover.domain.com” DNS record will be used by non-domain joined clients. It should also point to the CAS IP address(es).
Yes, at this stage you are only reviewing and if necessary tidying up the autodiscover config in readiness for Exchange 2013 deployment. So you point your autodiscover namespaces at the Exchange 2010 CAS for now.
Pingback: comment pirater
Pingback: Exchange 2010 to 2013 Migration - Installing Exchange Server 2013
Hey Paul,
I was under the impression that changing the SCP for all current exchange versions 2007/2010 alike is mandatory… that is changing the SCP so it points to the Exchange 2013 severs autodiscover.
http://blogs.technet.com/b/mspfe/archive/2013/10/21/upgrading-to-on-premises-exchange-server-2013.aspx
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/OUC-B313#fbid=
ilantz
Yes. The cutover of the Autodiscover service to point to your Exchange 2013 CAS is a post-installation task that you perform when you have complete the configuration of Exchange 2013. When you retain the autodiscover namespace you’re already using this cutover is basically performed via DNS change once all the right configurations are in place on the servers.
Consider that the amount of configuration you are performing for your new Exchange 2013 servers will vary from environment to environment – there’s all the URLs to be configured (not a huge task), there’s SSL certs to be provisioned (may be delays due to third party CA turnaround times), there might be multiple servers (so effort is somewhat multiplied), there may be load balancers that need configuring, and also once you point Autodiscover at Exchange 2013 those servers are effectively in production, so there may also be a range of other production-readiness tasks required for your environment (backups, AV, monitoring, etc).
So that window of time between installation of Exchange 2013 and actual production readiness will vary from environment to environment.
Ultimately this article is about pre-installation review tasks that should be performed to avoid the client impacts described in the article from occurring during that window of time.
Hope that helps.
Paul, Thanks for the great post!!!
A small query here, once we install the new Server within the same site instead of different site lets say,
The internal outlook client will first use the SCP to connect to the Exchange CAS servers at this stage from my understanding even the new servers we deploy will be made available on the SCP list as they are deployed in the same site or having site scope defined and if the client connects to that server for instance though the AutodiscoverInternalURI name space remains the same and if that server does not contain the autodiscover Namespace in the cert SSL the warning will be shown to users because domain joined internal clients will look SCP first and then only fall back to DNS.
Review Rhoderick post below on the outlook client behavior, it remains the same for all deployments.
http://blogs.technet.com/b/rmilne/archive/2011/10/21/exchange-amp-the-autodiscover-web-service.aspx
So suggested method is the ensure that we deploy the new servers in temp AD site per your guideline if possible and set their namespace properly and also set them with a different sitescope to avoid waring to end users and once the SSL cert is in modify their Sitescope and make them server the existing Exchange environment.
Sharing this from my understanding and self experience, kindly review and correct me if I am wrong… Thanks…. 🙂
The temporary site is one approach that Microsoft recommends. If it is not possible or practical in your environment then use the DNS method towards the end of the article. I’ve tested that method and it seems to work well.
Thanks Paul… 🙂