exchange 2010 autodiscover dns record

Ish · 18 Feb 2012 at 21:07

Hi

Our out of office notifications don't work to external email addresses but work fine to internal. I have been told that it is a DNS problem and have been told to get a DNS A record created for autodiscover.*****.org and point it to the external IP of our SBS2011 server.

Is there anything else I have to do?

Bry · 18 Feb 2012 at 21:16

eeer that doesnt sound right

What client are your users using?
If they set OOF via OWA does it work?
Remember there is an internal oof and an external one, are your users setting the correct one?
What error messages if any are received? (eventvwr etc)

Ish · 18 Feb 2012 at 21:29

They use Outlook 2010 and regardless of whether they set external OOF via OWA or in Outlook if an external email address emails them, no OOF is sent.

I can't see any errors in the server DNS event logs.

HungryHippos · 18 Feb 2012 at 21:44

They would only need an external DNS entry if the internal SRV records were not picking this up. I assume the users are running within the same network as the SBS server.

This article covers a lot of bases I would check:

http://exchangeshell.wordpress.com/...out-of-office-oof-working-with-exchange-2007/

I appreciate it says Exchange 2007, but there are not that many differences between them, most settings work on both versions unless otherwise specified.

Ish · 19 Feb 2012 at 22:55

This is what the connectivity test shows as even by adding the DNS A record for autodiscover.****.org it still doesn't work.

Is the problem the missing SRV record. Is this created on our SBS server or with our web host?

ExRCA is attempting to test Autodiscover for **@*****.org.

Testing Autodiscover failed.

Test Steps

Attempting each method of contacting the Autodiscover service.

The Autodiscover service couldn't be contacted successfully by any method.

Test Steps

Attempting to test potential Autodiscover URL https://*****.org/AutoDiscover/AutoDiscover.xml

Testing of this potential Autodiscover URL failed.

Test Steps

Attempting to resolve the host name *****.org in DNS.

The host name resolved successfully.

Additional Details

IP addresses returned: 212.46.***.**

Testing TCP port 443 on host *****.org 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 *****.org on port 443.

ExRCA successfully obtained the remote SSL certificate.

Additional Details

Remote Certificate Subject: E=[email protected], CN=plesk, OU=Plesk, O="Parallels, Inc.", L=Herndon, S=Virginia, C=US, Issuer: E=[email protected], CN=plesk, OU=Plesk, O="Parallels, Inc.", L=Herndon, S=Virginia, C=US.

Validating the certificate name.

Certificate name validation failed.

Additional Details

Host name *****.org doesn't match any name found on the server certificate E=[email protected], CN=plesk, OU=Plesk, O="Parallels, Inc.", L=Herndon, S=Virginia, C=US.

Attempting to test potential Autodiscover URL https://autodiscover.*****.org/AutoDiscover/AutoDiscover.xml

Testing of this potential Autodiscover URL failed.

Test Steps

Attempting to resolve the host name autodiscover.*****.org in DNS.

The host name resolved successfully.

Additional Details

IP addresses returned: 78.105.**.***

Testing TCP port 443 on host autodiscover.*****.org 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 autodiscover.*****.org on port 443.

ExRCA successfully obtained the remote SSL certificate.

Additional Details

Remote Certificate Subject: CN=webmail.*****.org, OU=*****, O=*****, L=*****, C=GB, Issuer: CN=DigiCert High Assurance CA-3, OU=www.digicert.com, O=DigiCert Inc, C=US.

Validating the certificate name.

Certificate name validation failed.

Additional Details

Host name autodiscover.*****.org doesn't match any name found on the server certificate CN=webmail.*****.org, OU=*****, O=*****, L=*****, C=GB.

Attempting to contact the Autodiscover service using the HTTP redirect method.

The attempt to contact Autodiscover using the HTTP Redirect method failed.

Test Steps

Attempting to resolve the host name autodiscover.*****.org in DNS.

The host name resolved successfully.

Additional Details

IP addresses returned: 78.105.**.***

Testing TCP port 80 on host autodiscover.*****.org to ensure it's listening and open.

The port was opened successfully.

ExRCA is checking the host autodiscover.*****.org for an HTTP redirect to the Autodiscover service.

