[NA] MS Exchange and Office 365

[AggieMike88]

I am having challenges setting up an email box on my workstation. I have an Office 365 Enterprises level account and MS Exchange server to go with it. And I have MS Outlook 2016 on my workstation (PC).

Something has changed with the auto discover mode such that a redirect to something with cpanel.com is interferring.

Two or three weeks a new box was auto discovered and configured no problem...

Now his cPanel thing is getting in the way.


Does anyone have experience in manually setting up an email box to work with MS Exchange / Office365? If you do, I'd like to setup a phone call/screen share to get this sorted.

Even better, if someone knows how to fix the auto discover so cPanel is not interfering, that would be of use too.

 

[John221us]

Do you have on Exchange services through Office 365, on premise Exchange or a hybrid deployment (unlikely for a small office). If you purchased one of the E SKUs (E1, E3, or E5) then you are entitled and paying for hosted Exchange services through Office 365. It is very possible your DNS is setup incorrectly for Autodiscover. Does this issue happen internally (at the office), externally (working remotely) or both? I ask, because it is possible you have "split brain" DNS configured, where you might have a different set of DNS records configured for your external zone for you internal users (this is often done for internally hosted apps, so you can point local users to the internal private address). If email is hosted in Office 365 and you do not have split brain DNS configured, you merely need to validate that your external DNS records are correct. If you log in to the Office 365 admin console, go to domains and select your main email domain. It will give you a list of required DNS records. Who is your external DNS hosting service? If this is just happening to internal users and you have split brain DNS configured, then you need to add the records to your internal version of the external DNS zone.

 

[weilke]

Did you use a web hosting service to host your email domain before ?

cpanel is the user interface for some web hosting systems.

 

[denverpilot]

Did you use a web hosting service to host your email domain before ?

cpanel is the user interface for some web hosting systems.

Yeah it sounds like whoever is hosting your DNS also uses cPanel for hosting websites and other stuff, and has forked up you DNS entries.

I'd go look but I have the office Mac disconnected for ... mumble... reasons... maintenance... mumble... and would need other info, like what's your domain name, to figure it out.

 

[weilke]

If you are the company I think you are, then yes, your website host uses cPanel to manage the website.

There is something called an mx file that has to be set at your domain registrar. That is the file that tells the world to now direct your emails to the office365 mail server rather than the email server of your web hosting provider. It sounds like something didn't go right with that process.

 

[AggieMike88]

Do you have on Exchange services through Office 365, on premise Exchange or a hybrid deployment (unlikely for a small office). If you purchased one of the E SKUs (E1, E3, or E5) then you are entitled and paying for hosted Exchange services through Office 365.

Through Office365. If it helps direct the conversation, it was the "E3" version shown on this page: https://products.office.com/en-us/business/compare-more-office-365-for-business-plans

It is very possible your DNS is setup incorrectly for Autodiscover. Does this issue happen internally (at the office), externally (working remotely) or both? I ask, because it is possible you have "split brain" DNS configured, where you might have a different set of DNS records configured for your external zone for you internal users (this is often done for internally hosted apps, so you can point local users to the internal private address). If email is hosted in Office 365 and you do not have split brain DNS configured, you merely need to validate that your external DNS records are correct. If you log in to the Office 365 admin console, go to domains and select your main email domain. It will give you a list of required DNS records. Who is your external DNS hosting service? If this is just happening to internal users and you have split brain DNS configured, then you need to add the records to your internal version of the external DNS zone.

DNS is through Network Solutions (the registrar). The DNS area may indeed be the culprit.... When setting up the service, I was following the instructions provided by Microsoft and made a royal mess of it in the end. Made my website unfindable due to not having the correct DNS records in the right spots. I got that fixed, but only after hiring someone much smarter in this area than I. Domain Name Servers are now on my personal "prohibited item" list.

Website is currently on a cPanel managed host, so your thought that this piece of the DNS picture is interfering with the Autodiscover might be the rabbit trail I need to trace.

 

[AggieMike88]

