Answered by:
Exchange 2007 2010 coexist autodiscover fails

Question
-
We are migrating from 2007 to 2010. Autodiscover is not working on the 2010 CAS servers (4 of them).
SMTP=firstname.lastname@domain.com
Attempting URL https://autodiscover.domain.com/Autodiscover/Autodiscover.xml found through SCP
Autodiscover to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml starting
GetLastError=o; httpStatus=500
Autodiscover request completed with http status code 500
Autodiscover to https://autodiscover.domain.com/Autodiscover/Autodiscover.xml Failed (0x80004005)
If I browse to the page, it returns the normal XML - error 600 Invalid request page.The AutoDiscoverServiceInternalUri is set to https://autodiscover.newpagecorp.com/Autodiscover/Autodiscover.xml on both the 2007 and 2010 CAS servers.
If we point our autodiscover DNS record to the 2007 CAS servers, 2007 mail users function just fine. If we point it to 2010 CAS servers, autodiscover fails, for both 2007 mail users and 2010 mail users (we only have 3 test users migrated)Please help!
Thank you!
Thursday, April 24, 2014 7:27 PM
Answers
-
We did wind up finding the problem. It had to do with the modifications that were made to the web.config files for our Barracuda 340 load balancers.
- Proposed as answer by Angela ShiModerator Wednesday, April 30, 2014 6:48 AM
- Marked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, May 6, 2014 8:08 AM
Monday, April 28, 2014 9:01 PM
All replies
-
Just noticed this in the event log:
Log Name: Application
Source: System.ServiceModel 3.0.0.0
Date: 4/24/2014 7:06:02 PM
Event ID: 3
Task Category: WebHost
Level: Error
Keywords: Classic
User: SYSTEM
Computer: server.domain.com
Description:
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/32001227
Exception: System.ServiceModel.ServiceActivationException: The service '/Autodiscover/autodiscover.xml' cannot be activated due to an exception during compilation. The exception message is: A binding instance has already been associated to listen URI 'http://server.domain.com/Autodiscover/Autodiscover.xml'. If two endpoints want to share the same ListenUri, they must also share the same binding object instance. The two conflicting endpoints were either specified in AddServiceEndpoint() calls, in a config file, or a combination of AddServiceEndpoint() and config. . ---> System.InvalidOperationException: A binding instance has already been associated to listen URI 'http://server.domain.com/Autodiscover/Autodiscover.xml'. If two endpoints want to share the same ListenUri, they must also share the same binding object instance. The two conflicting endpoints were either specified in AddServiceEndpoint() calls, in a config file, or a combination of AddServiceEndpoint() and config.
at System.ServiceModel.Description.DispatcherBuilder.InitializeServiceHost(ServiceDescription description, ServiceHostBase serviceHost)
at System.ServiceModel.ServiceHostBase.InitializeRuntime()
at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(String normalizedVirtualPath)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
--- End of inner exception stack trace ---
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath)
Process Name: w3wp
Process ID: 8256Friday, April 25, 2014 12:17 AM -
Hi,
According to the error detail information, the issue is caused by that two endpoints want to share the same ListenUri.
Let’s check the following Autodiscover settings:
Get-autodicovervirtualdirectory |fl *url
If you have any question, please feel free to let me know.
Thanks,
Angela Shi
TechNet Community SupportFriday, April 25, 2014 9:57 AMModerator -
Hmmmm.... OK, here is what I got:
The two 2007 CAS boxes have an InternalURL of https://autodiscover.domain.com/Autodiscover/Autodiscover.xml
ExternalURL is blank.The four 2010 CAS boxes have blank entries for both InternalURL and ExternalURL. I suspect this is not correct. What should they be?
Friday, April 25, 2014 1:59 PM -
For the ClientAccessServer -AutoDiscoverServiceInternalUri, all 6 CAS servers (2007 and 2010) are set to https://autodiscover.newpagecorp.com/Autodiscover/Autodiscover.xmlFriday, April 25, 2014 2:37 PM
-
Hi,
Firstly, I’d like to explain, the InternalURL and ExternalURL parameters are not filled in by default for any of the Autodiscover virtual directories. Setting the InternalURL and ExternalURL on the Autodiscover Virtual Directory is not required, and has no effect on your configuration.
However, the internal URL settings on your Exchange 2007 server may be the key point of that your Exchange 2007 users cannot use Autodiscover properly when you point autodiscover DNS record to the Exchange 2010.
For more information, you can refer to the following information:
http://blogs.technet.com/b/rmilne/archive/2013/04/02/busting-the-set-autodiscovervirtualdirectory-myth.aspxFor the Exchange 2010 users Autodisocver issue, let’s also check the SCP object in AD:
CN=exchangeserver,CN=Autodiscover,CN=Protocols,CN=exchangeserver,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=org name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
The attribute called serviceBindingInformation is where the AutoDiscoverServiceInternalUri data is stored.Additionally, in the Exchange 2007 and Exchange 2010 coexistence environment, I recommend you use different host names for different SCP objects.
If you have any question, please feel free to let me know.
Thanks,If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com
Angela Shi
TechNet Community Support- Edited by Angela ShiModerator Monday, April 28, 2014 1:51 AM
Monday, April 28, 2014 1:51 AMModerator -
We did wind up finding the problem. It had to do with the modifications that were made to the web.config files for our Barracuda 340 load balancers.
- Proposed as answer by Angela ShiModerator Wednesday, April 30, 2014 6:48 AM
- Marked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, May 6, 2014 8:08 AM
Monday, April 28, 2014 9:01 PM