Exchange 2016 is the latest version of Exchange, and it’s not very different compared to Exchange 2013. When it comes to requirements, there are some differences though:
- Domain Controllers need to be at Windows 2008 level;
- Domain Functional Level (DFL) and Forest Functional level need to be at Windows 2008 level;
- The Exchange servers themselves need to be running Windows 2012 or Windows 2012 R2. At the time of release Windows Server 10 is not supported.
There’s also something like Simplified Architecture. This is the Exchange 2013 Preferred Architecture, enforced on Exchange 2016. This means that there will be only one Exchange 2016 server role on the internal network, the Exchange 2016 Mailbox server. This is the same as the old Exchange 2013 multi-role server, but at this moment there’s no choice left. You have to install the Exchange 2016 Mailbox server, and you cannot opt to install a dedicated Client Access server anymore.
Continue reading Deploy Exchange 2016
I am always amazed by the amount of customers running Exchange 2007 or Exchange 2010 and NOT using Autodiscover. Their response is always “we don’t need it” and “we configure the Outlook profile manually”. In Exchange 2007 and Exchange 2010 you can get away with this (you cannot with Exchange 2013 and Autodiscover is mandatory) but when you want to implement a hybrid scenario with Exchange online you really need Autodiscover since Exchange Online uses Autodiscover to find relevant information regarding your on-premises Exchange environment.
Recently a customer with Exchange 2010 wanted to build a hybrid environment with Exchange Online, and one of my first findings was the lack of Autodiscover. So, after configuring their Exchange environment and creating the necessary DNS records Autodiscover was working properly as shown in the following picture:
Continue reading Disabled Outlook Anywhere causing free/busy issues
Microsoft introduced a new protocol in Exchange Server 2013 SP1 called MapiHttp (codename Alchemy). This is an Office 365 development to replace the traditional RPC/HTTPS protocol used in Outlook Anywhere.
Outlook Anywhere was developed in the Exchange 2003 timeframe to use Outlook 2003 over the Internet. Outlook is using RPC to communicate with the Exchange server, and the RPC traffic is encapsulated in HTTPS packets. To achieve this an RPC proxy is used. The ‘problem’ here is that this is not too stable, especially not when you have a flaky Internet connection. RPC is never designed to work with network connections like this. Besides this, the RPC proxy is a Windows components and thus a responsibility of the Windows team at Microsoft and not the Exchange team. So if problems arise, the Windows team has to solve this and the only thing the Exchange team can do is wait. Not a desirable solution.
Continue reading MapiHttp in Exchange 2013 SP1