Answered by:
Exchange 2010 Outlook AutoDiscover Update Issues

Question
-
Hi folks,
I have a server an Exchange server named vmINFRA-EXCH1. It acts as all roles (MB/CA/HT etc). I have internal DNS entry pointing mail.domain.com to the internal IP address of vmINFRA-EXCH1. I also have external DNS entry pointing mail.domain.com to the external IP address of vmINFRA-EXCH1.
I've purchased a certificate from Thawte, for mail.domain.com, domain.com, and autodiscover.domain.com. https://mail.domain.com/owa and /ecp are working fine, and I've left autodiscover disabled for now (I'll enable this later in the year).
The problem I now have is that Outlook users, connected to the internal network and joined to the domain.com AD domain, experience a certificate error when they configure their Outlook and start it up each day. It's because their Outlook always configures itself to vminfra-EXCH1.domain.com, which isn't included in the certificate. I've tried manually reconfiguring the Outlook profiles to point to mail.domain.com, but it always reverts back to vminfra-EXCH1.
Is there a way to change this behaviour, or am I going to have to send back the certificate and get an additional SAN on for vminfra-EXCH1.domain.com? Also, is there any danger of breaking the Exchange IIS virtual directories by forcing all access to mail.domain.com only?
Many thanks,
Alistair
- Edited by AlistairC Tuesday, July 13, 2010 8:15 PM Updated thread title to better reflect issue.
Wednesday, July 7, 2010 8:50 AM
Answers
-
There are two possible solutions to your problem as I see it.
1. Request a new certificate and include the internal domain name.
2. Configure both internal and external autodiscover to use your external domain name and possibly use a split-dns
It's your choice, you can request the new certificate or you can configure autodiscover. If you configure autodiscover to use the external domain name your clients will connect externally to receive their configuration. To prevent this you can add a zone for your external domain in your internal DNS. Then configure all internal Urls to use the external domain name instead.
Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com- Marked as answer by AlistairC Monday, August 2, 2010 9:09 AM
Wednesday, July 7, 2010 10:05 AM -
Domain Machines will look up the SCP (Service connection Point) in AD and connect to the first in the list, this is probably still the internal name of your server hence the error. you can change this,
Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>
Take a look at this article, it might help you understand the process http://technet.microsoft.com/en-us/library/bb124251.aspx & http://msexchangeteam.com/archive/2007/04/30/438249.aspx
If you need any more help please open EMS and run
Get-AutodiscoverVirtualDirectory ¦ fl Name,internalurl,externalurl
&
Get-clientAccessServer ¦ fl Name,AutoDiscoverServiceInternalUri
- Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
Saturday, July 10, 2010 1:30 AM -
Hi Alistair.
Could you please post the result of the script that you found here: http://msunified.net/2010/01/13/configure-exchange-2010-internalurl-powershell-script/ so that we can be a 100% sure that the internal urls are correct. remember that you must use https and http regardless of what the script say :)
As for the outlook profile it will still point to VMINFRA-EXCH1.domain.com because you probably have not created a CAS array or changed the RPC connection point on you database. This is as expected and should not be a problem.
Ståle Hansen
MCITP EMA, MCTS OCS 2007, MCTS Exchange 2010
http://msunified.net- Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
Wednesday, July 14, 2010 8:37 AM -
Alistair, I dont think creating a cas array will make any difference in this scenario, though it is good practice to create a cas array before migrating users to your Exchange 2010 environment. In you case name of the CAS array would be mail.domain.com. see this article about this: http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclientaccessserver-database-parameter/
Regarding the certificate issue you are having now, I think it may be a problem with you certificate. It may be that you need to enable the certificate to be all purpose. do this on the certificate itself and also on the root certificates for Thawte on the exchange server only. see this article regarding this issue. It is about a OCS problem, but may apply in this scenario. http://ocsguy.com/2010/01/13/a-certificate-gotcha-that-got-me-again/
Also you may have to request a new certificate without the name ".domain.com" as subject alternate name and just use mail.domain.com and autodiscover.domain.com. Alternatively you could just use only mail.domain.com and use SRV record externally for autodiscover and have it point to mail.domain.com. this works for windows mobile activesync clients and outlook anyhwere using outlook, and not for MAC clients. For testing puprose try use a local CA server in you domain if you have one to issue the certificate.
Here is the article about using srv record for autodiscover: http://support.microsoft.com/kb/940881
Let me know how it goes.
Ståle Hansen
MCITP EMA 2010, UC Voice Specialization
http://msunified.net- Marked as answer by AlistairC Monday, August 2, 2010 9:10 AM
Thursday, July 15, 2010 12:26 PM -
Hi There,
Just a final update on this issue before I close the question. My original problem was that Outlook was always prompting users with a certificate error notification. Every time I saw this behaviour I noticed that Outlook had substituted 'mail.domain.com' with 'vmINFRA-EXCH1.domain.com', which was not part of the certificate and therefore I (wrongly) assumed that this was the source of the certificate error. From that point on I concentrated on trying to get Outlook to stop replacing mail.domain.com with vmINFRA-EXCH1.domain.com, so the only test I was performing was adding a new Mail profile to Outlook to see if it picked up the correct server alias, which it never did.
After additional testing, I've now noticed that even though Outlook is still 'pointing' to vmINFRA-EXCH1, the certificate error notification is no longer occurring - I think my update of the all internal URIs at some point along my troubleshooting has caused Outlook to communicate with Exchange using the correct URLs, therefore fixing my problem; I just hadn't noticed as I was testing for the wrong behaviour. In hindsight, I should have taken a Wireshark trace in order to figure out what was going on under the hood! I just held off on an update for a couple of weeks as I wanted to be sure my issue had been resolved.
Thanks again for all your help guys, much appreciated!
Alistair
- Marked as answer by AlistairC Monday, August 2, 2010 9:12 AM
Monday, August 2, 2010 9:08 AM
All replies
-
There are two possible solutions to your problem as I see it.
1. Request a new certificate and include the internal domain name.
2. Configure both internal and external autodiscover to use your external domain name and possibly use a split-dns
It's your choice, you can request the new certificate or you can configure autodiscover. If you configure autodiscover to use the external domain name your clients will connect externally to receive their configuration. To prevent this you can add a zone for your external domain in your internal DNS. Then configure all internal Urls to use the external domain name instead.
Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.com- Marked as answer by AlistairC Monday, August 2, 2010 9:09 AM
Wednesday, July 7, 2010 10:05 AM -
Martin,
Thanks for your reply. I'm trying to reconfigure the autodiscover to use mail.domain.com. I followed instructions here:
http://technet.microsoft.com/en-us/magazine/ff381470.aspx
However a 'Test-OutlookWebServices -ClientAccessServer "vmINFRA-EXCH1" still returns:
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1019
Type : Information
Message : A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://vm
INFRA-EXCH1.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1006
Type : Information
Message : Contacted the Autodiscover service at https://vmINFRA-EXCH1.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1016
Type : Information
Message : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://vmINFRA-EXCH1
.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1015
Type : Information
Message : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://vmINFRA-EXCH
1.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1014
Type : Information
Message : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://vmINFRA-EXCH1
.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1022
Type : Success
Message : Autodiscover was tested successfully.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1024
Type : Success
Message : [EXCH] Successfully contacted the AS service at https://mail.domain.com/ews/exchange.asmx. The elapse
d time was 45 milliseconds.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1026
Type : Success
Message : [EXCH] Successfully contacted the UM service at https://mail.domain.com/ews/exchange.asmx. The elapse
d time was 15 milliseconds.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1124
Type : Success
Message : [Server] Successfully contacted the AS service at https://vminfra-exch1.domain.com/ews/exchange.asmx.
The elapsed time was 45 milliseconds.
RunspaceId : b209bc43-6b94-44f2-917f-741275e4e9e0
Id : 1126
Type : Success
Message : [Server] Successfully contacted the UM service at https://vminfra-exch1.domain.com/ews/exchange.asmx.
The elapsed time was 15 milliseconds.
Is there another configuration I'm missing to replace the vmINFRA-EXCH1 URL?
Apologies, as you can tell I'm new to Exchange 2010...
Thanks,
Alistair
Wednesday, July 7, 2010 1:27 PM -
No need to apologies!
It might be the the AutoDiscoverServiceInternalUri?
You can check this by running the following command and look for the value of the AutoDiscoverServiceInternalUri parameter:
Get-ClientAccessServer | fl
Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.comThursday, July 8, 2010 6:29 AM -
Thanks Martin,
I've reset AutoDiscoverServiceInternalUri to the correct parameter, but still no luck, Outlook still configures itself for vminfra-exch1.domain.com... I also set
Set
-AutodiscoverVirtualDirectory -InternalURL
and still no luck!If I remove the top level https://domain.com from the certificate, and replace it with vmINFRA-EXCH1.domain.com, would that break anything else? In terms of external auto discovery, http://domain.com will always divert to our company website so autodiscover will never be found there, it'll always have to go to autodiscover.domain.com instead...
Let me know what you think.
Thanks,
Alistair
Thursday, July 8, 2010 9:19 AM -
The external certificate should be a SAN certificate and include domain.com, mail.domain.com and autodiscover.domain.com, just as yours does. If you replace it with a certificate matching only the internal name, autodiscover probably would work internally but not externally.
By the way, what do you mean with " I've left autodiscover disabled for now (I'll enable this later in the year)."? In what way is it disabled?
Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.comThursday, July 8, 2010 2:01 PM -
Sorry, I meant that Outlook anywhere is disabled; I haven't specifically disabled AutoDiscover itself so it'll still be sitting with the default configuration (apart from me trying to force the URL changes...).
I'm at a loss, I've reconfigured every InternalURL I can see, but Outlook clients are STILL picking up "vmINFRA.domain.com" even if I specify "mail.domain.com" during the manual setup of the Outlook profile. I've even tried removing the reverse DNS entry and flushing the DNS cache - still the same. Perhaps there's a setting hidden somewhere in the AD I need to change... I noticed this article, but it relates to Exchange 2007 :/
Test-OutlookWebServices is now returning this:
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1019
Type : Information
Message : A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1006
Type : Information
Message : Contacted the Autodiscover service at https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1016
Type : Information
Message : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1015
Type : Information
Message : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1014
Type : Information
Message : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1022
Type : Success
Message : Autodiscover was tested successfully.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1106
Type : Information
Message : Contacted the Autodiscover service at https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.
xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1116
Type : Information
Message : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1
.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1115
Type : Information
Message : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH
1.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1114
Type : Information
Message : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1
.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1122
Type : Success
Message : Autodiscover was tested successfully.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1024
Type : Success
Message : [EXCH] Successfully contacted the AS service at https://mail.domain.com/ews/exchange.asmx. The elapse
d time was 62 milliseconds.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1026
Type : Success
Message : [EXCH] Successfully contacted the UM service at https://mail.domain.com/ews/exchange.asmx. The elapse
d time was 15 milliseconds.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1124
Type : Success
Message : [Server] Successfully contacted the AS service at https://vminfra-exch1.domain.com/ews/exchange.asmx.
The elapsed time was 374 milliseconds.
RunspaceId : 171c277e-bbb7-475c-b685-9eac7bfa80c1
Id : 1126
Type : Success
Message : [Server] Successfully contacted the UM service at https://vminfra-exch1.domain.com/ews/exchange.asmx.
The elapsed time was 15 milliseconds.
I guess I'll just have to return my current Thawte certificate and spend another £189 on another additional SAN :( It won't break the bank but it annoys me that I shouldn't have to yet can't get Autodiscover to play ball!
Thanks,
Alistair
- Edited by AlistairC Monday, July 12, 2010 9:41 AM
Friday, July 9, 2010 7:16 PM -
Just one thing, have you restarted IIS after applying the changes in Client Access?
Martin Sundström | Microsoft Certified Trainer | MCITP: Enterprise Messaging Administrator 2007/2010 | http://msundis.wordpress.comFriday, July 9, 2010 7:41 PM -
I'm currently working the same issue. mine has only happened to a few users as I just fired up the 2010 CAS yesterday. I'm suspecting the internalurl; made the changes and I'm bouncing the server.
If you right click the outlook icon and do a test autodiscover do you see your invalid fqdn showing up anywhere?
http://exchangedeepthoughts.blogspot.comFriday, July 9, 2010 7:54 PM -
Domain Machines will look up the SCP (Service connection Point) in AD and connect to the first in the list, this is probably still the internal name of your server hence the error. you can change this,
Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>
Take a look at this article, it might help you understand the process http://technet.microsoft.com/en-us/library/bb124251.aspx & http://msexchangeteam.com/archive/2007/04/30/438249.aspx
If you need any more help please open EMS and run
Get-AutodiscoverVirtualDirectory ¦ fl Name,internalurl,externalurl
&
Get-clientAccessServer ¦ fl Name,AutoDiscoverServiceInternalUri
- Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
Saturday, July 10, 2010 1:30 AM -
Hi,
Martin - yes I've restarted IIS, recycled the webapps, restated the whole server - no luck. Blackuke, I've already made that change I'm afraid, see below for outputs:
[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory | fl Name,internalurl,externalurl
Name : Autodiscover (Default Web Site)
InternalUrl : https://mail.domain.com//Autodiscover/Autodiscover.xml
ExternalUrl :
[PS] C:\Windows\system32>Get-ClientAccessServer | fl name,AutoDiscoverServiceInternalUri
Name : VMINFRA-EXCH1
AutoDiscoverServiceInternalUri : https://mail.domain.com/Autodiscover/Autodiscover.xml
Knightly, I didn't know about the CTRL+Click on Outlook... Look at the XML the autodiscover is returning:
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>Alistair</DisplayName>
<LegacyDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Alistair</LegacyDN>
<DeploymentId>43910e92-c468-4b17-90e5-fbee2a318d9a</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>VMINFRA-EXCH1.domain.com</Server>
<ServerDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=VMINFRA-EXCH1</ServerDN>
<ServerVersion>7380827F</ServerVersion>
<MdbDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=VMINFRA-EXCH1/cn=Microsoft Private MDB</MdbDN>
<PublicFolderServer>VMINFRA-EXCH1.domain.com</PublicFolderServer>
<AD>vmINFRA-DC1.domain.com</AD>
<ASUrl>https://mail.domain.com/ews/exchange.asmx</ASUrl>
<EwsUrl>https://mail.domain.com/ews/exchange.asmx</EwsUrl>
<EcpUrl>https://mail.domain.com/ecp</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
<OOFUrl>https://mail.domain.com/ews/exchange.asmx</OOFUrl>
<UMUrl>https://mail.domain.com/ews/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://mail.domain.com/OAB/398ac3c3-8ed4-4224-8d7f-2621cb8e5137/</OABUrl>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://mail.domain.com/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://mail.domain.com/ews/exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://mail.domain.com/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://mail.domain.com/ews/exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
</Account>
</Response>
</Autodiscover>
Specifically, the <Server>VMINFRA-EXCH1.domain.com</Server> and <PublicFolderServer>VMINFRA-EXCH1.domain.com</PublicFolderServer>... I wonder if I can somehow change that without breaking other functionality? I'm just trying to get Outlook clients to connect to the DNS alias mail.domain.com instead of the Exchange server FQDN hostname vmINFRA-EXCH1.domain.com; maybe Exchange 2010 autodiscover doesn't support this...
Thanks,
Alistair
Monday, July 12, 2010 8:01 AM -
maybe change your EWS url too?
That'll cover OOF and Availability.
http://exchangedeepthoughts.blogspot.comMonday, July 12, 2010 9:54 PM -
Tried that too - all are set to mail.domain.com, even the InternalNLBBypassURL (which could cause issues in future)... TestOutlookWebServices still gets:
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1019
Type : Information
Message : A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1006
Type : Information
Message : Contacted the Autodiscover service at https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1016
Type : Information
Message : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1015
Type : Information
Message : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1014
Type : Information
Message : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://mail.domain.com/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1022
Type : Success
Message : Autodiscover was tested successfully.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1106
Type : Information
Message : Contacted the Autodiscover service at https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1116
Type : Information
Message : [EXCH] The AS is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1115
Type : Information
Message : [EXCH] The OAB is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1114
Type : Information
Message : [EXCH] The UM is configured for this user in the AutoDiscover response received from https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1122
Type : Success
Message : Autodiscover was tested successfully.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1024
Type : Success
Message : [EXCH] Successfully contacted the AS service at https://mail.domain.com/ews/exchange.asmx. The elapsed time was 109 milliseconds.
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1026
Type : Success
Message : [EXCH] Successfully contacted the UM service at https://mail.domain.com/ews/exchange.asmx. The elapsed time was 31 milliseconds.
So it all looks fine till it gets to here:
RunspaceId : 5610f07b-4d85-4e21-bfcc-2d7b1ee5eeca
Id : 1106
Type : Information
Message : Contacted the Autodiscover service at https://VMINFRA-EXCH1.domain.com:443/Autodiscover/Autodiscover.xml.
I've updated every single configuration URL I can find, both in EMS and the EMC, I'm at a complete loss as to where it's picking up the server name from. Must be hidden somewhere deep in the Active Directory. As a side note, I've noticed the EMS always connects to vmINFRA-EXCH1 too, but maybe that's expected.
I've run out of time, just got to bite the bullet and buy another additional SAN for my Thawte certificate... Roll on Exch 2010 SP1, this release just feels half-baked at the moment, barely production-ready IMO.
Thanks for trying guys!
Alistair
Tuesday, July 13, 2010 8:02 PM -
Hi Alistair.
Could you please post the result of the script that you found here: http://msunified.net/2010/01/13/configure-exchange-2010-internalurl-powershell-script/ so that we can be a 100% sure that the internal urls are correct. remember that you must use https and http regardless of what the script say :)
As for the outlook profile it will still point to VMINFRA-EXCH1.domain.com because you probably have not created a CAS array or changed the RPC connection point on you database. This is as expected and should not be a problem.
Ståle Hansen
MCITP EMA, MCTS OCS 2007, MCTS Exchange 2010
http://msunified.net- Marked as answer by AlistairC Monday, August 2, 2010 9:11 AM
Wednesday, July 14, 2010 8:37 AM -
Hello,
Thanks for your reply. PFA the entire output from the scripts:
[PS] C:\Users\alistair\Desktop>.\InternalURL.ps1
Type internal Client Access FQDN starting with http:// or https://: https://mail.domain.com
WARNING: The command completed successfully but no settings of 'VMINFRA-EXCH1\owa (Default Web Site)' have been
modified.
WARNING: The command completed successfully but no settings of 'VMINFRA-EXCH1\ecp (Default Web Site)' have been
modified.
Identity InternalUrl
-------- -----------
VMINFRA-EXCH1\Autodiscover (Default Web Site) https://mail.domain.com/autodiscover/autodiscover.xml
Identity AutoDiscoverServiceInternalUri
-------- ------------------------------
VMINFRA-EXCH1 https://mail.domain.com/autodiscover/autodiscover.xml
Identity InternalUrl
-------- -----------
VMINFRA-EXCH1\EWS (Default Web Site) https://mail.domain.com/ews/exchange.asmx
Identity InternalUrl
-------- -----------
VMINFRA-EXCH1\OAB (Default Web Site) https://mail.domain.com/oab
Identity InternalUrl
-------- -----------
VMINFRA-EXCH1\owa (Default Web Site) https://mail.domain.com/owa
Identity InternalUrl
-------- -----------
VMINFRA-EXCH1\ecp (Default Web Site) https://mail.domain.com/ecp
Identity InternalUrl
-------- -----------
VMINFRA-EXCH1\Microsoft-Server-ActiveSync (Default Web S... https://mail.domain.com/Microsoft-Server-ActiveSync
[PS] C:\Users\alistair\Desktop>
Do you think creating a CAS array would resolve the issue? Would this even be possible with only one CAS server... I presume changing the RPC connection point is more likely to create other problems?
Thanks,
Alistair
Wednesday, July 14, 2010 9:55 AM -
Alistair, I dont think creating a cas array will make any difference in this scenario, though it is good practice to create a cas array before migrating users to your Exchange 2010 environment. In you case name of the CAS array would be mail.domain.com. see this article about this: http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclientaccessserver-database-parameter/
Regarding the certificate issue you are having now, I think it may be a problem with you certificate. It may be that you need to enable the certificate to be all purpose. do this on the certificate itself and also on the root certificates for Thawte on the exchange server only. see this article regarding this issue. It is about a OCS problem, but may apply in this scenario. http://ocsguy.com/2010/01/13/a-certificate-gotcha-that-got-me-again/
Also you may have to request a new certificate without the name ".domain.com" as subject alternate name and just use mail.domain.com and autodiscover.domain.com. Alternatively you could just use only mail.domain.com and use SRV record externally for autodiscover and have it point to mail.domain.com. this works for windows mobile activesync clients and outlook anyhwere using outlook, and not for MAC clients. For testing puprose try use a local CA server in you domain if you have one to issue the certificate.
Here is the article about using srv record for autodiscover: http://support.microsoft.com/kb/940881
Let me know how it goes.
Ståle Hansen
MCITP EMA 2010, UC Voice Specialization
http://msunified.net- Marked as answer by AlistairC Monday, August 2, 2010 9:10 AM
Thursday, July 15, 2010 12:26 PM -
Hi There,
Just a final update on this issue before I close the question. My original problem was that Outlook was always prompting users with a certificate error notification. Every time I saw this behaviour I noticed that Outlook had substituted 'mail.domain.com' with 'vmINFRA-EXCH1.domain.com', which was not part of the certificate and therefore I (wrongly) assumed that this was the source of the certificate error. From that point on I concentrated on trying to get Outlook to stop replacing mail.domain.com with vmINFRA-EXCH1.domain.com, so the only test I was performing was adding a new Mail profile to Outlook to see if it picked up the correct server alias, which it never did.
After additional testing, I've now noticed that even though Outlook is still 'pointing' to vmINFRA-EXCH1, the certificate error notification is no longer occurring - I think my update of the all internal URIs at some point along my troubleshooting has caused Outlook to communicate with Exchange using the correct URLs, therefore fixing my problem; I just hadn't noticed as I was testing for the wrong behaviour. In hindsight, I should have taken a Wireshark trace in order to figure out what was going on under the hood! I just held off on an update for a couple of weeks as I wanted to be sure my issue had been resolved.
Thanks again for all your help guys, much appreciated!
Alistair
- Marked as answer by AlistairC Monday, August 2, 2010 9:12 AM
Monday, August 2, 2010 9:08 AM -
OK, this is a bit old, but I had the same issue. The thing is that I did everything as described here on the Exchange server, however, Outlook showed still that damn certificate warning. After I renamed the local Outlook profile (C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook) to force Outlook to sync with Exchange, everything was peachy!!!!Wednesday, January 23, 2013 10:39 AM