I'm migrating ~50 2003 mailboxes this weekend, and because we can do them all at once we won't have a mailbox co-existence period. So I'm happy I won't need to mess with single-sign on nor the additional cert cost. After reviewing this page, http://blogs.catapultsystems.com/IT/archive/2010/02/17/exchange-2010-part-2-of-4-%E2%80%93-understanding-the-new-uc-san-certificate-requirement.aspx, I'm wondering if I am overcomplicating the cert request I had planned to submit. Their infrastructure was not designed with a Exchange front-end server; the firewall forwards requests on those ports directly to their single E2003 server. They currently have 5 e-mail domains, but their current SSL cert only includes the primary. So they receive a cert warning if they attempt to get to the webmail host for domains 2-5, but it'll still route to the destination. If there won't be a co-existence period, what hosts do I need to include in the cert? I had planned to include: webmail: domain1.com [primary outside] domain1.local [inside alias to CAS server] Autodiscover: domain1.com domain2.com domain3.com domain4.com domain5.com The E2010 will have a dedicated virtual CAS server, and a physical HT/MBX server. Should I include the real hostnames for either of those servers in the cert request? Thanks! Jim

you would normally need your mail address (webmail.constoso.com), autodiscover.contoso.com, internal FQDN of the CAS. I'm guessing all those other domains wont be needed on the cert because they're not coming in over SSL on 443. If those are just other domains you accept mail for, you shouldnt need the domain names in the cert. NOW -- if they all need to be able to go to a webmail.theirdomain.com, then thats 443 traffic and you'll want to add all of those entries onto the cert. I should point out in Exchange 2010, your certificate is generated in a wizard through the EMC..it will walk you through the cert generation step by step. Hope this helps..let us know!

No need for root of the domains. I don't include any root domains in the certificate requests I do, because all root domains point to a public web site - too many people enter domain.com rather than www.domain.com these days. So the host names that you need are: host.example.com (common name used for OWA, Outlook Anywhere, ActiveSync etc, can also be used for MX records) autodiscover.example.com server.domain.local server Personally I wouldn't bother with webmail.domain.local - setup a split DNS system so that the public name resolves internally as well. Keeps things simple. Now, the additional domains - this depends on whether you have users with those domains as their PRIMARY email address. If not, then you don't need autodiscover. If they do, then you will need to either add each domain with autodiscover (which could get expensive depending in the provider) or look at using SRV records or similar for autodiscover. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

We submitted the following earlier today: webmail.domain.com autodiscover.domain.com ahp-excas01.domain.local We received a message back from Comodo saying that it couldn't include the .local record, so we removed it. I'm trying to recall which stores the Entrust & USERTrust certs go into, though.

We submitted the following earlier today: webmail.domain.com autodiscover.domain.com ahp-excas01.domain.local We received a message back from Comodo saying that it couldn't include the .local record, so we removed it. I'm trying to recall which stores the Entrust & USERTrust certs go into, though.

I am surprised that your certificate provider will not allow a .local domain - particularly if they are advertising them as Unified Communications certificates. If you were using the UM role then you would be stuck with using self signed certificates, or using another provider, because the UM role requires the FQDN of the server to be in the certificate. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

I am surprised that your certificate provider will not allow a .local domain - particularly if they are advertising them as Unified Communications certificates. If you were using the UM role then you would be stuck with using self signed certificates, or using another provider, because the UM role requires the FQDN of the server to be in the certificate. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

It figures... Outlook is barking about the .local address. I spoke with Comodo tech support and they advised that all the CA's will stop including non-internet domains later this year, in about 6 months I think he said. Until then, the orders need to be manually validated to keep the .local-type addresses in the cert. I replaced just the Exchange cert (I did not re-import the Entrust or USERTrust certs), and now it includes 'ahp-excas01.domain.com', but after closing and re-opening Outlook it still gives the same error: Security Alert ahp-excas01.domain.local [Check] The security certificate is from a trusted certifying authority. [Check] The security certificate date is valid. [Red X] The name on the security certificate is invalid or does not match the name of the site. When I open the new certificate in EMC, goto the details tab, and look at the Subject Alternative Name field, it shows this: DNS Name=domain.com DNS Name=ahp-excas01.domain.local DNS Name=autodiscover.domain.com DNS Name=webmail.domain.com

