Redirect Autodiscover URL’s using .htaccess

There are several ways an emailclient can perform autodiscover to detect its settings, however, most clients do not implement all methods. One example is the iPhone, which works as follows:

E-mail address entered:

  1. Connect to
  2. Connect to

This works if the root of your e-mail hosting domain points to an Exchange Client Access Server. However, most of the time it doesn’t. A common case would be that the website is hosted elsewhere on for example an Apache HTTPD server. Of course, when the iDumbPhone connects to either URL’s above, it fails because the file doesn’t exist.

If both methods fail, the iPhone bugs out and asks the user to manually enter the server address, username, domain, etc… Well they won’t be entering it, as IT guy, you will be. What you can do is redirect the iPhone’s request to your mailserver using a HTTP 302 Temporary Redirect status code. To do so:

Create a file called .htaccess in your DocumentRoot with the following content:

RedirectMatch 302 (?i)^/Autodiscover/(.*)$$1

Adjust where necessary. If your Client Access Server is

RedirectMatch 302 (?i)^/Autodiscover/(.*)$$1

This will cause all requests to to be redirected to, thus allowing iPhones to correctly autodiscover all server information needed to configure the account.

Hint: to make this work, your webhosting provider must support .htaccess files and has not blocked the RedirectMatch directive

Hint2: if autodiscover still fails and you are sure the iPhones are being correctly redirected, set the user’s UPN to ( being the e-mail domain being used – resolvable on the internet) and have your users enter that as “E-mail Address” when the iPhone asks for it.


Exchange 2013: E-mail stuck in Outbox

When testing Exchange 2013, with almost everything untouched, I was unable to send e-mail. The e-mails were stuck in Outbox with no error messages reported to the client.

When going through the Application Windows event log, the following warning is logged. My Exchange server’s name is EXHANGE1:

Source: MSExchangeFrontEndTransport
Event ID: 1035
Task Category: SmtpReceive

Inbound authentication failed with error LogonDenied for Receive connector Client Frontend EXCHANGE1. The authentication mechanism is Login. The source IP address of the client who tried to authenticate to Microsoft Exchange is [::1].

It appears by default, the “Client Frontend” receive connector won’t allow connections from its own server.

To fix it, open the ECP and navigate to “mail flow” -> “receive connectors”. Double click “Client Frontend “. Go to the “security” tab and under permission groups, tick “Exchange servers”. Click “save”.

exch-outbox-1 exch-outbox-2

I had to delete the e-mail that was stuck in Outbox, but after restarting Outlook, new e-mails were being sent to internal recipients like they were supposed to.