In this blog post we’ll look at how to install the latest version of Exchange 2016 on Windows Server 2016. At the time of writing the current version of Exchange 2016 is CU3.
When Exchange 2016 was first released it wasn’t possible to install it on the Windows Server 2016 Technical Previews due to some missing features in the OS that it relies upon, but now Windows Server 2016 has been released to manufacturing, installation of Exchange 2016 on WIndows Server 2016 is supported.
The demo environment I am using includes a Windows Server 2016 domain controller that is running at the Windows 2016 forest and domain level, and a Windows Server 2016 member server.
In the demo environment no previous versions of Exchange have been installed so as part of the installation the Exchange 2016 we will upgrade the AD Schema.
Finally before we start, always test in a demo environment before deploying in Production!
Having been away over the summer I’m playing catchup with a few blog posts, so this one is a little late in coming! Over the summer (15th June 2016) Microsoft released the Exchange 2010 SP3 Update Rollup 14.
I installed Update Rollup 14 on my test SBS 2011 server this evening and it took about 22 minutes from start to finish, so I wouldn’t expect it to take much longer than this in production.
Please test before installing into your production environment. Maybe even wait a few days or a week or two from the release date to make sure the QA is up to scratch on it.
For migrations to Exchange 2016, Exchange 2010 SP3 Update Rollup 11 is the minimum version that will be supported in a coexistance environment.
In part 10 of this mini-series, I’ll look at how to configure the virtual directories used by Exchange 2013. We’ll need to configure these to match the FQDNs we request on our SSL certificate.
It’s assumed that split-brain DNS will be setup for the configuration to work. The essenace of split-brain DNS is that your external domain name is also configured on your internal DNS servers, but the A records on the internal DNS server point to the internal IP address of the server whereas the domain name configured on your external DNS servers point to the external IP address of your server. So whether a client is internal or external the FQDN will always resolve to the correct IP address.
In part 9 of this mini-series, I’ll look at how to configure the Fully Qualified Domain Name (FQDN) of the Default Frontend receive connector in Exchange 2013.
Firstly a warning: Don’t modify the FQDN value on the default Receive connector Default that’s automatically created on Mailbox servers. If you have multiple Mailbox servers in your Exchange organization and you change the FQDN value on the Default Receive connector, internal mail flow between Mailbox servers fails.
In a single Mailbox server environment to change the Default Frontend receive connector FQDN follow the steps below.