The earlier posts in this series (Part 1, Part 2, Part 3, Part 4, Part 5) focused on the set up and configuration of the Server Essentials role on a Server 2012 R2 machine followed by the set up and configuration of Exchange 2016 on a second Server 2012 R2 machine and its integration with tools provided by the Server Essentials Role. The posts are by no means exhaustive but they do provide a general guideline for configuration.
This final post will focus on the things you need to do to publish and secure the various Exchange-generated webpages and what you need to do to make them accessible to the outside world.
There are three main points of access to Exchange that are provided via various “web” means and technologies:
- – ECP ( Exchange Admin Center, management)
- – OWA (Outlook Web Access, user web access)
- – mobile device access (email feed)
The ECP and OWA pages are pretty much what you would expect as they are the pages you and/or your users access via a web browser. The mobile device access pages (ActiveSync and other technologies) are another matter entirely. But, regardless of what the pages do, they are all protected and secured by SSL and the third-party SSL certificate that you obtain.
ECP and OWA are accessible on the LAN with or without an SSL cert. But WAN access to ECP and OWA as well as operational access to mobile device technologies (ActiveSync et al) are predicated on having a proper SSL cert in place; in fact ActiveSync is completely unusable without a cert.
I said earlier in this series that you require a second static IP on your WAN connection for your Exchange server. This is because you need to be able to publish the FQDN of your server on your firewall on port 443 (SSL) so that ECP, OWA and ActiveSync are accessible from the WAN. All of the following steps assume you have made your firewall changes and that HTTPS (SSL, port 443) and SMTP (port 25) are pointed to the Exchange server LAN IP from the second static IP on the WAN.
There are a couple of steps that you need to follow to in order to obtain and install a cert.
Click on certificates:
As you can see, the system has generated and installed a few “self certs” so that basic features can be accessed but these are not adequate going forward. To obtain a proper cert you first have to generate a cert request (a “CSR”) that you can then pass on to a third-party SSL provider such as Certificates For Exchange. To create the CSR click on the + sign:
Clicking on the icon will cause a new webpage to open:
Clicking on Next starts the CSR generation process:
I have entered “mail.beagledom.ca” as the “friendly name”. This should match earlier settings made while setting up Exchange and should be the desired FQDN for the Exchange server. ALL resulting URL’s will start with this FQDN as the root of the URL such as https://mail.beagledom.ca/ecp or https://mail.beagledom.ca/owa . Click Next.
This is the important screen. I’m going to request a “wildcard” cert which means the cert can technically cover any site within beagledom.ca. This is important as it will dovetail with the request type I am going to make at the cert provider (Certificates for Exchange).
All fields are required.
This is a place to save the request file, it can be anywhere you want but you need to be able to get to the file that is created.
The file will be saved and on the certificates screen you’ll see it as a “Pending request”.
The CONTENTS of the file need to be passed on to your certificate provider of choice. Some will want you to upload the file, others will want you to copy/paste the contents. Either way, you have to complete the process at your certificate provider in order to have a valid certificate generated and sent back to you for installation.
You complete the process on the Exchange server by highlighting the certificate request then clicking on the Complete link:
As this is a lab system I’m not actually going to complete the request process. But I will look at the completed certificate as installed at the Stan Hagen Centre.
The cert has been assigned to cover specific services (red box). I assigned specific web addresses to the cert when I generated the request at Certificates for Exchange which appear in the properties for the cert as “Subject Alternative Names”.
You must have the FQDN of the server (mail.sashcf.com), the internal FQDN of the server (sashhyg02.sashcf.com) and the autodiscover record (autodiscover.sashcf.com) and the root domain (sashcf.com) as a bare minimum. And, of course, you must have matching DNS records published to match.
With all of this in place your users will be able to access OWA as an SSL-secured site, you’ll be able to do the same with ECP and you’ll be able to connect mobile devices via ActiveSync.
A best practice is to check your connectivity and operations with the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) using the Exchange Server connectivity tests. Your system should test correctly but if it does not the tests will give you a pretty good idea where issues may exist. It is very important to perform this testing before you give users access as you want to ensure the system operates as expected. You will probably hit issues with mobile devices as every device seems has its own quirks” connecting to Exchange. If you know your system tests correctly you can then work to sort out the individual devices. As an example, with Stan Hagen we found that iPhones and iPad’s connected without any issue with minimal information provided on the devices Exchange configuration page. Android devices were all over the map; some connected with minimal information others required us to fill in every single piece of information on the Exchange “advanced” configuration screens. But as we knew the system itself was okay we focused our efforts on “tweaking” the devices.
I hope this series has proved helpful.