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 user2@domain.com 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.

Smeerpijp
  • 201
  • 1
  • 12

1 Answers1

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.

Michał Sacharewicz
  • 549
  • 8
  • 25