Managing Active Directory can get complicated. Often, the native tools for managing AD are just not up to the task. The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.
Course Of The Month
1 day, 20 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
exchange 2010 autodiscover issue
Posted on 2012-12-26
Dear All,
We are in the middle of migrating on of our customers from an Exchange 2003 to an Exchange 2010 server.
This customer has a very particular situation to which i haven't found a solution yet.
Let me first explain the current situation.
This company has an exchange server situated in the UK and an Exchange environment in Belgium.
The primary exchange environment is the UK one, so ALL incoming emails are sent to an MX-record pointing to the UK server. To get the emails from Users that are in Belgium, on their exchange environment, there is a pop3 download engine that pulls all mails from their accounts in UK and putts them into their own exchange environment. Primary SMTP address is identical for BOTH the UK en Belgian environment (let me call this domain name: mail.com).
This situation has been working fine, as both sides were running an exchange 2003 environment that did NOT support autodisover records.
When we started the migration to Exchange 2010, upon connection of the first mailbox, we came up with the following issue. Outlook perfectly connects to the new Exchange2010 server, but keeps prompting for the autodiscover record.
The autodiscover record that is requested is autodiscover.mail.com, so in fact, this points to their UK server, as that domain name primarily is configured on the UK server.
Now is my question:
How do i get the client pc's to connect to the actual rpc over http address (for the Belgian organisation) in stead of going to the UK side?
Additional, but very important information:
We do NOT manage the UK server side, only the Belgian server side.....
Hope I've clearly stated my problem and hope to see a solution to my issue soon.
Kind regards,
Bert
We are in the middle of migrating on of our customers from an Exchange 2003 to an Exchange 2010 server.
This customer has a very particular situation to which i haven't found a solution yet.
Let me first explain the current situation.
This company has an exchange server situated in the UK and an Exchange environment in Belgium.
The primary exchange environment is the UK one, so ALL incoming emails are sent to an MX-record pointing to the UK server. To get the emails from Users that are in Belgium, on their exchange environment, there is a pop3 download engine that pulls all mails from their accounts in UK and putts them into their own exchange environment. Primary SMTP address is identical for BOTH the UK en Belgian environment (let me call this domain name: mail.com).
This situation has been working fine, as both sides were running an exchange 2003 environment that did NOT support autodisover records.
When we started the migration to Exchange 2010, upon connection of the first mailbox, we came up with the following issue. Outlook perfectly connects to the new Exchange2010 server, but keeps prompting for the autodiscover record.
The autodiscover record that is requested is autodiscover.mail.com, so in fact, this points to their UK server, as that domain name primarily is configured on the UK server.
Now is my question:
How do i get the client pc's to connect to the actual rpc over http address (for the Belgian organisation) in stead of going to the UK side?
Additional, but very important information:
We do NOT manage the UK server side, only the Belgian server side.....
Hope I've clearly stated my problem and hope to see a solution to my issue soon.
Kind regards,
Bert
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
6
4
3
13 Comments
IMHO disabling autodiscover at domain level (A record for autodisover.domain.com to 127.0.0.1) and set it up manually.
http://exchangeserverpro.com/how-to-configure-exchange-server-2010-outlook-anywhere
http://exchangeserverpro.com/how-to-configure-exchange-server-2010-outlook-anywhere
Active 7 days ago
what do you mean with IMHO?
what do you mean with the domain level? the actual domain name or the Active directory Domain?
what do you mean with the domain level? the actual domain name or the Active directory Domain?
In my humble opinion.
I mean disabling autodiscover at the (DNS) domain level (NOT AD domain). This way you will not be bothered by autodisover. the only hassle is that you have to set up everything manually.
If I was in such a situation I would use a country code as subdomain. Also why are you using POP3 while you can use a scoped sendconnector in exchange?
I mean disabling autodiscover at the (DNS) domain level (NOT AD domain). This way you will not be bothered by autodisover. the only hassle is that you have to set up everything manually.
If I was in such a situation I would use a country code as subdomain. Also why are you using POP3 while you can use a scoped sendconnector in exchange?
Active 7 days ago
could this also solve my issue?
http://blogs.perficient.com/microsoft/2011/03/is-it-possible-to-disable-autodiscover/
http://blogs.perficient.com/microsoft/2011/03/is-it-possible-to-disable-autodiscover/
It is a solution, make sure there is no wildcard record present for *.domain.com otherwise autodiscover.domain.com will still resolve.
but yes, disabling autodiscover and entering settings manual is a way to solve your problem.
but yes, disabling autodiscover and entering settings manual is a way to solve your problem.
Active today
I have to disagree about disabling Autodiscover to resolve this problem is the best solution. That is like saying my leg hurts so I will cut it off.
Autodiscover works in two ways.
If the clients are on the domain then it doesn't use DNS records for autodiscover.example.com, it will use a value that is published to the domain by the Exchange servers. This value is AD site specific.
You would only get a prompt for autodiscover.example.com if the Outlook client is unable to get the domain information, or the client is NOT a member of the domain.
Therefore the first thing to check is that AD Sites and Services is setup correctly. If you ahve two physical locations then you should have two AD sites.
Each site should have a server with the Client Access Server role.
If you run
get-clientaccessserver | select Server, AutodiscoverServiceInterna
then you will see the URL that the clients will try and reference. That URL MUST be on the SSL certificate on the CAS role server. If it is not, then things start to fail.
Therefore your problems are probably just down to the configuration of the platform being incomplete.
Simon.
Autodiscover works in two ways.
If the clients are on the domain then it doesn't use DNS records for autodiscover.example.com, it will use a value that is published to the domain by the Exchange servers. This value is AD site specific.
You would only get a prompt for autodiscover.example.com if the Outlook client is unable to get the domain information, or the client is NOT a member of the domain.
Therefore the first thing to check is that AD Sites and Services is setup correctly. If you ahve two physical locations then you should have two AD sites.
Each site should have a server with the Client Access Server role.
If you run
get-clientaccessserver | select Server, AutodiscoverServiceInterna
then you will see the URL that the clients will try and reference. That URL MUST be on the SSL certificate on the CAS role server. If it is not, then things start to fail.
Therefore your problems are probably just down to the configuration of the platform being incomplete.
Simon.
Active 7 days ago
i can confirm that disabling the autodiscover does NOT solve my issue.
This automatically also disables functions as out of office reply.
However, Simon, i do have a correct client-accessserver configuration.
I have an active ssl certificate on the OWA and the autdiscover internal uri is configured correctly.
This automatically also disables functions as out of office reply.
However, Simon, i do have a correct client-accessserver configuration.
I have an active ssl certificate on the OWA and the autdiscover internal uri is configured correctly.
the problem is that you have mailboxes on two different servers while from the outside it looks like you have one server.
so to make this work you should rethink the architecture of your mail solution.
so to make this work you should rethink the architecture of your mail solution.
Active today
Having mulitple mailboxes on multiple sites isn't a problem. Exchange is designed to work in that way. Autodiscover isn't difficult to setup, it just needs to be done with care.
On to the original question, going back to basics.
1. Do you have a seperate name space for each location? Is the name space exposed to the internet?
2. Are you getting errors on internal or external clients?
You have said that you have a correct Client Acecss Server configuration, but haven't actually said what it is. Therefore how do we know it is correct?
Simon.
On to the original question, going back to basics.
1. Do you have a seperate name space for each location? Is the name space exposed to the internet?
2. Are you getting errors on internal or external clients?
You have said that you have a correct Client Acecss Server configuration, but haven't actually said what it is. Therefore how do we know it is correct?
Simon.
Active 7 days ago
I have only 1 smtp namespace configured on both locations, but i do have a second namespace for the belgian office to which users can connect.
i've been using this site to troubleshoot the configuration:
http://testexchangeconnectivity.com/
Microsoft ActiveSync works
and ALSO
Rpc over http works
The only error we get, inside AND outside, is that outlook is trying to connect to autodiscover.smtpdomain.co
i've been using this site to troubleshoot the configuration:
http://testexchangeconnectivity.com/
Microsoft ActiveSync works
and ALSO
Rpc over http works
The only error we get, inside AND outside, is that outlook is trying to connect to autodiscover.smtpdomain.co
Active today
It wasn't really SMTP name space that I was referring to, but HTTPS services.
Ideally you should have a unique host name for each location.
I have just completed a design and build of a 15 location Exchange 2010 platform. For that I used country code.
So in each site it was host.xx.example.com, where xx was the country (so host.uk.example.com, host.fr.example.com).
"host" was the same name both internally and externally, for that client we used webmail.
The host name was also set as the AutodiscoverServiceInterna
Test Exchange Connectivity only tests external hosts, it doesn't help with internal. There is a BETA tool available which can do some tests. You can also do it with Outlook.
Outlook will connect to autodiscover.example.com when external, and will do so at frequent intervals. You either have to ensure that autodiscover.example.com resolves to a public facing Exchange server, or ensure that it doesn't resolve at all, and use SRV records instead. Autodiscover is NOT an optional feature.
Internally, there should be nAutodiscover autodiscover unless the value you have set on the Client AccessAutodiscover autodiscover is incorrect,Autodiscoverg autdiscover. Again this should be an internal URL that resolves to the host in that country so that clients are not going across site for Autodiscover and availabilityly availabity services.
There is nothing unusual about the configuration that you have outlined, all standard stuff when multiple sites are involved.
Simon.
Ideally you should have a unique host name for each location.
I have just completed a design and build of a 15 location Exchange 2010 platform. For that I used country code.
So in each site it was host.xx.example.com, where xx was the country (so host.uk.example.com, host.fr.example.com).
"host" was the same name both internally and externally, for that client we used webmail.
The host name was also set as the AutodiscoverServiceInterna
Test Exchange Connectivity only tests external hosts, it doesn't help with internal. There is a BETA tool available which can do some tests. You can also do it with Outlook.
Outlook will connect to autodiscover.example.com when external, and will do so at frequent intervals. You either have to ensure that autodiscover.example.com resolves to a public facing Exchange server, or ensure that it doesn't resolve at all, and use SRV records instead. Autodiscover is NOT an optional feature.
Internally, there should be nAutodiscover autodiscover unless the value you have set on the Client AccessAutodiscover autodiscover is incorrect,Autodiscoverg autdiscover. Again this should be an internal URL that resolves to the host in that country so that clients are not going across site for Autodiscover and availabilityly availabity services.
There is nothing unusual about the configuration that you have outlined, all standard stuff when multiple sites are involved.
Simon.
Featured Post
Only on Experts-Exchange: Sign-up for a free-trial and we'll send you your permanent license!
Here is what you get: 30 Nodes | Unlimited Sensors | No Time Restrictions | Absolutely FREE!
Act now. This offer ends July 14, 2017.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
I was prompted to write this article after the recent World-Wide Ransomware outbreak. For years now, System Administrators around the world have used the excuse of "Waiting a Bit" before applying Security Patch Updates. This type of reasoning to me …
For anyone that has accidentally used newSID with Server 2008 R2 (like I did) and hasn't been able to get the server running again because you were unlucky (as I was) and had no backups - I was able to get things working by doing a Registry Hive rec…
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment.
The video tutorial explains the basics of the Exchange server Database Availability grou…
Attackers love to prey on accounts that have privileges.
Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …
Suggested Courses
Course of the Month1 day, 20 hours left to enroll
717 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.