Rick Goodman
asked on
Exchange 2010 DNS and SRV records
I have an Exchange 2010 environment with 2 CAS/HUB servers, 2 Mailbox servers, and 1 Edge Transport server that resides in our DMZ and has TMG 2010 running on it. Up until now, we have only allowed access to our corporate email if a user was either on our local network or connected via VPN. I'm now looking at allowing access through Outlook and/or OWA from the Internet without a VPN connection.
Our domain, company.com, has a website that resides at a hosting company, so the public A record for our domain points to the IP Address of the hosting company. I do have a public A record for both mail.company.com and webmail.company.com that point to our mail server. Do I need to add an SRV record and an A record for autodiscover.comapny.com that points to our mail server, or just an SRV record? Any help would be appreciated, thanks.
Our domain, company.com, has a website that resides at a hosting company, so the public A record for our domain points to the IP Address of the hosting company. I do have a public A record for both mail.company.com and webmail.company.com that point to our mail server. Do I need to add an SRV record and an A record for autodiscover.comapny.com that points to our mail server, or just an SRV record? Any help would be appreciated, thanks.
Sean
You don't need both. Just one or the other. I always think A records are easier to setup as long as you have autodiscover.domain.com in your cert but it is completely up to you.
Zindel1's correct. You only need one.
For external services, the only time I found myself ever adjusting anything regarding SRV, was when in our org - we had 4 public IPs for mail flow. 2 inbound and 2 outbound that were load balanced.
We had the 2 inbound ip's for SMTP listed in our MX record lookups, but external domains eventually started dropping mail from our org, since our outbound IPs didn't match the mx records, if that makes sense. We added two SRV records in this instance of the outbound IPs and everything started working at that point.
Personally, between all of the DNS types, I'm mostly a fan of CNAMEs. The shortcuts that point to A-records. - This is how I have the autodiscover.domain.com and mail.domain.com configured. autodiscover --> mail --> actual A record of the public IP. *If that makes sense. That way, should the public IP or hostname change, it's only one entry I have to edit instead of multiple.
For external services, the only time I found myself ever adjusting anything regarding SRV, was when in our org - we had 4 public IPs for mail flow. 2 inbound and 2 outbound that were load balanced.
We had the 2 inbound ip's for SMTP listed in our MX record lookups, but external domains eventually started dropping mail from our org, since our outbound IPs didn't match the mx records, if that makes sense. We added two SRV records in this instance of the outbound IPs and everything started working at that point.
Personally, between all of the DNS types, I'm mostly a fan of CNAMEs. The shortcuts that point to A-records. - This is how I have the autodiscover.domain.com and mail.domain.com configured. autodiscover --> mail --> actual A record of the public IP. *If that makes sense. That way, should the public IP or hostname change, it's only one entry I have to edit instead of multiple.
ASKER
I did just set up the autodiscover A record. I can resolve the name fine but when I run the Exchange Remote Connectivity Analyzer it fails. I get an error that states "The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response. An HTTP 403 forbidden response was received. The response appears to have come from ISA." So it appears that I might be missing something in my TMG confiiguration, just not quite sure what.
When you run the Exchange RCA internally it will look for the autodiscover in your internal DNS and may fail if your internal DNS is not configured properly for that request.
To check if you have done that quite properly, you need to go to www.testexchangeconnectivity.com and test one exchange account.
for TMG, can you post snapshots of your current configuration? How did you publish the autodiscover and the other protocols e.g. SMTP, IMAP, Pop3, RPC.?
i'll see if you got anything wrong there.
To check if you have done that quite properly, you need to go to www.testexchangeconnectivity.com and test one exchange account.
for TMG, can you post snapshots of your current configuration? How did you publish the autodiscover and the other protocols e.g. SMTP, IMAP, Pop3, RPC.?
i'll see if you got anything wrong there.
ASKER
I've run out of time today. I was running my tests from that link and from a laptop off the network, working from home. I did get OWA working from the Internet, and got my Autodiscover to pass the test, but I still can't configure an email account using Autodiscover. I'll look into it more on Monday when I'm back in. Thanks for the input and help so far. Have a wonderful holiday.
If you have outlook 2010/2013 client then ctrl + right click on the outlook client icon in the tray bar and you will see "Connection status" and "Test e-mail auto-configuration" select the Test-AC and the email credentials then hit test and post the result here please for us to see what kind of problem you have with the auto-discovery.
ASKER
Below are the results of Test e-mail auto-configuration on a configured client while off the network. All works fine when on the network. Also, when I run this, and when I try and configure a client off the network, it prompts me to login to webmail.domain.com but, no matter what I put in, it fails and keeps popping it back up on me.
Results
Autoconfiguration has started, this may take up to a minute
Autoconfiguration found the following settings:
Display Name UserName
Internal OWA URL: https://webmail.domain.com/owa/
External OWA URL: https://webmail.domain.com/owa/
Protocol Exchange RPC
Server: outlook.domain.com
Login Name: user.name
Availability Service URL: https://webmail.domain.com/EWS/Exchange.asmx
OOF URL: https://webmail.domain.com/EWS/Exchange.asmx
OAB URL: https://webmail.domain.com/OAB/ (numbers)
Unified Message Service URL: https://webmail.domain.com/EWS/UM2007/Legacy.asmx
Auth Package: Unspecified
Exchange Control Panel URL: https://webmail.domain.com/ecp/
ECP Sub URL: ?p=customize/voicemail/.as
ECP Sub URL: ?p=peronalsettings/EmailSu
ECP Sub URL: ?p=sms/textmessaging.slab&
ECP Sub URL: ?p=PersonalSettings/Delive
ECP Sub URL: ?p=organize/retentionpolic
Protocol: Exchange HTTP
Server: webmail.domain.com
Login Name: user.name
SSL: Yes
Mutual Authentication: Yes
Availability Service URL: https://webmail.domain.com/EWS/Exchange.asmx
OOF URL: https://webmail.domain.com/EWS/Exchange.asmx
OAB URL: https://webmail.domain.com/OAB/ (numbers)
Unified Message Service URL: https://webmail.domain.com/EWS/UM2007/Legacy.asmx
Auth Package: NTLM
Certificate Principal Name: msstd: <webmail.domain.com>
Exchange Control Panel URL: https://webmail.domain.com/ecp/
ECP Sub URL: ?p=customize/voicemail/.as
ECP Sub URL: ?p=peronalsettings/EmailSu
ECP Sub URL: ?p=sms/textmessaging.slab&
ECP Sub URL: ?p=PersonalSettings/Delive
ECP Sub URL: ?p=organize/retentionpolic
Log
Autodiscover to https://domain.com/autodiscover/autodiscover.xml starting
GetLastError=12175; httpStatus=0
Autodiscover to https://domain.com/autodiscover/autodiscover.xml failed (0x800C8203)
Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml starting
GetLastError=0; httpStatus-401
AD lookup for e-mail address Failed (0x80070548)
GetLastError=0; httpStatus-401
GetLastError=0; httpStatus-200
Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml Succeeded (0x00000000
Results
Autoconfiguration has started, this may take up to a minute
Autoconfiguration found the following settings:
Display Name UserName
Internal OWA URL: https://webmail.domain.com/owa/
External OWA URL: https://webmail.domain.com/owa/
Protocol Exchange RPC
Server: outlook.domain.com
Login Name: user.name
Availability Service URL: https://webmail.domain.com/EWS/Exchange.asmx
OOF URL: https://webmail.domain.com/EWS/Exchange.asmx
OAB URL: https://webmail.domain.com/OAB/ (numbers)
Unified Message Service URL: https://webmail.domain.com/EWS/UM2007/Legacy.asmx
Auth Package: Unspecified
Exchange Control Panel URL: https://webmail.domain.com/ecp/
ECP Sub URL: ?p=customize/voicemail/.as
ECP Sub URL: ?p=peronalsettings/EmailSu
ECP Sub URL: ?p=sms/textmessaging.slab&
ECP Sub URL: ?p=PersonalSettings/Delive
ECP Sub URL: ?p=organize/retentionpolic
Protocol: Exchange HTTP
Server: webmail.domain.com
Login Name: user.name
SSL: Yes
Mutual Authentication: Yes
Availability Service URL: https://webmail.domain.com/EWS/Exchange.asmx
OOF URL: https://webmail.domain.com/EWS/Exchange.asmx
OAB URL: https://webmail.domain.com/OAB/ (numbers)
Unified Message Service URL: https://webmail.domain.com/EWS/UM2007/Legacy.asmx
Auth Package: NTLM
Certificate Principal Name: msstd: <webmail.domain.com>
Exchange Control Panel URL: https://webmail.domain.com/ecp/
ECP Sub URL: ?p=customize/voicemail/.as
ECP Sub URL: ?p=peronalsettings/EmailSu
ECP Sub URL: ?p=sms/textmessaging.slab&
ECP Sub URL: ?p=PersonalSettings/Delive
ECP Sub URL: ?p=organize/retentionpolic
Log
Autodiscover to https://domain.com/autodiscover/autodiscover.xml starting
GetLastError=12175; httpStatus=0
Autodiscover to https://domain.com/autodiscover/autodiscover.xml failed (0x800C8203)
Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml starting
GetLastError=0; httpStatus-401
AD lookup for e-mail address Failed (0x80070548)
GetLastError=0; httpStatus-401
GetLastError=0; httpStatus-200
Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml Succeeded (0x00000000
ASKER
moh10ly, as you can see, autodiscover seems to be setup correctly in both internal and external DNS. I seem to be having an issue with authenticating to the mail server when outside the network. My TMG config is such:
Rule to Allow Anywhere to webmail.domain.com, I have the name of my CAS server in there, which I was able to Browse for. The Public Names the rule applies to are webmail.domain.com and autodiscover.domain.com. I ahve the paths for public, OWA, Exchange, ews, ecp, and autodiscover. Authentication Delegation is set to No delegation, but client may authenticate directly. Bridging tab is set to Web server and Rediredt requests to SSL port 443. On the Users tab I removed All Authenticated Users and added All Users.
The Listener is set for Internal and External networks with each one specifically listing the IP Address of the inside and outside interface. Both HTTP and HTTPS connections are selected with redirection set to redirect all traffic from http to https. My 3rd party certificate, which lists webmail.domain.com and autodiscover.domain.com is assigned to both IP Addresses of the inside and outside interfaces. I've selected HTML form authentication with Windows Active Directory selected.
print-screens.docx
Rule to Allow Anywhere to webmail.domain.com, I have the name of my CAS server in there, which I was able to Browse for. The Public Names the rule applies to are webmail.domain.com and autodiscover.domain.com. I ahve the paths for public, OWA, Exchange, ews, ecp, and autodiscover. Authentication Delegation is set to No delegation, but client may authenticate directly. Bridging tab is set to Web server and Rediredt requests to SSL port 443. On the Users tab I removed All Authenticated Users and added All Users.
The Listener is set for Internal and External networks with each one specifically listing the IP Address of the inside and outside interface. Both HTTP and HTTPS connections are selected with redirection set to redirect all traffic from http to https. My 3rd party certificate, which lists webmail.domain.com and autodiscover.domain.com is assigned to both IP Addresses of the inside and outside interfaces. I've selected HTML form authentication with Windows Active Directory selected.
print-screens.docx
Let me ask you question regarding your TMG first, Have you used the TMG wizard to publish Exchange 2010 Services?
If so then could you first make sure that you have one service rule publishing your Exchange's RPC over HTTP service?
The Exchange RPC Server should allow RPC traffic to pass from anywhere to your exchange server which handles the RPC traffic.
The reason why I asked this is cause if your OWA works fine without any issues then your problem is most likely to be with the RPC connection or configuration.
Just to double check with your OWA rule, let's start with the To tab. Under the "Computer name or IP address..." Try placing the IP address of your master CAS mailserver ... and tick the check mark next to the forward the original host header.
and under "proxy request" choose "Requests appear to come from the original client"
Under Application Settings untick the used customized HTML form unless you did this on purpose and u have a customized HTML for your Exchange OWA.
In the Listerner's Authentication, choose No Authentication. and then in the certificate tab make sure you reselect your public Cert and apply changes. because the client should directly authenticate to the server not with TMG.
Apply and check if it would work?
If not double check the certificate loaded in the listener tab! make sure that you have all the certificate path installed correctly including the intermediate and the root CA.
hope this works
If so then could you first make sure that you have one service rule publishing your Exchange's RPC over HTTP service?
The Exchange RPC Server should allow RPC traffic to pass from anywhere to your exchange server which handles the RPC traffic.
The reason why I asked this is cause if your OWA works fine without any issues then your problem is most likely to be with the RPC connection or configuration.
Just to double check with your OWA rule, let's start with the To tab. Under the "Computer name or IP address..." Try placing the IP address of your master CAS mailserver ... and tick the check mark next to the forward the original host header.
and under "proxy request" choose "Requests appear to come from the original client"
Under Application Settings untick the used customized HTML form unless you did this on purpose and u have a customized HTML for your Exchange OWA.
In the Listerner's Authentication, choose No Authentication. and then in the certificate tab make sure you reselect your public Cert and apply changes. because the client should directly authenticate to the server not with TMG.
Apply and check if it would work?
If not double check the certificate loaded in the listener tab! make sure that you have all the certificate path installed correctly including the intermediate and the root CA.
hope this works
ASKER
I tried the above and the ExRCA failed when I tested it so I reverted back to what I had. I did use the wizard to publish Exchange. I'm not sure about RPC over HTTP. Is that needed for autodiscover? If so, can it be RPC over HTTPS?
When you use the Wizard to publish Exchange services it will automatically create all the required rules for you.
RPC over HTTP is required for outlook to connect to Exchange server. The autodiscover is only an XML file which stores all the configuration. and from your post it seems you have a problem with Auto discover.
"The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response" which means there's a problem with your autodiscover URL publishing, it might not be accessible.
Autodiscover to https://domain.com/autodiscover/autodiscover.xml starting
GetLastError=12175; httpStatus=0
Autodiscover to https://domain.com/autodiscover/autodiscover.xml failed (0x800C8203)
Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml starting
GetLastError=0; httpStatus-401
Try to access the Autdodiscover.xml link internally and see what it returns? It should ask u for ur credentials and view some configuration
Have you tried www.testexchangeconnectivity.com ? Could you please try and let us know what it results?
RPC over HTTP is required for outlook to connect to Exchange server. The autodiscover is only an XML file which stores all the configuration. and from your post it seems you have a problem with Auto discover.
"The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response" which means there's a problem with your autodiscover URL publishing, it might not be accessible.
Autodiscover to https://domain.com/autodiscover/autodiscover.xml starting
GetLastError=12175; httpStatus=0
Autodiscover to https://domain.com/autodiscover/autodiscover.xml failed (0x800C8203)
Autodiscover to https://autodiscover.domain.com/autodiscover/autodiscover.xml starting
GetLastError=0; httpStatus-401
Try to access the Autdodiscover.xml link internally and see what it returns? It should ask u for ur credentials and view some configuration
Have you tried www.testexchangeconnectivity.com ? Could you please try and let us know what it results?
ASKER
That link is where most of my testing has been from. When I run the test for Autodiscover everything passes fine, but when I run the test for RPC over HTTP (Outlook Anywhere), it fails at the end with the info below.
Testing SSL mutual authentication with the RPC proxy server.
Verification of mutual authentication failed.
The certificate common name webmail.domain.com doesn't validate against the mutual authentication string that was provided: msstd:<webmail.domain.com>
Elapsed Time: 0 ms.
Testing SSL mutual authentication with the RPC proxy server.
Verification of mutual authentication failed.
The certificate common name webmail.domain.com doesn't validate against the mutual authentication string that was provided: msstd:<webmail.domain.com>
Elapsed Time: 0 ms.
Apparently from the error you provided it seems that you have a mismatch problem between your certificate's common name and outlook anywhere.
if your outlook anywhere's FQDN is not set as your common name if the public certificate then you most likely will fail in the autodiscover or RPC over HTTP test.
check here for more info
http://terenceluk.blogspot.com/2010/07/common-name-matters-for-outlook.html
Could you please answer each of the following?
1- What are the SANs included in your certificate?
2- What are the authentication method for your OWA in your CAS ?
3- What's the FQDN for your Outlook anywhere settings?
4- How do you publish your RPC over HTTP Protocol?
if your outlook anywhere's FQDN is not set as your common name if the public certificate then you most likely will fail in the autodiscover or RPC over HTTP test.
check here for more info
http://terenceluk.blogspot.com/2010/07/common-name-matters-for-outlook.html
Could you please answer each of the following?
1- What are the SANs included in your certificate?
2- What are the authentication method for your OWA in your CAS ?
3- What's the FQDN for your Outlook anywhere settings?
4- How do you publish your RPC over HTTP Protocol?
ASKER
1. webmail.domain.com
www.webmail.domain.com
autodiscover.domain.com
2. Looking at the Outlook Anywhere tab of the CAS properties page, where the Outlook Anywhere external name is, it’s set to NTLM
3. External host name is webmail.domain.com
4. I thought I published it as part of the Exchange publishing in TMG
www.webmail.domain.com
autodiscover.domain.com
2. Looking at the Outlook Anywhere tab of the CAS properties page, where the Outlook Anywhere external name is, it’s set to NTLM
3. External host name is webmail.domain.com
4. I thought I published it as part of the Exchange publishing in TMG
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm going to try changing the authentication and try it this weekend if I have a chance. I'm traveling and won't be back in the office until Tuesday so my time to to work on this until then will be pretty limited. I'll let you know how it goes once I try it. Thanks.
ASKER
Yeah, I tried Basic Authentication on Outlook Anywhere, same result. I agree that it's likely in my TMG. I'll try and go through it all again but I thought I had everything set correctly.
ASKER
It looks like the issue I might having is that because I have a listener configured with Basic Authentication for ActiveSync to allow connectivity with our iPhones and iPads that I can't use any other form of authentication for Outlook Anyhwere. Any ideas on if that's true or not, and if so, any work arounds?