The redirect (HTTP 301/302) response was received successfully.

Additional Details

Redirect URL: HTTPS://AUTODISCOVER.*****.ORG/AUTODISCOVER/AUTODISCOVER.XML

Attempting to test potential Autodiscover URL HTTPS://AUTODISCOVER.*****.ORG/AUTODISCOVER/AUTODISCOVER.XML

Testing of this potential Autodiscover URL failed.

Test Steps

Attempting to resolve the host name autodiscover.*****.org in DNS.

The host name resolved successfully.

Additional Details

IP addresses returned: 78.105.**.***

Testing TCP port 443 on host autodiscover.*****.org 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 autodiscover.*****.org on port 443.

ExRCA successfully obtained the remote SSL certificate.

Additional Details

Remote Certificate Subject: CN=webmail.*****.org, OU=*****, O=***** L=*****, C=GB, Issuer: CN=DigiCert High Assurance CA-3, OU=www.digicert.com, O=DigiCert Inc, C=US.

Validating the certificate name.

Certificate name validation failed.

Additional Details

Host name autodiscover.*****.org doesn't match any name found on the server certificate CN=webmail.*****.org,

Attempting to contact the Autodiscover service using the DNS SRV redirect method.

ExRCA failed to contact the Autodiscover service using the DNS SRV redirect method.

Test Steps

Attempting to locate SRV record _autodiscover._tcp.*****.org in DNS.

The Autodiscover SRV record wasn't found in DNS.

radderfire · 19 Feb 2012 at 23:12

Hello. Server Admin isn't my thing but I had a quick read and saw:

___

ExRCA is attempting to obtain the SSL certificate from remote server autodiscover.*****.org on port 443

Host name autodiscover.*****.org doesn't match any name found on the server certificate CN=webmail.*****.org,
____

So, it looks like you have an authentication problem in that an SSL certificate that is being read does not have the name autodiscover.*****.org on the certificate CN=webmail.*****.org.

I am guessing you need to update the SSL certificate to also include the name autodiscover.*****.org.

How you do that I have no idea. I don't really know what I'm talking about here but I hope you appreciate my attempt

Rgds

HungryHippos · 19 Feb 2012 at 23:14

No you should have those already configured when you install Exchange, at least locally anyway. If you jump onto a client machine connected on the same network and use the Oulook autodiscover tester, does this come back OK?

Autodiscover should only be needed in public DNS if you aren't connecting locally, i.e. you are on the internet elsewhere.

Also advise checking my other recommendations, config of the remote domain, smart host config, message tracking etc.

Above poster is correct as well, your cert needs to have autodiscover.domain.com on it if you want external autodiscovery to work. However I would still question your need to even have external autodiscover if you don't need it.

Ish · 19 Feb 2012 at 23:15

Thanks for having a go.

We have an IT support company who can't fix this problem and they actually provided our SSL certificate as well so I'm having to try and resolve this myself. I can't wait for our contract to end.

Is it true that if I get the SRV working properly then the certificate errors won't matter?

Ish · 19 Feb 2012 at 23:16

Eulogy said:
No you should have those already configured when you install Exchange, at least locally anyway. If you jump onto a client machine connected on the same network and use the Oulook autodiscover tester, does this come back OK?

Autodiscover should only be needed in public DNS if you aren't connecting locally, i.e. you are on the internet elsewhere.

Also advise checking my other recommendations, config of the remote domain, smart host config, message tracking etc.

Above poster is correct as well, your cert needs to have autodiscover.domain.com on it as well. However I would still question your need to even have external autodiscover if you don't need it.

I'll test this on site tomorrow and let you know.

We used to have SBS 2003 and this was migrated over to SBS 2011 and this is when OOF to external email addresses stopped working.

HungryHippos · 19 Feb 2012 at 23:20

Sorry incorrect terminology, I meant SCP not SRV. SCP is Service Connection Point and is created in AD as per technet article : http://technet.microsoft.com/en-us/library/bb124251.aspx.

SCP is the first thing which is queried for autodiscover lookups, i.e. before DNS.

