MSOffice / Outlook connect to local exchange

[coffee]

Ok, I have a client with about 13 workstations running win7 pro with MSOffice 2013. I will be replacing a workers laptop with a desktop computer. My problem is that I know I will run into difficulty connecting to their local exchange server (SBS 2010, AD,Exchange,DNS). Since I think 2013 is not available anymore and the exchange server is totally local I will have issues getting something like Outlook 2016 to actually see the exchange server. I had this problem in the past as I remember but was able to find a copy of Office2013 that temporarily resolved my issue.

I remember talk about having to alter the 'Autodiscover' for office2016 to find the server but I am very fuzzy on that.

So, Basically looking for help in advance on how to get outlook 2016 to connect to this local exchange server. I know most of you would recommend 365 but this company does not want any of their files "on the cloud".

I think I asked once before many moons ago and was told "Setup autodiscover" to which was at best vague to me.

Thanks,

coffee

 

[Sky-Knight]

If you have Exchange 2010, you can connect Outlook clients up to two versions away, 2016 still directly supports Exchange 2010 as a result. If it's not connecting, you have an issue with autodiscover, or you've neglected the update roll ups and service packs for exchange which must be manually installed.

Sadly, if "setup autodiscover" is vague to you... you really need to get on Google and update your brain, that's pretty much Exchange 101. I'd give you more detail but the process is a bit beyond what can get stuffed into a forum post. You are going to need this site though: https://testconnectivity.microsoft.com/

Your customer will need a real SSL certificate that is valid for the name used to get to the mail server's web port, AND autodiscover.domain.com, you'll need to kick DNS both publicly and privately so resolution works everywhere. So your client is at least out the cost for a 5 name certificate, unless you can find one that does two and you can control both.

Oh, and your customer needs to upgrade to Office 365, they really have no choice in the matter. At $4 / month / mailbox that's the cheapest and most effective way to upgrade Exchange, get that load off the server, and keep it current. The actual upgrade to Exchange 2016 is UGLY...

Thanks Microsoft, why can't Exchange 2016 install on Server 2016 without flaming hoops? Oh... yeah... because Microsoft.

 

[coffee]

If you have Exchange 2010, you can connect Outlook clients up to two versions away, 2016 still directly supports Exchange 2010 as a result. If it's not connecting, you have an issue with autodiscover, or you've neglected the update roll ups and service packs for exchange which must be manually installed.

Sadly, if "setup autodiscover" is vague to you... you really need to get on Google and update your brain, that's pretty much Exchange 101. I'd give you more detail but the process is a bit beyond what can get stuffed into a forum post. You are going to need this site though: https://testconnectivity.microsoft.com/

Your customer will need a real SSL certificate that is valid for the name used to get to the mail server's web port, AND autodiscover.domain.com, you'll need to kick DNS both publicly and privately so resolution works everywhere. So your client is at least out the cost for a 5 name certificate, unless you can find one that does two and you can control both.

Oh, and your customer needs to upgrade to Office 365, they really have no choice in the matter. At $4 / month / mailbox that's the cheapest and most effective way to upgrade Exchange, get that load off the server, and keep it current. The actual upgrade to Exchange 2016 is UGLY...

Thanks Microsoft, why can't Exchange 2016 install on Server 2016 without flaming hoops? Oh... yeah... because Microsoft.

Thank you for the reply. I will be knuckling down and reading up. I might delay the install a bit until I get this figured out. I appreciate the link and the advice.

coffee

 

[Sky-Knight]

Patch first play later!

Auto-discover is pretty easy, but it's an anal beast, and if you miss a fundamental... good night does it get ugly. You can manually configure Outlook, but honestly... one of those stations takes me so long to do manually that I can instead use that same time on Autodiscover and fix it forever... you'll also need autodiscover working to migrate them either to on prem Exchange, or Office 365... so honestly you have little choice but to get autodiscover working.

 

[HCHTech]

Your customer will need a real SSL certificate that is valid for the name used to get to the mail server's web port, AND autodiscover.domain.com, you'll need to kick DNS both publicly and privately so resolution works everywhere. So your client is at least out the cost for a 5 name certificate, unless you can find one that does two and you can control both.

@Sky-Knight , I'll take the lashes for not quite understanding here - haha. In a typical on-premise Exchange setup, what are the 5 (possible) names for the cert you are referring to? I would imagine you would have A records, for example, for mail.company.com, and autodiscover.company.com, both pointing to the public address of the server, yes? Then a CNAME record for OWA. I would normally start with an SRV record in the local DNS, but that doesn't impact the cert. I'm sure there is more than one way to do it, and I only have a handful of on-premise clients. Could you elaborate?

 

[Markverhyden]

For private use I always do a self-signed certificate. No need to pay for something that "stays in the family" so to speak.

 

[Sky-Knight]

@Sky-Knight , I'll take the lashes for not quite understanding here - haha. In a typical on-premise Exchange setup, what are the 5 (possible) names for the cert you are referring to? I would imagine you would have A records, for example, for mail.company.com, and autodiscover.company.com, both pointing to the public address of the server, yes? Then a CNAME record for OWA. I would normally start with an SRV record in the local DNS, but that doesn't impact the cert. I'm sure there is more than one way to do it, and I only have a handful of on-premise clients. Could you elaborate?

Sorry for the confusion, I was referring to the need for a 5 name UAC certificate. You need the certificate to resolve autodiscover. and mail. or whatever you want the IIS on that Exchange to use publicly. You can get away with a normal web certificate if and only if you can redirect the root name, domain.com to the local IIS but this generally isn't true because you have that aimed at a web server hosting the public website. If you use the link I provided and test a working exchange, perhaps an office 365 client, it'll step you through the process and you'll see what names work. You can also use it against this client and see what fails. You don't have to make all path's work, just one. None of them involve SRV records, Exchange doesn't use them as far as I know.

A self signed certificate can also work, but you'll have to manually install it on the client so it's trusted. If you go this route, you'll forever be having issues with mobile devices and kill your ability to migrate them to 365 or another Exchange server later.