Autodiscover Settings for Outlook after Hosted Exchange Migration

We've migrated from on-premise to Hosted Exchange. We are seeing an issue with one Outlook client where it is still looking for the .local when you configure Outlook. How can we force it to look for the external autodiscover record and resolve their correct domain name when configuring Outlook? We are seeing an issue with sending attachments as winmail.dat and we believe it's related to this autodiscover issue.

James ParsonsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The autodiscover entry in the DNS that everyone has to follow, has to be input in your DNS server as well (log in the Hosted Exchange environment, with the Domain setup, it will show you exactly what you needed to do, just from the top of my head, autodiscover in your own domain, should now be a CNAME to

The winmail.dat error though, is something else:

Open a remote powershell session and login with the admin account of the Hosted Exchange, then use this command:

 Set-RemoteDomain Default -TNEFEnabled $false
David Johnson, CD, MVPOwnerCommented:
winmail.dat (don't use rtf in messages use html or plaintext
James ParsonsAuthor Commented:
Thanks Kimputer. We have the correct DNS records set up, I'll connect with our Hosted Exchange provider to see about Powershell Access.

David - we did try that solution already with no luck.

Thanks everyone.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

Powershell, no need to look it up. It always works:

Set-ExecutionPolicy RemoteSigned
$username = ""
$password = "xxx"
$secstr = New-Object -TypeName System.Security.SecureString
$password.ToCharArray() | ForEach-Object {$secstr.AppendChar($_)}

$Credential = new-object -typename System.Management.Automation.PSCredential `
         -argumentlist $username, $secstr
$PSSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $Credential -Authentication Basic -AllowRedirection
Import-PSSession $PSSession

Open in new window

Script only logs you in. Commands have to by typed after this (I did it on purpose, because otherwise you might miss the response to each command, and sometimes you need to read it.

If it doesn't work, yes, look it up haha
James ParsonsAuthor Commented:
Yeah unfortunately our hosted exchange provider said they don't allow access to Powershell on their servers. Only their level 3 tech's do. I've submitted a support ticket them. In the mean time, back to the original question of autodiscover - When i do a right click + Ctrl on the Outlook icon in the task bar to do the Test Auto-Configuration, it pops up with their domain.local. I'm sure this is not a good thing as it should pop up with their actual domain, no?
Ouch, I was under the assumption you were using Microsoft's services (Exchange Online or Office 365).
If you use third party, you are indeed at the mercy of their support. For both issues, you have to get back to them and check all settings one by one.
That's because with Microsoft, most things are documented well, and third party providers have their own infrastructure that might differ from industry standards.
The PowerShell solution still stands though (I tested it in many situations), it's only a matter if your provider is willing to push it through.
James ParsonsAuthor Commented:
Hi Kimputer - ok update here:  We connected with third-party support for our Hosted Exchange provider. They confirmed that the issue is related to Outlook and those autodiscover settings, and not the TNEF on the server. They were able to verify this as the issue did not occur when sending attachments from Outlook.

So i guess back to the original question:  How can we force it to look for the external autodiscover record and resolve their correct domain name when configuring Outlook?

Highly doubtful what your third party support is saying. The TNEF settings overrride Outlook's settings (it receieves the mail content, and then sends it out in a particular way). When sending attachments, you change to format of how the email is sent out (which the server along with your Outlook decides, but the server TNEF settings override this). Sending attachments and having it come out okay is not a valid check that this is a client setting causing it.
In all cases where I applied the command, the problem disappeared immediately. Blaming it on the client is easy, but it's still a fact that this command solves it (and the client can try what he wants, he cannot reproduce these winmail.dat emails ever again).
Even IF they are correct, and the client is causing it, ONE SIMPLE COMMAND solves it, why let the client go on a wild goose chase anyway? It's great you trust their support so greatly though, it's a bit unwarranted in this case though. You can even start a new topic (for instance "Did TNEF settings solve winmail.dat problem 100%?", and I can guarantee you will get 100% reply for YES). To back up my statement look here at MS's own solution: (please note my command is slightly different, applying TO ABSOLUTELY everything, while the command in this knowledge base is for a single domain)

As for the Outlook and autodiscover (which doesn't control Outlook settings like what you think it does, another statement that third party support should've told you, instead of encouring you to look at something so strange as this) settings, it's just pointing at server, it doesn't control Outlook settings.
But in any case, since you trust them so completely, it's kind of strange they didn't help you check it. As they have all the settings you need to apply, and they can verify what's wrong or not.
Just have them give you a list of which DNS settings need to be applied, and on the, just check them one by one with the nslookup command.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
James ParsonsAuthor Commented:
Kimputer - thank you for your response. I've pushed back on their support and have escalated the issue. I've referenced that MS article you included, so i'm hoping that helps. The discussion surrounding Autodiscover was actually something we thought here ourselves, simply because when we test the Outlook Auto-Configuration it defaults to email@domain.local instead of email@externaldomain.tld. We thought this might be because they are running Small Business Server 2008 and there were some remnants on the network of Exchange.  I'll let you know what the results of are support. Thank you!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.