While we puzzle out the "autodiscover", how do I find out the name of the Exchange mail server so I can set this up manually?

If this is for mailbox "sales@dentonautosalvage.com", is it as simple as putting "dentonautosalvage.com" in that box?

 

[John221us]

Hi Mike,
The DNS records are not going to be hard to fix and it is the right way to do it. If your account has admin rights for O365, login, go to admin page and select domain on the left side, then select your domain. It will give you a list of all required records. If you PM me your contact info, I can help you remotely. Do you have the login info for Network Solutions? This should not affect the A records for your website at all. (BTW, it is more than just an MX record, which I assume is correct, if you are receiving email).
John

 

[John221us]

I believe Outlook.office365.com will work for the server name, but this is not the right way to manage this.
John

 

[AggieMike88]

I believe Outlook.office365.com will work for the server name, but this is not the right way to manage this.
John

I agree. But it would get me over the initial hurdle.

I'll send a PM to you shortly.

 

[denverpilot]

Also keep in mind that a local Domain Controller can override the DNS stuff for auto-config, by pushing things to clients via GPO in Active Directory.

I don't know if you have or use a local Domain Controller and AD on site, just mentioning it in case DNS is correct and it seems to still be doing something squirrelly. An old AD GPO could be screwing with you.

Especially if the local AD server is handling DNS chores and storing DNS entries in AD and replicating them that way...

You won't see these special DNS entries in the DNS panel on the local Windows server if this is the case. Only in the stored actual DNS zone files on disk as "autodiscover" entries. In the GUI they're hidden under "additional records" or something goofy named like that. I forget right now and am not in front of a machine I can look at our 2012 R2 servers.

It's confusing for anyone who does "traditional" DNS until they can see those files, but makes sense when one realizes that a local Domain Controller is built to manage all of this stuff for an organization.

With newer versions of Exchange you also see a shift from having clients talk to the server over native protocols to EWS (Exchange Web Services) so the autodiscover stuff became more important over time. Long long ago. But then MSFT tries to make all of it "just work" when you install Exchange on-site and it stuffs records into your local Domain Controllers. If those are still there, during a move to O365, stuff won't work.

Here's a doc that shows the EIGHT different ways an up to date Outlook 2016 client will attempt to configure itself, and more importantly, how to turn on logging and see which one it's actually using.

https://support.microsoft.com/en-us/kb/2212902

 

[John221us]

Also keep in mind that a local Domain Controller can override the DNS stuff for auto-config, by pushing things to clients via GPO in Active Directory.

I don't know if you have or use a local Domain Controller and AD on site, just mentioning it in case DNS is correct and it seems to still be doing something squirrelly. An old AD GPO could be screwing with you.

Especially if the local AD server is handling DNS chores and storing DNS entries in AD and replicating them that way...

You won't see these special DNS entries in the DNS panel on the local Windows server if this is the case. Only in the stored actual DNS zone files on disk as "autodiscover" entries. In the GUI they're hidden under "additional records" or something goofy named like that. I forget right now and am not in front of a machine I can look at our 2012 R2 servers.

It's confusing for anyone who does "traditional" DNS until they can see those files, but makes sense when one realizes that a local Domain Controller is built to manage all of this stuff for an organization.

With newer versions of Exchange you also see a shift from having clients talk to the server over native protocols to EWS (Exchange Web Services) so the autodiscover stuff became more important over time. Long long ago. But then MSFT tries to make all of it "just work" when you install Exchange on-site and it stuffs records into your local Domain Controllers. If those are still there, during a move to O365, stuff won't work.

Here's a doc that shows the EIGHT different ways an up to date Outlook 2016 client will attempt to configure itself, and more importantly, how to turn on logging and see which one it's actually using.

https://support.microsoft.com/en-us/kb/2212902

I'm guessing what happened (because I have seen it a many times before) is that the that the guy he hired to fix his DNS was the hosting provider and instead of going in and fixing the records where they were, he just pointed the zone to his DNS servers (they like to own the zone) and he didn't add the additional O365 records (probably just the MX record) because he probably didn't know what he was doing.

 

