Cannot set Automatic Replies - Exchange Online/Outlook 2013

[mycarsavw]

Dontcha love a good thread title?

I have an onsite server running Server 2016 Essentials. I use O365/Exchange Online and I believe Microsoft refer to this as a Hybrid setup. I have never had an onsite Exchange server for this network.

Until very recently, everything worked fine. I have made no changes to configurations either server or host side.

Outlook 2013 (all CTR installs and all up to date) users cannot set their Automatic Replies (OOO). Instead they receive an error; "Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later".

Extensive troubleshooting suggests this is due to autodiscover not working correctly. All tests using testconnectivity.microsoft.com pass and all users can receive and send emails without any problems.

Running the Auto-Configuration test in Outlook (ctrl + right click Outlook tray icon) for any user from any machine returns the following (red text is where I believe the error lies);

Log

Autodiscover to https://mydomain.com/autodiscover/autodiscover.xml starting
GetLastError=0; httpStatus=200.
Autodiscover to https://mydomain.com/autodiscover/autodiscover.xml Succeeded [0x00000000]

XML

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <User>
            <DisplayName>username@mydomain.co.uk</DisplayName>
        </User>
        <Account>
            <AccountType>email</AccountType>
            <Action>settings</Action>
            <Protocol>
                <Type>IMAP</Type>
                <Server>mydomain.co.uk</Server>
                <Port>993</Port>
                <DomainRequired>off</DomainRequired>
                <SPA>off</SPA>
                <SSL>on</SSL>
                <AuthRequired>on</AuthRequired>
                <LoginName>username@mydomain.co.uk</LoginName>
            </Protocol>
            <Protocol>
                <Type>SMTP</Type>
                <Server>mydomain.co.uk</Server>
                <Port>465</Port>
                <DomainRequired>off</DomainRequired>
                <SPA>off</SPA>
                <SSL>on</SSL>
                <AuthRequired>on</AuthRequired>
                <LoginName>username@mydomain.co.uk</LoginName>
            </Protocol>
        </Account>
    </Response>
</Autodiscover>

All DNS records (with Fasthosts) are setup and verified as per the O365 Admin Centre verification process. There's a CNAME record to divert autodiscover to autodiscover.outlook.com.

Pinging autodiscover.mydomain.co.uk from an affected machine returns autodiscover.outlook.com. Tracert completes and ends up exactly where I'd expect it to end up which makes me think there's nothing untoward there.

I can set individual OOO replies from OWA so I'm 99% certain this is a local issue. I've read about 4.3 million threads but none of them fix the issue.

Anyone have a clue before I expire?

[Splash]

Surely if you're using an up-to-date version of Outlook you should be using MAPI over HTTP, and not IMAP/SMTP? If you create a new mail profile and let it autodiscover does that then fix your issue?

EDIT: also - are your users logging into Windows using the same credentials that are used for the mailbox, or are they separate? I seem to recall a similar issue a long time ago where the credentials for Exchange Online were different to their Windows domain creds, and there was something funky happening whereby when trying to set the message Outlook was passing the local credentials rather than the Exchange credentials.

[mycarsavw]

I'm using up-to-date versions of Outlook 2013. Creating a new profile doesn't work either, the server it finds is my domain and not O365.

EDIT: IMAP/SMTP settings are being (incorrectly) autodiscovered, I think that's all because of my initial error though.

Windows and mailbox passwords are different, I hadn't even thought of that. I had to change all Exchange passwords recently due to an 'issue'.

I'll do some searching to see if I can find anything on that one, thanks!

[mycarsavw]

Changing the mailbox password to match the AD password doesn't appear to do anything other than prompt a remote user to phone me to ask why his phone wants a password

I thought I'd open the URL returned by autodiscover in a browser to see what I got. There's a single line of text "autodiscovery must be provided a valid email address" returned which I assume is why autodiscover stops. It's my understanding that a cloud based setup shouldn't see anything at all and should then start to look elsewhere.

Adding additional registry keys to one test PC forces it to look elsewhere rather than locally and that's made autodiscover start working again.

I've sent an email to our website hosts to see if they can remove whatever is being found at that address.

OOO still doesn't work though so I'll have to begin the troubleshooting again.

[mycarsavw]

Triple post, what do I win?

I've now tested this on a live machine and it works.

Added registry keys as per MS documentation to cause autodiscover to fail when it looks at mydomain.com/auto...
Repaired user profile.
Success.

Cheers again for the pointers Splash, I was reluctant to start recreating profiles but as soon as I saw my domain being populated it made me think that little bit harder.

Still no idea why this changed by itself though, I'm sure it'll remain a mystery forever.

[Splash]

Sorry, I'm not online that much these days but glad to see that you got it sorted. So long as your autodiscover. CNAME is in place then everything should Just Work, but it sounds like your config might be a little more complex.