4

Scenario:

Test environment with Exchange 2013 servers, 1 mbx server, 1 cas server. Autodiscover configured. This environment is mainly for learning/testing purposes.

Lets say I have 3 users.

user1
user2
user3

I am logged in as user1, using my Outlook 2010 client to connect to the Exchange 2013 on-premises servers, with the use of Autodiscover.

Now, user2 and user3 have shared their calendar's. User1 is viewing the calendar of user2 and user3.

Now once in a while I get the autodiscover message:

Allow this website to configure [email protected] server settings?

https:\\autodiscover.domain.com/autodiscover/autodiscover.xml

This message (not my picture):

enter image description here

Why is it, that I am logged in as User1 but receiving the autodiscover message for user2, but not for user3? I am viewing both their calendar's.

Does one understand this behavior? Some explanation would be appreciated very much.

3
  • Followed the test by the given link. Autodiscover does not give any errors.
    – doenoe
    Dec 28, 2015 at 8:14
  • Bump. Anyone..?
    – doenoe
    Feb 1, 2016 at 12:27
  • @Diamant We periodically see the same thing and it does appear to be directly related to shared calendars Jan 3, 2019 at 17:47

1 Answer 1

0

The autodiscovery process launches a non-SSL request first (http://) and then gets redirected to SSL (302 to https://). This redirection triggers the popup, unfortunately.

This behaviour is even documented here: KB2480582, although the proposed solution is insane. Also, switching discovery to HTTP ain't a good solution too. It's not secure and also Outlook will ignore the discovery result if it's served over non-SSL connection :)

A better solution could be to disable the redirection from non-SSL to SSL. This can be achieved in several ways:

  1. I use KEMP LB for my Exchange and was able to modify the HTTP redirect service to exclude any /\/autodiscover.*/ requests. Basically, you open the HTTP redirect service, create a new SubVS, assign to it an existing Autodiscover_# rule or create your own based on the regexp above (case insensitive!) and configure SubVS > Not Available Redirection Handling to Error 404. This pretty much works.
  2. If your load balancer is not up to this task, you may alternatively split the autodiscover.yourdomain to a different IP and serve HTTPS only on this address.

There are possibly many other ways to achieve this. Anyways, once http://autodiscover.yourdomain is not producing any result (or is not reachable) Outlook itself tries HTTPS over the same domain and everything works.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .