Exchange Blog by Georg Hinterhofer, Microsoft Certified Master:Exchange

Exchange 2016 - Introduction Part 2 - Requirements and Prerequisites

Continuing from part one of the series (Part 1 is here), today we want to take a look at system, forest, domain, server and client prerequisites to make Exchange 2016 feel at home.

Microsoft made a few good decisions in what they support and what they don't. Here's a quick overview:

  • Exchange 2016 can only coexist with Exchange 2010 SP3 RU11 or later and Exchange 2013 CU10 or later - please note that these RU's and CU's are not available yet. There's NO support to migrate directly from 2007 (or even 2003) to Exchange 2016. If you are still running one of these versions, it necessarily means either a two-step Migration (2007->2013->2016) or your choice of a third Party.

  • From a domain and forest perspective, Microsoft made the - IMHO - very good move to only support Windows 2008 R2 or higher Forest Functional Levels and Domain Functional Levels. It's time to let Windows 2003 die R2, seriously folks. It's a product that's by now really far past it's lifetime. This change also aligns the recommendations from the Exchange PG with those from the Windows PG. Furthermore, as before, Microsoft still requires at least one GC running either 2088R2 in each site where you plan to add Exchange.

  • Obviously, with new versions of Exchange, it'd be weird if we dint see any new clients and client prerequisites. As introduced in Exchange 2013 SP1, Microsoft is betting big on MAPI/HTTP. It might even become the default, enabled protocol in Exchange 2016 - the PG is still debating on that though. So it's pretty clear that all supported editions will have the need to support MAPI/HTTP. Its definitely time to say bye bye to Outlook 2007. Here's the current idea -

    • Outlook 2010 SP2 with the latest Hot-fixes
    • Outlook 2013 SP1 with the latest Hot-fixes
    • Outlook 2016, obviously
    • Outlook for Mac 2011 or later (EWS)

Here's the quick overview from Ignite:

As before, when installing Exchange 2016 in a native Exchange 2010 environment, and you didn't have any Exchange 2013 installed, this will effectively block you from ever installing Exchange 2013. So if you feel that you might need Exchange 2013, bring up a small VM with both Exchange 2013 roles upon it before you move forward to Exchange 2016. This way you can always utilize 2013 if you feel the need for it.

Last but not least - Server Requirements:

  • The Exchange PG made the right move here to only support the newest version of their server OS's as a base for Exchange 2016. Windows Server 2012 R2 is fine, so is the upcoming Windows 10 Server (currently in TP2 stage). As before, the Exchange PG doesn't support server core installations.

  • As for software prerequisites, you will be pleasantly surprised that nothing really changed from Exchange 2013. Exchange 2016 still need the .Net Framework 4.5.2, WMF 4.0 and the UCMA 4.0. The one thing I'm very glad to see is that Microsoft puts way more focus on Office Web Apps Server nowadays. 

    In fact, if you want to preview ANY attachments in Outlook on the Web - formerly Outlook Web Access) or even work with them, you will NEED to have at least one Office Web Apps Server around. There's already a beta of Office Web Apps vNext available, so grab that and familiarize yourself. BTW - do you think that "Outlook on the Web" sounds as horrible as I do? Feels like another pretty useless and confusing rename.

  • The usual Windows - Prereqs also apply. Desktop experience, IIS, and so on - the easiest way to install is to let either Exchange 2016 do the work, or use the powershell way of installing - i prefer this one: Open up an administrative Powershell, run

    Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS
    and be done with it. A reboot will required afterwards.

In the next part, we will look at the possible coexistence scenarios that are possible, I'll bet you'll be a bit surprised whats in store for you!

Have a nice weekend,


Exchange 2016 - Introduction Part 1

