Was originally setup to use their 2008 Enterprise CA so customer not only did not know how to generate the request from within Exchange but also did not know how to submit it to their own CA (I know). I suggest contacting Microsoft Support if your organization is running into this issue.Īlso, this KB offers methods to control which AutoDiscover methods are used by your Outlook clientsĬustomer had hired a Consultant to originally setup their Exchange 2007 environment and now their Certificate had expired. I’ve heard nothing concrete or public but the Outlook team is aware of the issue & listening to customer feedback. Simply put, just make sure whatever resolves to is something that’s not going to throw a certificate error. Make sure doesn’t listen on 443, or possibly get a proper cert on your website that is listening on 443. However, now they may get a certificate pop-up for when creating a new profile.
In the past, they would have found the SCP record that would have pointed them to your internal Exchange 07/10/13 server for AutoDiscover & would have been happy as a clam (one Exchange Product Manager’s favorite way to describe Exchange bliss). Now imagine you begin deploying users using Outlook 2013 in your internal environment. However if you were to query the website using https then it could respond & obviously not return a certificate with on it (because you haven’t paid for it you cheapskate…). Imagine you have a public website for hosted by a third-party hosting site & you did not pay for HTTPS/443 services. Obviously my lab environment is a corner case but there have been several other customers report this issue with Outlook 2013 as well. The error is easy enough to get through & it only occurred on initial profile creation but this can definitely prove painful for some customers. Also, because I did not have a cert installed on the server with in the Subject or Subject Alternative Name then it gave the certificate error we see above. Now because I have web enrollment enabled & am listening on 443 in IIS the server responded. resolved to this server because it’s my internal Active Directory domain name & the name server entry resolves to my DC (just ping internaldomainname.local in your AD lab environment & you’ll see the same thing). When Outlook 2013 does it’s simultaneous DNS AutoDiscover query the first URL it tries is, which in my lab environment resolved to my Domain Controller, which was also serving DNS, as well as a Certificate Authority. That’s right, I actually get a certificate pop-up for my lab’s domain name () & not like one would expect if I were to have a certificate issue on Exchange. I actually stumbled upon this while in the middle of the scenario below: If Outlook 2013 encounters any kind of Certificate error while doing the simultaneous DNS query then you will receive a pop-up in Outlook about the cert. Great idea, however there’s one problem in the implementation. If an SCP record was found it would still be used but in the event it failed then it would already have the DNS response ready to go. They decided to have domain-joined Outlook 2013 clients query both the SCP values in AD as well as the DNS records at the same time. The above methods have served us well since Exchange 2007 timeframe but for some reason the Outlook team decided to try & implement some giddyup into Outlook & try to speed up the process.
Why it ever looked to I’ll never really know because honestly I’ve never come across a customer who had it deployed that way most have but I imagine when Exchange 2007 was first being developed they weren’t exactly sure how customers would be implementing AutoDiscover. The order of this non-domain-joined lookup is as follows: If that failed then they would revert to using DNS like any non-domain-joined Outlook client. In Outlook 2007 through Outlook 2010 all domain-joined Outlook clients would initially query Active Directory for AutoDiscover information & ultimately find a Service Connection Point (SCP) value that would point them to their nearest Client Access Server’s AutoDiscover virtual directory. I originally discovered this issue back in early Feb & let a couple people on the Exchange Product Team know about it via the TAP but it seems to be affecting more customers than initially thought so I thought I’d share.
0 kommentar(er)
