This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(60.8, 75%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ED%3C/text%3E%3C/svg%3E)
Hi,
I'm in the middle of a mail migration from Exchange 2013 to Exchange 2019 and I'm facing some autodiscover issues.
Other than those "learn to configure your virtual directories" questions, my autodiscovery setup is working just fine, but the retunred url's to be used by clients arn't the URL's I expect.
Layout:
My current environment is a Hybrid environment with 3 actors in play: Office 365, my on-prem Exchange 2013 and my on-prem Exchange 2019. Nothing out of the ordinary. My goals is to phase out my 2013 server within a month.
The scenario where I spot some problems:
To make my question as straightforward as possible and prevent all kinds of AD discovery remarks, this is the test setup:
When I run an autodiscover test on the test computer for my test user, autodiscover replies to use the Exchange 2013 url to open the mailbox and not the Exchange 2019 url.
When opening Exchange 2013/owa, I can connect to the mailbox while maintaining on the Exchange 2013 URL
When opening Exchange 2019/owa, I can connect to the mailbox while maintaining on the Exchange 2019 URL
So everything seems to be proxying anyway, but how can I tell autodiscover that I want my url for Exchange 2019 mailboxes to be the url directly to Exchange 2019.
Autodiscover V2 API problem:
When trying to use the api via autodiscover2 for my Teams calendars, I end up with a real problem. Because all my autodiscover requests to Exchange 2019 persistently return my Exchange 2013 url's to be used!
So it returns Exchange 2013/api , but the API virtual directory was only introduced in Exchange 2016!
That url simply doesn't exist, returning a 404 and resulting in teams calendars not working.
The big question:
Does anybody know how I can change the priority in server URL's returned by autodiscovery?
I know quickly decomissioning my Exchange 2013 wil automatically resolve my problem, but there should be a way to change this behaviour in advance???
Anyone?
@Dimitri_T
I would suggest you change services URL in this format:
Exchange 2013: Internal URL: https://Exchange2013.domain.com/..... External URL: Null
Exchange 2019: Internal URL: https://Exchange2019.domain.com/..... External URL: https://mail.domain.com/.....
Then point external DNS record(mail.domain.com) to Exchange 2019 public IP address.
In this way, mailboxes will try to connect to Exchange 2019 and using Exchange 2019 URL, if needed, Exchange will proxy request to Exchange 2013 automatically.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
KyleXu,
thanks for you suggestion.
I've disabled all external url's on my Exchange 2013 machine, recycled the autodiscover app pools, but it doesn't change a thing.
I do need to point out though that I have both internal and external urls set to the same FQDN.
My clients resolve via split DNS.
So to clarify:
exch2013.domain.local (192.168.1.1) has an internal and external url = exch2013.domain.com, it can be reached remotely via its dedicated public IP 1.1.1.1
exch2019.domain.local (192.168.1.2) has an internal and external url = exch2019.domain.com, it can be reached remotely via its dedicated public IP 1.1.1.2
autodiscover.domain.com resolves to the public IP of my exch2019 server 1.1.1.2, and to 192.168.1.2 internally
Commands used
Set-OwaVirtualDirectory -Identity "exch2013\owa (Default Web Site)" -ExternalUrl $null
Set-EcpVirtualDirectory -Identity "exch2013\ecp (Default Web Site)" -ExternalUrl $null
Set-ActiveSyncVirtualDirectory -Identity "exch2013\Microsoft-Server-ActiveSync (Default Web Site)" -ExternalUrl $null
Set-WebServicesVirtualDirectory -Identity "exch2013\EWS (Default Web Site)" -ExternalUrl $null
Set-OabVirtualDirectory -Identity "exch2013\OAB (Default Web Site)" -ExternalUrl $null
Set-MapiVirtualDirectory -Identity "exch2013\mapi (Default Web Site)" -ExternalUrl $null
Set-OutlookAnywhere -Identity "exch2013\Rpc (Default Web Site)" -ExternalHostname $null
Any more ideas?
Why not just set the 2013 URLs to the 2019 values?
AndyDavid,
Just like phasing out my Exchange 2013 quickly, I don't see your proposal as an answer but more like a workaround/avoiding the problem.
I'm seeking a solution to this problem.
What mechanism determines to generate the wrong value and how can I correct it?
How can I make autodiscover return an existing api virtual directory?
Since you have set the Exchange 2013 external URL to Null, Exchange will use Exchange 2019 as connection point first.
About why the request be redirected to Exchange 2013, you may need to open a ticket to Microsoft, they could confirm with product teams to check the working Mechanism.
I' m afraid I have no other option.
It is indeed my 2019 autodiscover that keeps responding to use the Exchange 2013 server.
I think that even though the mailbox is hosted on 2019, some services actually hosted on Exchange 2013(function provided by Exchange 2013), so the mailbox will still use the 2013 URL. For more detailed information, you may need to open a ticket to confirm with Microsoft product team.
Another evening of digging the internet in search of a solution... but no cigar.
At least now I know I'm not alone, the guy in this article faces the same issue... autodiscover V2 returning wrong values...