It figures... Outlook is barking about the .local address. I spoke with Comodo tech support and they advised that all the CA's will stop including non-internet domains later this year, in about 6 months I think he said. Until then, the orders need to be manually validated to keep the .local-type addresses in the cert. I replaced just the Exchange cert (I did not re-import the Entrust or USERTrust certs), and now it includes 'ahp-excas01.domain.com', but after closing and re-opening Outlook it still gives the same error: Security Alert ahp-excas01.domain.local [Check] The security certificate is from a trusted certifying authority. [Check] The security certificate date is valid. [Red X] The name on the security certificate is invalid or does not match the name of the site. When I open the new certificate in EMC, goto the details tab, and look at the Subject Alternative Name field, it shows this: DNS Name=domain.com DNS Name=ahp-excas01.domain.local DNS Name=autodiscover.domain.com DNS Name=webmail.domain.com

And if you open Outlook and go to where you configure what server the client is pointed at (Outlook 2010 ->File, Account Settings, Change Account Settings, Change button) you'll see a screen like this, does the name here match that name on the cert?

And if you open Outlook and go to where you configure what server the client is pointed at (Outlook 2010 ->File, Account Settings, Change Account Settings, Change button) you'll see a screen like this, does the name here match that name on the cert?

I forgot to re-assign services after replacing the new cert, that error is fixed. Hopefully that's the end of it :)

Another issue which I'm told may be due to incorrect cert design. After all the mailboxes were sucessfully moved, the iPhone users are able to validate their settings, but when they attempt to open Mail they're told it is unable to connect. This is with the cert installed on the CAS server but not the HT/MBX server. When I ran the testexchangeconnectivity.com test last night, it was barking that the common name on the cert was domain.com, whereas Exchange said it was msstd:webmail.domain.com. So I used the set-outlookprovider cmdlet to change the common name to webmail.domain.com and the mutual authentication error was no longer reported. The support provider we're taking over for indicated that the common name needs to be webmail.domain.com, and also suggested adding all internal Exchange hostnames to the cert, as well as autodiscover.domain.local to avoid internal user grief. So I added the existing cert to the HT/MBX role even though the cert doesn't have the HT/MBX FQDN included. Still no joy with the iPhone Mail access. Recommendations?

Another issue which I'm told may be due to incorrect cert design. After all the mailboxes were sucessfully moved, the iPhone users are able to validate their settings, but when they attempt to open Mail they're told it is unable to connect. This is with the cert installed on the CAS server but not the HT/MBX server. When I ran the testexchangeconnectivity.com test last night, it was barking that the common name on the cert was domain.com, whereas Exchange said it was msstd:webmail.domain.com. So I used the set-outlookprovider cmdlet to change the common name to webmail.domain.com and the mutual authentication error was no longer reported. The support provider we're taking over for indicated that the common name needs to be webmail.domain.com, and also suggested adding all internal Exchange hostnames to the cert, as well as autodiscover.domain.local to avoid internal user grief. So I added the existing cert to the HT/MBX role even though the cert doesn't have the HT/MBX FQDN included. Still no joy with the iPhone Mail access. Recommendations?

Jim - you are correct that the issues you are seeing are related to FQDN assignment and certificate names. You are not alone in this so lets see what we can do to get you fixed up. For background purposes read this http://technet.microsoft.com/en-us/library/dd351198.aspx This is what I see lacking above, a clear understanding of what the URLs should be set to, and THEN you go and buy the necessary certs with those names on it. What is the actual subject name of the certificate? You mention that you have the below " When I open the new certificate in EMC, goto the details tab, and look at the Subject Alternative Name field, it shows this: DNS Name=domain.com DNS Name=ahp-excas01.domain.local DNS Name=autodiscover.domain.com DNS Name=webmail.domain.com " What does it say for the "Subject Name" on that tab, and also back on the general tab what is listed there for the "issued to:" field? You also want to double check what the CAS URLs are set to. Check the OWA, OA, ActiveSync, EWS, OAB URLs to ensure that you are using the name you expect. Easiest way is in Exchange Management Shell and do the following Get-OWAVirtualDirectory | select name, *URL* Get-ECPVirtualDirectory | select name, *URL* Get-ExchangeWebServicesVirtualDirectory | select name, *URL* etc, etc. (pls check for typos as I'm doing this from memory !) I would agree that the common name should be something like webmail.domain.com rather than jsut domain.com. There is no reason to add all internal host names to the cert - but that is dependent on you configuring the correct URLs into Exchange. It will only use what you tell it to use :) "Domain.com" would be added to the cert to facilitate email encryption, but lets leave that as out of scope since you are having CAS issues here. For certificates pay attention to the certificate principle name (subject name) for the following: Windows XP users who want to do outlook anywhere, the name you configure for OA, must the the principle name, and not a SAN name. Due to issues with mobile phones recommend to also point them to the subject name, to prevent issues with the SAN or also using a wildcard cert. If you want to use the SAN name or a wildcard then test, test test the modes of phones you will support. Cheers, Rhoderick