This gets configured when you install Exchange afaik and you don't really need to change it. It should just work for your internal users anyway. I suspect if internal oof is working and autodiscover works internally via the SCP you may simply be dropping the mails at the Transport level. You can check this via the Message Tracking logs which was one of the suggestions in the link I posted in my original reply to you.

Check it out tomorrow and let me know how you get on.

One final thing, when doing Autodiscover test with Outlook, disable the GuessSmart stuff.

#Chri5# · 20 Feb 2012 at 09:19

Potential barking up the wrong tree here...

Reading the OP, the problem is when users set OOO (either via Outlook or OWA - both work), messages don't go out to external e-mail addresses?

If so, from the Exchange Management Console, drill down into Organisation Configuration, then Hub Transport. Under "Remote Domains" you will probably have a single entry "Default". If you go into that, what is enabled for OOO? It might be set to "Allow None".

Rob7865 · 20 Feb 2012 at 09:24

Hi
SRV Records have nothing to do with OOF Reply. SRV Records are setup to allow the Outlook client to Autodetect for the Outlook Anywhere feature.

How are you sending emails? If you're using a Smarthost connection make sure they allow OOF Emails.
Check your Exchange logs / Message tracking to see if the OOF is being generated

Rob

oddjob62 · 20 Feb 2012 at 10:13

#Chri5# said:
Potential barking up the wrong tree here...

Reading the OP, the problem is when users set OOO (either via Outlook or OWA - both work), messages don't go out to external e-mail addresses?

If so, from the Exchange Management Console, drill down into Organisation Configuration, then Hub Transport. Under "Remote Domains" you will probably have a single entry "Default". If you go into that, what is enabled for OOO? It might be set to "Allow None".

This was my thought as well... Be carefully allowing external OOO emails, as this is an easy way for spamers to harvest live email accounts.

adencool · 20 Feb 2012 at 10:13

i can confirm that oof has nothing to do with autodiscover, and there must be another reason why the oof is not working.

have you tried setting this from owa instead, does it work using this methord, also after exch2003 both internal and external messages have to be setup for oof. are you sure both messages have been setup?

out of intrest who is you current IT providor

HungryHippos · 20 Feb 2012 at 11:46

To be fair I already mentioned the remote domain/message tracking stuff in post #7 above

EvilFranky · 20 Feb 2012 at 12:06

I was a bit confused when I started reading this thread. I didn't understand why SRV records were being discussed for an OOO message issue....

It's already been said but I'd guess at looking at message tracking logs on the Exchange server, and also whether the system has been set up to allow OOO messages to be sent externally.

HungryHippos · 20 Feb 2012 at 12:32

Yeah sorry I made a mistake, I meant to say SCP not SRV. I pointed out my stupidity in post #10

SCP is relevant for autodiscover, but like you I don't think autodiscover is the problem.

Ish · 20 Feb 2012 at 20:23

#Chri5# said:
Potential barking up the wrong tree here...

Reading the OP, the problem is when users set OOO (either via Outlook or OWA - both work), messages don't go out to external e-mail addresses?

If so, from the Exchange Management Console, drill down into Organisation Configuration, then Hub Transport. Under "Remote Domains" you will probably have a single entry "Default". If you go into that, what is enabled for OOO? It might be set to "Allow None".

This is exactly the problems we are having.

i checked and the 3rd option is ticked which is allow external out-of-office............

How do I check message tracking and can you give me the menu paths as you did above.

To the person that mentioned smart hosts our smtp server only accepts emails coming from our email addresses with out domain *****.org

Thanks

HungryHippos · 20 Feb 2012 at 22:04

Well it was discussed in one of the articles that I linked above, that external out of office messages get sent with a blank sender address, so that might be your problem.

This is all in the doc I linked you earlier on in this thread: http://exchangeshell.wordpress.com/...out-of-office-oof-working-with-exchange-2007/

You can just use the Message Tracking tool in the toolbox which should be in your management console, or use PowerShell to perform the message tracking.

Rob7865 · 21 Feb 2012 at 09:06

Eulogy said:
Well it was discussed in one of the articles that I linked above, that external out of office messages get sent with a blank sender address, so that might be your problem.

As Eulogy has said - this is your problem, if the Smarthost is only accepting mail from yourdomain.org then a blank sender email will never get accepted.

Rob