[denverpilot]

I'm guessing what happened (because I have seen it a many times before) is that the that the guy he hired to fix his DNS was the hosting provider and instead of going in and fixing the records where they were, he just pointed the zone to his DNS servers (they like to own the zone) and he didn't add the additional O365 records (probably just the MX record) because he probably didn't know what he was doing.

Agreed. Very common mistake. Also why we don't let anyone but us ever touch our public or private DNS. But it's hard at the small business level to have someone around who can deal with it.

We integrate so much with stuff like MailChimp and MailGun and Twilio and other services that need specific DNS records and also host some customer zones that also do, that we have a reason to pay DNS savvy folks to be on staff at all times.

All that said, if I'd go reinstall the desktop machine in the home office today and spend two minutes with dig, I (and anyone else here) could tell Mike exactly what his public DNS says for autodiscover. I just haven't made it in there to work on the reinstall project yet. And I realize that even if it's correct in the public side, it could be incorrect inside his office if he has a Windows DC/Domain Controller/DNS server/AD server combo messing with him.

You know, I didn't search for one, but I bet for the command line skittish, someone has written a script that can be run on a client desktop machine that would spit out all of the autodiscovery stuff in a nicer human readable format. Probably free, too. It's pretty common to need a little tool like that, and someone has probably shared one on GitHub.

 

[AggieMike88]

I'm guessing what happened (because I have seen it a many times before) is that the that the guy he hired to fix his DNS was the hosting provider and instead of going in and fixing the records where they were, he just pointed the zone to his DNS servers (they like to own the zone) and he didn't add the additional O365 records (probably just the MX record) because he probably didn't know what he was doing.

No, hired gun was the very well educated and major experienced geek from the advertising/marketing firm I contract with. He knows major bucketloads on SEO and other goodies on how the interwebs tangle and untangle themselves. He quickly identified what the issue was when I caused my website to go dark and knew what was needed to fix that.

My suspicion is in line with yours is that we didn't know that a particular MX record was needed, thus not put into play when we were fixing that stuff.

And Nate, I don't have any onsite devices that control DNS or site hosting activities.

Today has been a bit more hectic than I had planned.... working auctions to get raw inventory for the salvage yard machine has been more productive than anticipated. I underbid most of the desired lots by 15% and I'm still winning more than anticipated. Now I'm busy getting the cars/parts inputted into the inventory system.

I'll set up time with one or both of you soon for a screen share session.... that way, with you guiding me what to click on and search for, you can see what's "under the hood" and what needs to be added or changed.

 

[denverpilot]

Hmm side note Mike...

Any other IT folks here, feel hair go up on their neck, their master caution light go off, and wiggles on their BS detector meter, whenever they hear "SEO" -- and want to reach to check and see if their wallet is still in their back pocket?

Mike... there's over 3000 PhDs at Google trying to make their search engine not be fooled by stupid web tricks, and there is an entire industry of pud-knockers who think they're tricking those PhDs...

Just sayin'. Be careful with that crap.

Glad to hear the auctions went your way!

 

[AggieMike88]

Nate... Appreciate the concern, I'm happy with what they are doing for me (recent past, and for short and long term future), so not so worried.... more to them than you know, and the simple changes the uber-geek did are paying off. My site comes up even when looking for the local big box places like Napa and Autozone.

 

[denverpilot]

Nate... Appreciate the concern, I'm happy with what they are doing for me (recent past, and for short and long term future), so not so worried.... more to them than you know, and the simple changes the uber-geek did are paying off. My site comes up even when looking for the local big box places like Napa and Autozone.

That's good. It's often a bit of a scam. Especially long term contracts. But if they know what they're doing they can help with exactly the sort of things you mention -- convince the search engines that you're part of that other blob of businesses -- so you come up when people search. After that level, SEO hockey-sticks very fast for ROI and that's why they tend toward wanting long term contracts and monthly payments. Their expertise petered out in the first site redesign and they can't do a whole lot more.