Jim - you are correct that the issues you are seeing are related to FQDN assignment and certificate names. You are not alone in this so lets see what we can do to get you fixed up. For background purposes read this http://technet.microsoft.com/en-us/library/dd351198.aspx This is what I see lacking above, a clear understanding of what the URLs should be set to, and THEN you go and buy the necessary certs with those names on it. What is the actual subject name of the certificate? You mention that you have the below " When I open the new certificate in EMC, goto the details tab, and look at the Subject Alternative Name field, it shows this: DNS Name=domain.com DNS Name=ahp-excas01.domain.local DNS Name=autodiscover.domain.com DNS Name=webmail.domain.com " What does it say for the "Subject Name" on that tab, and also back on the general tab what is listed there for the "issued to:" field? You also want to double check what the CAS URLs are set to. Check the OWA, OA, ActiveSync, EWS, OAB URLs to ensure that you are using the name you expect. Easiest way is in Exchange Management Shell and do the following Get-OWAVirtualDirectory | select name, *URL* Get-ECPVirtualDirectory | select name, *URL* Get-ExchangeWebServicesVirtualDirectory | select name, *URL* etc, etc. (pls check for typos as I'm doing this from memory !) I would agree that the common name should be something like webmail.domain.com rather than jsut domain.com. There is no reason to add all internal host names to the cert - but that is dependent on you configuring the correct URLs into Exchange. It will only use what you tell it to use :) "Domain.com" would be added to the cert to facilitate email encryption, but lets leave that as out of scope since you are having CAS issues here. For certificates pay attention to the certificate principle name (subject name) for the following: Windows XP users who want to do outlook anywhere, the name you configure for OA, must the the principle name, and not a SAN name. Due to issues with mobile phones recommend to also point them to the subject name, to prevent issues with the SAN or also using a wildcard cert. If you want to use the SAN name or a wildcard then test, test test the modes of phones you will support. Cheers, Rhoderick

On the Certificates General tab, it is issued to 'domain.com', and also on the details tab, the Subject field shows 'CN=domain.com' owa (Default Web Site): InternalUrl: https://ahp-excas01.domain.local/owa ExternalUrl: https://webmail.domain.com/owa ecp (Default Web Site) InternalUrl: https://ahp-excas01.domain.local/ecp ExternalUrl: https://webmail.domain.com/ecp Web services InternalNLBBypassUrl: https://ahp-excas01.domain.local/ews/exchange.asmx InternalUrl: https://ahp-excas01.domain.local/EWS/Exchange.asmx ExternalUrl: https://webmail.domain.com/EWS/Exchange..asmx I just replaced the certificate and changed the common name from domain.com to webmail.domain.com, waiting for validation. Even though the cert wizard lets you specify the prinicpal name, we overlooked that Comodo has a separate field to specify the common name. But now we're getting calls that mobile phone users can't connect. The previous certificate is still listed as valid, does a new pending certificate knock out service? Any special steps to reduce this downtime for a cert change?

The mobile phone issue was likely unrelated to the cert. I had previously attempted to change the common name from PS, and issued a iisreset /noforce, but the service did not restart. Once I restarted it the phones were back in business. The only known remaining problem, and perhaps we're just doing it wrong and/or it's not certificate related, are thes probably related scenarios: 1) A person who works in a remote office and uses a wireless connection to the internet can no longer check mail. It was working fine with Exchange 2003 and Outlook 2007. We upgraded him to Outlook 2010 and attempted to configure the AutoDiscover settings. Some times he does come into the corporate office which would then be an internal network. 2) I tried setting up a new Outlook mail profile while only connected to an open wireless connection. It wasn't exactly a smooth process. It failed at one point, but then it listed the correct internal server name (ahp-excas01.domain.local) in the server field, and had the correct e-mail address in the other field, but the e-mail address was prefixed by =SMTP: (or something like that). If I removed the prefix and clicked check name, it popped up a window requesting the password for that e-mail address, but it would not accept it. Do these previously configured remote users need to connect on the LAN to recognize that the mailbox has moved? Can you configure a new profile using AutoDiscover?