With the Exchange 2016 Beta finally available to the public (grab the bits here -, i wanted to start a little series to get us all kicked off with Exchange 2016 in no time. Before we get into deployment, lets see what all the fuzz is about Exchange 2016 and how it came to be what it is right now.

Exchange 2016 is built off of Exchange 2013, not a complete re-development as with the move of Exchange 2010 to Exchange 2013. Seeing that Microsoft that Microsoft has it's own multiple-Million Exchange infrastructure, Office 365, it's pretty clear where most of the development is coming from - the Cloud. At Ignite, we saw the following slide -

So the way enhancement and refinement is coming to On-Premise versions is through feedback and development in Office 365. Think about Exchange 2016 as a vessel of bringing all the goodness of stability, reliability, fixes and obviously new features that have been developed for O365 to your on-premise environment. Exchange O365 runs millions of mailboxes with little to no downtime - just think about having that form of reliability on prem. Awesome!

Lets have a look at the major points of investments:


  • "Combine Mailbox Servers with CAS Servers?" Are you sick of that discussion? Well take it easy - there's only one way to do it - there's just ONE role anymore. So the preferred Exchange 2013 Installation method now becomes the only method in Exchange 2016
  • Basic protocol architecture is still the same as in Exchange 2013 - "For a given mailbox's connectivity, the protocol being used is always served by the protocol instance that is local the the active database copy". Basically - the mailbox server that your database is hosted on will do the work for you.


  • Faster Failovers
  • Replay Lag Manager is now turned on by Default (already available in Exchange 2013 if you want to).
  • Database Divergence Detection - Servers share a common stream of Knowledge to make them aware of divergence and correct them before anyone notices.


  • IP-less Dags are becoming the new norm. Forget about that DAG-IP being offline, thinking of a DAG Name etc. Started already in Exchange 2013, this becomes the standard for Exchange 2016 deployments.
  • Get-MailboxServerRedundancy - this cmdlet will help you do determine which are Servers are save to have maintenance performed on them, and also specify how urgent you want to do maintenance on any Server - Exchange will do the rest

Improved Search

  • Finally - Outlook 2016 in cached mode will be able to use the Exchange Server CI instead of relying on WDS to present search results.
  • Overall search speed has been greatly enhanced.
  • Fuzzy search logic is used to present matching Content, People, calendar items and so on...

Enhancements to usabiity

  • Modern attachments - Outlook and OWA will present you with a completely new attachment experience. More on that later!
  • More tight Integration with SharePoint and Office Web Apps Server 2016

In the next session we'll look at AD/Forest requirements, System and Client requirements and how to deploy Exchange 2016.



Active Directory Event 1801 - The partition DC=ForestDNSZones should be hosted at site ABC, but has not been intantiated yet.

Alright, its not the best way to start for an Exchange blog, but hey - Exchange is as depended on Active Directory as the next guy.

I've been called in by a customer who was getting the following error messages from ADDS -


Ok, one would think that with those Events, Integrated DNS Zones and stuff would be broken as well, but they were pretty happy and even replicated.

The customer was already working with Microsoft Support at that time, but the suggestions that came down the support channel were, lets say, mediocre. Suggestions like demote/promote (if the partition is screwed, what's that supposed to do?), transfer or even seize domain controller roles, and so on... none of those worked, or could be potentially even dangerous - seizing a role? really? when everything else is happy?

After digging around, I noted that the ForestDNSZones and DomainDNSZones were indeed inaccessible when trying with ADSIEdit. So why is integrated DNS working? Let's do some basics on what these application partitions actually are.

The Forest- and DomainDNSZones partitions have been created when the first Windows 2003 or higher domain controller was promoted. They are used to store DNS Zones for replication from 2003 onwards. However, before that, the Microsoft DS Team didn't store their data in these partitions, but in a subtree of the Domain Naming Context partition.

Guess what - this customer obviously once had Windows 2000 - and never bothered to change the DNS Zones to the new 2003 model. This explained why DNS was still happy while the actual DNS partitions were screwed.

After consulting with an AD MCM (thanks Andreas!), we agreed that the best way of going forward was to delete both effected partitions using NTDSUTIL (make sure you have a proper backup), and let Windows DNS recreate these - as there was not data in it (remember, all data was still in the domain naming partition), we didn't loose anything. And even if - the data was destroyed anyway.

To do this, you can run -

  • Run ntdsutil
  • Type domain management
  • At the domain management command prompt, type:
  •  At the server connections command prompt, type:
    connect to server ServerName (where servername obviously is a DC of yours)
  • At the server connections command prompt, type:
  • At the domain management command prompt, type:
    delete nc ApplicationDirectoryPartition (where ApplicationDirectoryPartition is the DN of the Partition you want to delete, in our case CN=ForestDNSZones,.... and CN=DomainDNSZones,CN=....

After deleting, wait for replication and restart the DNS service on one of your servers. This will recreate the now missing partitions. When those came back up, we could already see that the partitions were there again -  only thing left to do was to restart AD DS on all involved servers, and replication started working again for those zones too! As a cleanup, we moved all DNS zones over to the new 2003 or higher model.

So there goes my first blog post on this new spot - hope it helps!



Well, well... look what we've got here!

Yep, another blog about our favourite product - Microsoft Exchange. In time, i will try to fill this blog with many useful bits and pieces of information.

Georg Hinterhofer