Jump to content

Recommended Posts

Posted

Hi All, looking for some help with Autodiscover and hopefully this will be a quick resolution as i think it will be a DNS configuration but my DNS knowledge is limited..

Im working with a client whose email is being hosted by on our mail server. they are using outlook 2010/2013 and everytime they open outlook, they get a certification error. It seems that autodiscover functionality is looking for 'autodiscover.domain1.com.au' (Domain1 = client domain), and their mail server is 'mail.domain2.com.au' (domain2 = Email server domain). They are on a completely separate AD forest without any kind of trust in place, so are connecting over http i guess. in their exchange proxy settings the "use this URL to connect to my proxy server for exchange" is populated with the server within domain2 and has the mx record for the server entered in there.

 

in its current state:

the server is resolved using the fqdn of the mail server

connecting to the mail server over http (from what i can grasp)

when testing in the client domain, i cant seem to create a new outlook profile replicating other outlook profile settings as i cant authenicate against the administrator account for example.

 

i have read up on autodiscover but cant seem to find anything that is specific to my scenario. i have created a service locator record to point at autodiscover.domain2.com.au. still no joy....

 

Certificate Error attached.

certError.png

Posted
i have just discovered that Out of Office cant be set up from the outlook client either, all users have to log into OWA to configure their OOO. Im sure this is all related, and im 95% certain this is a DNS configuration that is missing....

OOO error.png

Posted

OOO is related to AutoD as it can't retrieve the settings so cannot be used.

 

Just trying to get my head around this, are you a hosting provider?

 

What is the endpoint that the customer connects to ?

 

What certs do you have and what names are on it?

 

Basically it's either rmissing a name for your end customer of they are connecting to the wrong endpoint.

 

Really need to know how Exch Is deployed.

Posted

we are hosting their email yes. their mailboxes are on our mail server and their exchange settings within outlook point at our exchange server, as mentioned above this connects thru http. i was not the person who set this up so am not entirely sure how they got this working, but they left it in a way that autodiscover is throwing up this error each time the users open outlook.

we have a certificate deployed for our exchange server in our domain, which again, their mailboxes reside on. i guess this is why it is moaning about the fact that the certificate doesnt match the name of the site. But its the correct server that outlook is connecting to so how do we establish a connection for AutoD to work?

Posted
we are hosting their email yes. their mailboxes are on our mail server and their exchange settings within outlook point at our exchange server, as mentioned above this connects thru http. i was not the person who set this up so am not entirely sure how they got this working, but they left it in a way that autodiscover is throwing up this error each time the users open outlook.

we have a certificate deployed for our exchange server in our domain, which again, their mailboxes reside on. i guess this is why it is moaning about the fact that the certificate doesnt match the name of the site. But its the correct server that outlook is connecting to so how do we establish a connection for AutoD to work?

 

You may need to add a dns entry into your clients dns records for autodiscover.[Yourdomainname]

 

And piint it to your public facing exchange address. I had a similar option with autodiscover in office365

Posted
thanks i did try this by adding a service locator record in and pointing to autodiscover.ourdomain.com.au. but this didnt work. but you suggest changing the autodiscover.ourdomain.com.au to our public facing ip?
Posted
I have only setup our AutoDis and it only works on the autodiscover.ourdomain.com and not on the ourdomain.com But if the other poeples domain name is not in the cert as a SAN then their autodiscover wont work as it will take the email address as [email protected] then it will search autodiscover.theirdomain.com for the info. My advice if you dont want to purchase another cert is to remove the autodiscover and issue the settings with your mail.domain.com so its only their email address that is different.
Posted
The settings specify my domain. the exch server specified is within my domain, the https setting points to mail.mydomain.com. then the user/mailbox specifies their email address. i.e. [email protected] - so their email address IS the only thing that is different. it is still coming up with the error that the site name is different to that on the cert.
  • 1 month later...
Posted

Hi All,

 

after having been looking into some other work i have been put back on this task of resolving this issue. i looked at it again today and started fresh, created a new mailbox on my exchange server and changed the primary smtp address to be the clients address: [email protected]. thought this is sitting on our exchange server. i set up outlook to use http(outlook anywhere) and set the address to ourdomain.com.au. the exchange server it is pointing at is exchangeserver.ourdomain.com.au. the user/mailbox name is [email protected]. When we open outlook, it loads fine, then about 30 seconds later it pops up with the cert error and it appears that it is getting a certificate for clientdomain.com.au instead of ourdomain.com.au.

 

i have tested this with other clients that we host email for and it works fine, there is no error and they must get the correct öurdomain.com.au cert. i cant understand why this particular client is receiving a different cert, if they are accessing our server, in our domain, accessing the mailbox on our exchange server.

 

any thoughts how this could be happening.

 

to me it is clearly a DNS problem - just not sure where. i have done a whois and confirmed the DNS settings appear to be correct. im stumped.

 

any ideas are greatly appreciated.

Posted
yes, we host exchange for many companies. our cert specifies our domain only, which works for outlook anywhere so long as you enter mail.ourdomain.com.au and put in the clients email address for the mailbox/username. just this one seems to be picking up a cert from somewhere else and i have no idea where.
Posted
i dont see where this would be configured. from the internet i have configured the http setting to point at mail.ourdomain.com.au. We host their dns where the mx records point to message labs, but there is no autoD record and we havent had the need to set that up for any other client that all work fine.
Posted
i guess all other clients use our internal dns for autdiscover which points to the ip of the exchange server and it works. this is an assumption. but if this works for them, i still dont understand where this other company are getting this alternate cert from as they have identical settings within outlook clients.
Posted

we configure their DNS records through our DNS provider, conexim.com.au.

 

i ran the ssl test. for our domain, it passed fine which is expected and mail.ourdomain.com.au is what the client should be using. but then i tried testing ssl for mail.clientdomain.com.au and it failed stating: "certificate name mismatch. Try these other domain names (extracted from the certificates): autodiscover.ourdomain.com.au, mail.ourdomain.com.au, www.mailourdomain.com.au." and the IP that it connects to is for our domain. this to me is normal. it is stating that it has found that for the client domain, it is going to our exchange server. Except when we set this up through outlook anywhere, it somehow gets a different certificate.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...