The mobile phone issue was likely unrelated to the cert. I had previously attempted to change the common name from PS, and issued a iisreset /noforce, but the service did not restart. Once I restarted it the phones were back in business. The only known remaining problem, and perhaps we're just doing it wrong and/or it's not certificate related, are thes probably related scenarios: 1) A person who works in a remote office and uses a wireless connection to the internet can no longer check mail. It was working fine with Exchange 2003 and Outlook 2007. We upgraded him to Outlook 2010 and attempted to configure the AutoDiscover settings. Some times he does come into the corporate office which would then be an internal network. 2) I tried setting up a new Outlook mail profile while only connected to an open wireless connection. It wasn't exactly a smooth process. It failed at one point, but then it listed the correct internal server name (ahp-excas01.domain.local) in the server field, and had the correct e-mail address in the other field, but the e-mail address was prefixed by =SMTP: (or something like that). If I removed the prefix and clicked check name, it popped up a window requesting the password for that e-mail address, but it would not accept it. Do these previously configured remote users need to connect on the LAN to recognize that the mailbox has moved? Can you configure a new profile using AutoDiscover?

Pending requests will not make changes untill you complete the request, and then assign the certificate to the services. Yes - different CAs have differnet policies and tools to get certs. I ran into one 3 months ago where you could not generate a cert request on Exchange with any SAN names, and you had to add the SAN names in their tool....... Cheers, Rhoderick

Pending requests will not make changes untill you complete the request, and then assign the certificate to the services. Yes - different CAs have differnet policies and tools to get certs. I ran into one 3 months ago where you could not generate a cert request on Exchange with any SAN names, and you had to add the SAN names in their tool....... Cheers, Rhoderick

Good to hear that you are getting relief now :) Sounds like autodiscover is not quite happy. Can you go to testexchangeconnectivity.com and run through the autodiscover test there please? I'm assuming that autodiscover.domain.com is on the latest certificate?Cheers, Rhoderick

Good to hear that you are getting relief now :) Sounds like autodiscover is not quite happy. Can you go to testexchangeconnectivity.com and run through the autodiscover test there please? I'm assuming that autodiscover.domain.com is on the latest certificate?Cheers, Rhoderick

