During an upgrade of an Exchange 2013 SP1 multi-role server to Exchange 2013 CU8 the upgrade crashed, apparantly on a strange Receive Connector configuration since the following error message was raised:
The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector ” SERVER1\Relay Connector SERVER1″. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.
Continue reading Upgrade to CU8 Fails on Receive Connector misconfiguration
In my previous blog I wrote about the new SSL offloading capabilities in Exchange 2013 SP1. In this blog I will explain how to use this with a load balancer. In my lab environment I’m using an F5 (virtual) LTM running on Hyper-V. My lab is configured as shown in the following figure:
Continue reading load balancing in Exchange 2013 SP1 with F5
One of the ‘new’ features in Exchange 2013 SP1 is SSL Offloading, although I can better say ‘re-introduced’ features since this was available in Exchange 2010 but not supported in Exchange 2013 RTM.
I’ve explained numerous time why you want to use SSL offloading in Exchange, but mainly because of performance reasons (load balancers typically have a dedicated chip for SSL decryption) and for SSL certificate management. Suppose you have 8 Client Access servers and *not* using SSL Offloading. In this case you have to manage the SSL certificate on each individual Client Access server. If you have an SSL offloading scenario you have only one SSL certificate to manage, and that’s the SSL certificate on the load balancer.
Continue reading Exchange 2013 SP1 SSL Offloading
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
Re-introduced in Exchange 2013 SP1 is Command Logging. This was available in Exchange Server 2010 when using the Exchange Management Console. This way you could easily see what commands the Management Console was actually executing.
Command logging is now also available in Exchange Server 2013 SP1, but you have to be aware that you need to turn it on before you start working in the Exchange Admin Center. In EAC click on the little arrow in the top right corner and select the Show Command Logging option.
A new window appears where all commands are shown based on what you configure in EAC. It can be a bit cryptic, sometimes object GUIDs are used instead of normal (readable) names but at least it’s possible to figure out what’s happening under the hood.
In the screenshot shown here I’ve created a new Email Address Policy and I can use Command Logging to figure out what EMS commands were used. The only thing I have to figure out now what container is used for the User objects, but that’s not too difficult.