Yes, autodiscover.domain.com is on the latest certificate. The problem in this thread is similar to the problems we have been experiencing, I'll try their solutions tomorrow: http://social.technet.microsoft.com/Forums/en-US/outlook/thread/5089eb16-377e-466f-95ef-a8e12122d070/ The autodiscover test passes, results below. ExRCA is attempting to test Autodiscover for a.test@domain.com. Autodiscover was tested successfully. Test Steps Attempting each method of contacting the Autodiscover service. The Autodiscover service was tested successfully. Test Steps Attempting to test potential Autodiscover URL https://domain.com/AutoDiscover/AutoDiscover.xml Testing of this potential Autodiscover URL failed. Test Steps Attempting to resolve the host name domain.com in DNS. The host name resolved successfully. Additional Details IP addresses returned: 1.2.3.4 Testing TCP port 443 on host domain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The SSL certificate failed one or more certificate validation checks. Test Steps ExRCA is attempting to obtain the SSL certificate from remote server domain.com on port 443. ExRCA wasn't able to obtain the remote SSL certificate. Additional Details The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation. Attempting to test potential Autodiscover URL https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml Testing of the Autodiscover URL was successful. Test Steps Attempting to resolve the host name autodiscover.domain.com in DNS. The host name resolved successfully. Additional Details IP addresses returned: 5.6.7.8 Testing TCP port 443 on host autodiscover.domain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The certificate passed all validation requirements. Test Steps ExRCA is attempting to obtain the SSL certificate from remote server autodiscover.domain.com on port 443. ExRCA successfully obtained the remote SSL certificate. Additional Details Remote Certificate Subject: CN=webmail.domain.com, OU=Unified Communications, OU=WEB, O=<SNIP>, STREET=>SNIP>, L=<SNIP>, S=<SNIP>, PostalCode=<SNIP>, C=US, Issuer: CN=USERTrust Legacy Secure Server CA, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US. Validating the certificate name. The certificate name was validated successfully. Additional Details Host name autodiscover.domain.com was found in the Certificate Subject Alternative Name entry. Certificate trust is being validated. The certificate is trusted and all certificates are present in the chain. Test Steps ExRCA is attempting to build certificate chains for certificate CN=webmail.domain.com, OU=Unified Communications, OU=WEB, O=<SNIP>, STREET=<SNIP>, L=<SNIP>, S=<SNIP>, PostalCode=<SNIP>, C=US. One or more certificate chains were constructed successfully. Additional Details A total of 1 chains were built. The highest quality chain ends in root certificate CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US. Analyzing the certificate chains for compatibility problems with versions of Windows. No Windows compatibility problems were identified. Additional Details The certificate chain has been validated up to a trusted root. Root = CN=Entrust.net Secure Server Certification Authority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), O=Entrust.net, C=US. Testing the certificate date to confirm the certificate is valid. Date validation passed. The certificate hasn't expired. Additional Details The certificate is valid. NotBefore = 2/10/2012 12:00:00 AM, NotAfter = 2/9/2013 11:59:59 PM Checking the IIS configuration for client certificate authentication. Client certificate authentication wasn't detected. Additional Details Accept/Require Client Certificates isn't configured. Attempting to send an Autodiscover POST request to potential Autodiscover URLs. ExRCA successfully retrieved Autodiscover settings by sending an Autodiscover POST. Test Steps ExRCA is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml for user a.test@domain.com. The Autodiscover XML response was successfully retrieved. Additional Details Autodiscover Account Settings XML response: <?xml version="1.0"?> <Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <User> <DisplayName>AHP Test</DisplayName> <LegacyDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=<snip></LegacyDN> <DeploymentId>6bbe5cae-a0cd-4f7f-a373-fcfd3fbce2f0</DeploymentId> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>AHP-EXCAS01.domain.local</Server> <ServerDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=AHP-EXCAS01</ServerDN> <ServerVersion>738180DA</ServerVersion> <MdbDN>/o=domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=AHP-EXCAS01/cn=Microsoft Private MDB</MdbDN> <ASUrl>https://ahp-excas01.domain.local/EWS/Exchange.asmx</ASUrl> <OOFUrl>https://ahp-excas01.domain.local/EWS/Exchange.asmx</OOFUrl> <OABUrl>http://ahp-excas01.domain.local/OAB/4e022701-a400-4873-abb9-03e889191f17/</OABUrl> <UMUrl>https://ahp-excas01.domain.local/EWS/UM2007Legacy.asmx</UMUrl> <Port>0</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort> <PublicFolderServer>AHP-EXHTMBX01.domain.local</PublicFolderServer> <AD>ahp-dc01.domain.local</AD> <EwsUrl>https://ahp-excas01.domain.local/EWS/Exchange.asmx</EwsUrl> <EcpUrl>https://ahp-excas01.domain.local/ecp/</EcpUrl> <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um> <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr> <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt> <EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret> <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms> </Protocol> <Protocol> <Type>EXPR</Type> <Server>webmail.domain.com</Server> <ASUrl>https://webmail.domain.com/EWS/Exchange.asmx</ASUrl> <OOFUrl>https://webmail.domain.com/EWS/Exchange.asmx</OOFUrl> <OABUrl>https://webmail.domain.com/OAB/4e022701-a400-4873-abb9-03e889191f17/</OABUrl> <UMUrl>https://webmail.domain.com/EWS/UM2007Legacy.asmx</UMUrl> <Port>0</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort> <SSL>On</SSL> <AuthPackage>Basic</AuthPackage> <CertPrincipalName>msstd:webmail.domain.com</CertPrincipalName> <EwsUrl>https://webmail.domain.com/EWS/Exchange.asmx</EwsUrl> <EcpUrl>https://webmail.domain.com/ecp/</EcpUrl> <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um> <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr> <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt> <EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret> <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms> </Protocol> <Protocol> <Type>WEB</Type> <Port>0</Port> <DirectoryPort>0</DirectoryPort> <ReferralPort>0</ReferralPort> <Internal> <OWAUrl AuthenticationMethod="Basic, Fba">https://ahp-excas01.domain.local/owa/</OWAUrl> <Protocol> <Type>EXCH</Type> <ASUrl>https://ahp-excas01.domain.local/EWS/Exchange.asmx</ASUrl> </Protocol> </Internal> <External> <OWAUrl AuthenticationMethod="Fba">https://webmail.domain.com/owa/</OWAUrl> <Protocol> <Type>EXPR</Type> <ASUrl>https://webmail.domain.com/EWS/Exchange.asmx</ASUrl> </Protocol> </External> </Protocol> </Account> </Response> </Autodiscover>

Hello, Yes, the external autodiscover seems to be configured properly. Thanks, Simon

Hello, Yes, the external autodiscover seems to be configured properly. Thanks, Simon

Yup better- the inital failure is due to it contacting domain.com/autodiscover then it goes to autodiscover.domain.com Try those machines and lets see what it does. PS you may want to edit the above and remove the internal information.Cheers, Rhoderick

Yup better- the inital failure is due to it contacting domain.com/autodiscover then it goes to autodiscover.domain.com Try those machines and lets see what it does. PS you may want to edit the above and remove the internal information.Cheers, Rhoderick

Hello, Is there any update on this thread? Thanks, Simon

Hello, Is there any update on this thread? Thanks, Simon